Étape 1: 99 problèmes et une connexion de travail n’est pas un
Il y a deux options pour transmettre les signaux d’un téléphone cellulaire à un moteur. Ce sont ceux que j’ai essayé et mes motifs de l’utilisation (ou de ne pas utiliser) eux.
TL; dr: utilisez le module BT
Étincelle Core: compatible WiFi, compatible Arduino, petit Conseil. Dire quoi! ? Je devrais être capable de juste envoyer un signal du téléphone à cette chose directement via UDP/TCP, mais à partir d’avril 2014, ce n’était pas possible. Tandis que l’équipe d’étincelle travaille à une modification de leur firmware, quand j’ai testé ce Conseil, il a seulement couru si il était connecté à l’internet et le serveur de base de la bougie. Je voulais juste les communications locales, alors que ce n’était pas bon.
IOIO-OTG: se connecte directement sur le téléphone via un câble USB et permet à l’application du téléphone d’avoir un bouquet de broches GPIO. Génial ! Cela aurait été parfait si j’avais pris le temps de comprendre comment écrire mon propre firmware. Comme elle vient, le firmware sur le IOIO-OTG est à peu près comme un firmata. Toute la logique doit fonctionner sur le téléphone et la seule chose qu’il fait, c’est exposer certaines broches d’e/s. Parce que j’utilise des moteurs à courant continu simples avec fin de course, cela semblait être une option risquée. Que se passe-t-il si le téléphone perd la connexion à l’Office, ou les accidents de l’application, tandis que l’un des moteurs est allumé ? Le IOIO-OTG ne pourriez pas obtenir les signaux de fin de course pour arrêter le moteur.
Arduino ADK en tant qu’hôte USB : aussi semblait prometteur. Envoyer directement des messages à un Arduino depuis un téléphone, via un câble ! Gagner, droite ? Je pourrais écrire mon propre code Arduino pour faire face à la course et moteur logique, et le téléphone enverrait seulement des commandes simples de STOP/GO à l’Arduino. Parfait, sauf l’appariement entre Arduino, téléphone et app était, au mieux, merde. L’ordre dans lequel je devais allumer le téléphone, l’Arduino et l’app et branchez le câble, a été très précis. Je pense que c’était allumez le téléphone, allumez l’Arduino, brancher l’Arduino dans téléphone, débranchez l’appareil Arduino de téléphone, brancher l’Arduino dans téléphone, démarrer env. quoi que ce soit autre que causerait le téléphone pour ne pas être reconnu par l’ADK Arduino et parfois même cause le téléphone pour réinitialiser. Très pointilleux !
Arduino ADK avec dongle BlueTooth : fonctionne très bien avec des dongles. Autres dongles de la même marque et le type, ne serait pas juste paire. J’aurais été en mesure de le faire fonctionner en ajoutant quelques retards dans le code de l’Arduino, mais à ce stade, j’ai été assez déçu par l’ADK et de l’USB Host Library.
Arduino avec module BlueTooth: au départ, je ne voulais pas utiliser BT en raison de la façon dont il doit être associé et parfois il perd sa connexion/couple et quelques paquets supprimés... mais en fin de compte, c’est la solution la plus judicieuse. Peu importe si les paquets supprimés, j’envoie seulement un genre STOP/GO très simple de signal, et je peux ajouter redondance. Il également n’importe pas si le téléphone devient non-apparié provenant du module BT. Je sais que c’est là, juste à côté du téléphone, donc je peux continuer à essayer de se connecter à l’aide de code dans l’application Android. Bien que cela puisse paraître difficile au début, c’est beaucoup plus facile que ce que j’avais à faire pour rétablir le câble de connexion de l’ADK, une fois que le téléphone perdu la trace de l’Arduino (débrancher, brancher, redémarrer l’application, etc.).
Donc en fin de compte : BT pour la victoire !
