Étape 3: Test de BlueTerm
Fil de votre K64F le module de commande de moteur.
Se connecter au module Bluetooth à l’aide de BlueTerm.
Connecter un terminal série au port série USB sur la K64F de l’ordinateur hôte pour afficher le diagnostic.
Pour tester vous pouvez changer le Deadman délai d’attente par défaut de 250 à 500 ms à quelque chose de plus comme 15000ms dans la fuinction de initMotorDrive() de main.cpp. Cela vous permettra de tester depuis un terminal sans l’application de contrôle à distance. Lorsque vous exécutez un véritable robot, le délai d’attente de deadman devrait être plus proche de la vitesse de commande de votre application de commande, tels que CXEM-voiture, environ 100 à 500 ms.
Le Bluetooth du terminal, tapez une commande comme L255 à pleine vitesse avant sur le moteur gauche. Puis L-99 pour le retour de près de moitié-vitesse. Notez que le moteur s’arrête brièvement avec le frein électrique, puis démarre dans le sens inverse. Vous pouvez faire semblable pour le moteur droite avec des commandes comme R-255 puis R111. Lors de l’émission les commandes R0 ou L0 les moteurs doivent cesser d’utiliser rapidement le frein électrique.
Le frein électrique engagés lorsque les deux entrées directionnelles sont faibles, et l’option Activer est élevé. Dans le cas contraire, la vitesse principale de conduite lorsque le contrôle est effectué avec PWM sur la ligne activer.
Diagnostic décrivant toutes les actions ci-dessus peut être affichées sur le terminal PC-USB. Si vous examinez le code il y a des rapports de diagnostic plus commentée. La plupart de ces diagnostics auront des commandes qui ressemblent à des DiagSerial.printf(...). Vous pouvez supprimer ces commentaires pour des diagnostics plus. J’ai trouvé que trop d’impressions de diagnostic peuvent causer le MCU de geler quand fournissant un flux haut débit commande, tels que l’opne produites par l’app CXEM-voiture.
