Open Bidouille Robot : Différence entre versions

De Les Fabriques du Ponant
Aller à : navigation, rechercher
(OBR)
m (+ Catégorie:Arduino)
 
(22 révisions intermédiaires par un autre utilisateur non affichées)
Ligne 6 : Ligne 6 :
  
 
== Pourquoi ce projet ? ==
 
== Pourquoi ce projet ? ==
A la base, j'ai été à l'Open Bidouille Camp (d'où le choix de reprendre ce nom pour le projet) de 2012, où j'ai rencontré une connaissance qui voulais faire un robot démineur sans savoir programmer. Je partais donc avec un engin sur roues, avec un bras motorisé au dessus, mais non pilotable. De base, je devais donc coder un programme sur un arduino Mega2560, permettant de piloter les moteurs inclus dans l'engin.
+
A la base, j'ai été à l'Open Bidouille Camp (d'où le choix de reprendre ce nom pour le projet) de 2012, où j'ai rencontré une connaissance qui voulait faire un robot démineur sans savoir programmer. Je partais donc avec un engin sur roues, avec un bras motorisé au dessus, mais non pilotable. De base, je devais donc coder un programme sur un arduino Mega2560, permettant de piloter les moteurs inclus dans l'engin.
 
il y a peu, j'ai mis de côté le robot démineur pour me concentrer sur les robots en général.
 
il y a peu, j'ai mis de côté le robot démineur pour me concentrer sur les robots en général.
 
C'est donc de là que m'est venu l'idée de coder un système modulable, et adaptable à tous types de robots.
 
C'est donc de là que m'est venu l'idée de coder un système modulable, et adaptable à tous types de robots.
Ligne 31 : Ligne 31 :
  
 
== Ce qu'OBR sait faire pour le moment ==
 
== Ce qu'OBR sait faire pour le moment ==
Pour le moment (version 0.4), OBR ne sait pas faire grand chose, si ce n'est gérer les connexions entre arduinos, télécommandes et PC.
+
Pour le moment (version 0.6), OBR gére les connexions entre arduinos, télécommandes et PC.
 
Les commandes sont fonctionnelles, et on peut connaître le nom du robot, ainsi que sa version d'OBR installé.
 
Les commandes sont fonctionnelles, et on peut connaître le nom du robot, ainsi que sa version d'OBR installé.
 
Une session administrateur est gérée, on peut l'utiliser (mot de passe par défaut : 2560) pour configurer le robot.
 
Une session administrateur est gérée, on peut l'utiliser (mot de passe par défaut : 2560) pour configurer le robot.
Lorsque l'administrateur se connecte, la LED 13 s'allume pour dire que la configuration est susceptible d'être modifiée.
+
Lorsque l'administrateur se connecte, la LED 13 s'allume pour dire que la configuration est susceptible d'être modifiée, sauf si la sortie 13 est utilisée.
 +
On peut lui configurer des moteurs, servomoteurs, sorties digitales et des entrées, ainsi que les MIN et MAX des sorties PWM et des entrées analogiques.
 +
La configuration est enregistrée en EEPROM, et est inchangée après un redémarrage.
 +
On peut lier une sortie (PWM ou digitale) avec 1 PIN analog, et 3 PINs E/S. Ces liens permettent de sécuriser une sortie, en lui empêchant de bouger si un des liens lui interdit (ex : un moteur peut tourner jusqu'à ce que le capteur sur A0 soit à plus de 80%, ou que l'entrée sur le PIN 10 soit à 1).
 +
Pour augmenter le nombre de PIN, On peut mettre jusqu'à 3 arduino (un maître et deux esclaves) reliés via les ports séries, la communication entre les cartes se fait toute seule grâce au protocole de communication OBR3.
 +
Pour le moment, OBR v0.6 ne sait pas utiliser les PIN des autres cartes (Maitre, Esclave1 et Esclave2).
  
 
== Ce qu'il sera sensé faire plus tard ==
 
== Ce qu'il sera sensé faire plus tard ==
Dans le futur (version 1.0), OBR devra toujours gérer les connexions automatiquement et à chaud, mais aussi enregistrer les configurations dans l'EEPROM, pour s'en servir lors du pilotage (l'EEPROM sera copié dans différents tableaux en RAM au démarrage).
+
Dans le futur (version 1.0), OBR devra toujours gérer les connexions automatiquement et à chaud, mais le maître saura aussi gérer les deux esclaves (si présents), pour piloter ses entrées/sorties.
Le maître saura gérer les deux esclaves (si présents), pour piloter ses entrées/sorties.
 
 
OBR devra gérer les batteries, et se désactiver si nécessaire.
 
OBR devra gérer les batteries, et se désactiver si nécessaire.
 
Un système de WatchDog fonctionnera sur les ports séries, pour détecter la déconnexion d'un périphérique.
 
Un système de WatchDog fonctionnera sur les ports séries, pour détecter la déconnexion d'un périphérique.
Ligne 62 : Ligne 66 :
  
 
== Code Arduino ==
 
== Code Arduino ==
 +
Le code de la version en développement, sur GitHub : [https://github.com/Aglesia/OBR/blob/master/Dev/OBR/OBR.ino ici].
  
 
== Code C de TeC'OBiR ==
 
== Code C de TeC'OBiR ==
 
=== Bibliothèque de communication OBR en C ===
 
=== Bibliothèque de communication OBR en C ===
 +
Une bibliothèque a été créée pour faciliter la communication entre un programme codé en C, et un arduino tournant sous OBR.
 +
Cette bibliothèque est dépendant d'une autre, qui gère les connexions séries.
 +
Les deux bibliothèques (OBR.h et Serial.h) sont disponible au téléchargement, [github.com/Aglesia/OBR/blob/master/Dev/Bibliotheque_C ici].
 +
 +
Code [https://github.com/Aglesia/OBR/blob/master/Dev/Bibliotheque_C/OBR.h OBR.h], sur GitHub
 +
 +
 +
Le code de [https://github.com/Aglesia/OBR/blob/master/Dev/Bibliotheque_C/OBR.c OBR.c], sur GitHub
 +
 +
 +
'''Des suggestions ? Des conseils ? Je suis preneur ;)'''
  
 
=== Code de TeC'OBiR ===
 
=== Code de TeC'OBiR ===
 +
TeC'OBiR utilise la bibliothèque OBR pour fonctionner...
 +
 +
Code : [https://github.com/Aglesia/OBR/blob/master/Dev/TeC_OBiR/main.c main.c], sur GitHub.
  
 
== Changelog ==
 
== Changelog ==
Ligne 82 : Ligne 101 :
  
 
0.3 :
 
0.3 :
 +
- Utilisation du protocole de communication OBR3
 
  - Ajout du système d'authentification sur les ports série
 
  - Ajout du système d'authentification sur les ports série
 
  - Ajout de la prise en charge des cartes d'extension (jusqu'à deux cartes d'extensions) via RS232 (Mais les cartes seront inactives, sauf pour demander la liste des connexions externes)
 
  - Ajout de la prise en charge des cartes d'extension (jusqu'à deux cartes d'extensions) via RS232 (Mais les cartes seront inactives, sauf pour demander la liste des connexions externes)
  - Ajout du mapage réseau, permettant de relier le PC, télécommande et les cartes d'extensions sur n'importe quel port série (de n'importe quelle carte d'extension)
+
  - Ajout du mappage réseau, permettant de relier le PC, télécommande et les cartes d'extensions sur n'importe quel port série (de n'importe quelle carte d'extension)
 
  - Ajout du système d'adresse dans les commandes, permettant le routage des données à travers les cartes ([1|2]OBR_...)
 
  - Ajout du système d'adresse dans les commandes, permettant le routage des données à travers les cartes ([1|2]OBR_...)
  - Ajout des constantes de compilation pour définir le nom du robot, et son rôle (maitre/esclave), ainsi que le type (MEGA, UNO...)
+
  - Ajout des constantes de compilation pour définir le nom du robot, et son rôle (maître/esclave), ainsi que le type (MEGA, UNO...)
 
  - Ajout de la détection de déconnexion série, et déconnexion auto de l'administrateur
 
  - Ajout de la détection de déconnexion série, et déconnexion auto de l'administrateur
  
 
0.4 :
 
0.4 :
  - WatchDog plus intelligent, évite la surcharge du réseau lorsque ça discute
+
  - Ajout des fonctions de gestion des E/S dans le noyau
  - Mise en place de la configuration des cartes d'extension via les ports série, permettant de les utiliser
+
  - prise en compte des limites imposées dans les sorties PWM
  - Centralisation du pilotage des cartes, via le maitre
+
- Mise à jour auto des valeurs des E/S
 +
  - Réorganisation du code et séparation des fonctions du noyau, des autres fonctions
 +
- Ajout de deux fonctions (user_setup et user_loop) modifiable par l'utilisateur
 +
 
 +
0.5 :
 
  - Mise en place des codes d'erreur dans le noyau du système
 
  - Mise en place des codes d'erreur dans le noyau du système
 
  - Mise en place des fonctions de copie RAM->EEPROM et EEPROM->RAM, contenant les données de fonctionnement (liste des moteurs, capteurs...)
 
  - Mise en place des fonctions de copie RAM->EEPROM et EEPROM->RAM, contenant les données de fonctionnement (liste des moteurs, capteurs...)
 
0.5 :
 
 
  - Ajout des fonctions de mise en place des périphériques (moteurs, capteurs...)
 
  - Ajout des fonctions de mise en place des périphériques (moteurs, capteurs...)
 +
- Sauvegarde des PIN E/S pour les restaurer au boot
 +
- Ajout d'une commande de redémarrage du système
 
  - Ajout de toutes les commandes de pilotage
 
  - Ajout de toutes les commandes de pilotage
- Gestion du pilotage des autres cartes
 
  
'''Pour le moment, la dernière version est la 0.37 : tout ce qui est dit dans la version 0.3 est faite, et une partie de la version 0.4 est traitée.'''
+
0.6 :
 +
- Redémarrage d'un moteur en douceur après un arrêt brutal (Lien qui bloque le moteur d'un coup)
 +
- Suppression du système de blocage de la carte, remplacé par un redémarrage complet du système
 +
- La remise à 0 du mot de passe ne bloque plus l'arduino
 +
- Changement de la gestion des commandes, chaque commande enregistre sa réponse et le système la retourne à la fin des commandes (permet de dire quand une commande est inconnue)
 +
- Séparation des commandes de pilotage et de configuration
 +
- Ajout de la gestion des liens, au sein d'une carte
 +
- L'état de l'activation du watchdog est enregistré en EEPROM, et est restauré au démarrage
 +
- Renommage des fonctions du noyau
 +
 
 +
0.7 :
 +
- Changement de la gestion des numéro de PWM : maintenant on envoie son n° de PIN (et non plus n°PWM) en paramètre
 +
- La liaison entre le PIN 12 et 13 au démarrage réinitialise le mot de passe, mais aussi toutes les configurations
 +
- WatchDog plus intelligent, évite la surcharge du réseau lorsque ça discute
 +
- Correction du BUG qui laisse la LED 13 allumée quand on la déconnecte
 +
- Déconnexion de l'administrateur lors du pilotage
 +
 
 +
0.8 :
 +
- Utilisation de F() pour économiser de la RAM, sur les String des différentes commandes
 +
- Correction de Bugs empêchant la connexion entre deux arduino
 +
- Refonte totale de la gestion des connexions entre les cartes
 +
- Passage partielle au protocole OBR4
 +
- Utilisation de la bibliothèque <Servo.h>
 +
- Déconnexion automatique des PWM connectés sur les PIN verrouillés par la bibliothèque <Servo.h>
 +
- Arrêt complet des moteurs lors de la déconnexion (Valeur_Voulue mis à 0, sauf pour les servomoteurs)
 +
- Ajout de la valeur à 0 pour une sortie (peut être 0 ou 1)
 +
- Watchdog non désactivable
 +
 
 +
0.9 :
 +
- Ajout d'identifiants devant la commande pour connaître le type de message (réponse, commande, watchdog...)
 +
- Gestion centralisée par le maître, on peut configurer une E/S d'une autre carte, en passant par le maître
 +
- Mise en place des liens entre toutes les cartes
 +
- Ajout des entrées/sorties virtuelles, qui se mettent à un automatiquement si tous les liens le permettent
 +
- Doublage du nombre de liens (passage à 2 liens Analogique et 6 liens numériques
 +
 
 +
1.0 :
 +
- Première version finale
 +
- Contient toutes les commandes de pilotage
 +
- Contient toutes les commandes de configuration
 +
- Utilise le protocole OBR4, non compatible OBR3 (utilisé jusqu'à la v0.7)
 +
- Le système de WatchDog des connexions séries est fonctionnel
 +
- On peut brancher et débrancher une carte du réseau à chaud
 +
- On peut connecter une télécommande OBRoC sans problème
 +
- Entièrement compatible avec TeC'OBiR 1.5 et supérieur
 +
 
 +
'''Pour le moment, la dernière version est la 0.8.'''
  
 
=== TeC'OBiR ===
 
=== TeC'OBiR ===
Ligne 116 : Ligne 184 :
 
  - Ajout de la commande 'VERSION' qui affiche la version du programme
 
  - Ajout de la commande 'VERSION' qui affiche la version du programme
 
  - Connexion automatique en essayant les 10 premiers ports en boucles
 
  - Connexion automatique en essayant les 10 premiers ports en boucles
  - Detection de la déconnexion de l'arduino
+
  - Détection de la déconnexion de l'arduino
 
  - Ajout de la connexion admin
 
  - Ajout de la connexion admin
  - Passage au baudrate de 57600 bauds.
+
  - Passage au baud-rate de 57600 bauds.
  
 
1.2
 
1.2
- réécriture du noyau
+
- réécriture du noyau
- Adaptation au nouveau protocole OBR 0.3
+
- Adaptation au nouveau protocole OBR 0.3
- Prise en compte des adresses
+
- Prise en compte des adresses
  
 
1.27
 
1.27
Ligne 129 : Ligne 197 :
  
 
1.3
 
1.3
  - Ajout du choix de l'adresse destinatrice (Commande sous forme "add:OBR_COMMANDE-PARAMS" ex : pour connaitre le nom du maitre, "M:OBR_NOM")
+
  - Ajout du choix de l'adresse destinatrice (Commande sous forme "add:OBR_COMMANDE-PARAMS" ex : pour connaitre le nom du maître, "M:OBR_NOM")
  - Ajout de l'adresse émetrice dans la réponse
+
  - Ajout de l'adresse émettrice dans la réponse
 
  - Séparation du code TeC'OBiR et de la bibliothèque OBR_Communication
 
  - Séparation du code TeC'OBiR et de la bibliothèque OBR_Communication
  
 
1.4
 
1.4
  - Adaptation au protocole OBR 0.4, qui inclus un watchdog sur la connexion série
+
- Passage à l'essai des 50 premier ports séries
 +
  - Adaptation partielle au protocole OBR 4, qui inclus un watchdog obligatoire sur la connexion série
 +
- Ajout d'un thread pour la gestion du watchdog
 +
 
 +
1.5
 +
- Adaptation complète au protocole OBR 4
 +
 
 +
1.6
 
  - Prise en charge des fichiers de config .map
 
  - Prise en charge des fichiers de config .map
  - Peut etre ouvert avec, comme parametre, un fichier .map. La configuration auto se fera dès que la connexion est effectuée
+
  - Peut être ouvert avec, comme paramètre, un fichier .map. La configuration auto se fera dès que la connexion est effectuée
 +
 
 +
'''Pour le moment, la dernière version est la 1.3, le chien de garde est désactivé à la connexion, pour éviter les déconnexions intempestives. (il faudrait mettre moins de 5 secondes à taper une commande, et ne jamais s'arrêter...)'''
  
 
== Liens de téléchargements ==
 
== Liens de téléchargements ==
 +
Un compte a été ouvert sur GitHub pour centraliser les fichiers sources...
 +
 +
=== Documents techniques + notices ===
 +
[https://github.com/Aglesia/OBR/blob/master/Documents/Notice%20d'utilisation%20du%20robot.pdf Notice d'utilisation d'OBR]
 +
 +
=== Binaires finalisées ===
 +
==== Open Bidouille Robot (à compiler sur un arduino) ====
 +
[https://github.com/Aglesia/OBR/blob/master/Versions_Finies/OBR/OBR%20v0.6.ino OBR v0.6]
 +
 +
==== Terminal Console for Open Bidouille Robot ====
 +
[https://github.com/Aglesia/OBR/blob/master/Versions_Finies/TeC'OBiR/TeC'OBiR%20v1.3.exe TeC'OBiR Win32 1.3]
 +
[https://github.com/Aglesia/OBR/blob/master/Versions_Finies/TeC'OBiR/TeCOBiR%20v1.3_Linux TeC'OBiR Linux 1.3]
 +
 +
==== Open Bidouille Robot Contrôleur Arduino (à compiler sur un arduino) ====
 +
 +
==== Open Bidouille Robot Contrôleur PC ====
 +
 +
=== Changelog ===
 +
[https://github.com/Aglesia/OBR/blob/master/Versions_Finies/OBR/Changelog.txt Changelog OBR]
 +
[https://github.com/Aglesia/OBR/blob/master/Versions_Finies/TeC'OBiR/changelog.txt Changelog TeC'OBiR]
 +
 +
=== Lien GitHub ===
 +
[https://github.com/Aglesia/OBR GitHub Open Bidouille Robot]
 +
 +
[[Catégorie:Projets]]
 +
[[Catégorie:Arduino]]

Version actuelle datée du 13 octobre 2016 à 09:41

Qu'est-ce qu'Open Bidouille Robot (OBR) ?

Open Bidouille Robot est un micrologiciel pour arduino, permettant la gestion de moteurs, capteurs, servomoteurs, entrée numériques et sorties numériques. En d'autres termes, OBR sert à la création de robot, via un arduino. Une fois compilé et installé sur la carte, il faut configurer OBR (via le PC par exemple) en envoyant une série de commandes. Une fois configuré, on peut toujours le reconfigurer (ajouter/enlever des servomoteurs, changer la vitesse maximum d'un moteur, etc...), mais aussi le piloter. Lorsqu'on demande à un moteur de tourner, OBR va vérifier dans la configuration s'il est lié à d'autres objets (capteurs, entrées, sorties...), et verrouiller ou non le moteur (de même pour une sortie tout ou rien, et un servomoteur). De cette manière, nous pouvons créer des systèmes de fin de courses, en liant plusieurs choses (ex : le moteur ne peut tourner que si le capteur vaut moins que x, et que l'entrée n°y est à 0).

Pourquoi ce projet ?

A la base, j'ai été à l'Open Bidouille Camp (d'où le choix de reprendre ce nom pour le projet) de 2012, où j'ai rencontré une connaissance qui voulait faire un robot démineur sans savoir programmer. Je partais donc avec un engin sur roues, avec un bras motorisé au dessus, mais non pilotable. De base, je devais donc coder un programme sur un arduino Mega2560, permettant de piloter les moteurs inclus dans l'engin. il y a peu, j'ai mis de côté le robot démineur pour me concentrer sur les robots en général. C'est donc de là que m'est venu l'idée de coder un système modulable, et adaptable à tous types de robots.

Communication avec OBR

La communication avec OBR suit une norme qui lui est propre, sous la forme : "[AdresseEnvoyeur|AdresseDestinataire]OBR_COMMANDE-PARAMETRES\n" Le protocole est assez strict, mais simple :

- La communication se fait via les ports séries, en 57600 bauds.
- Le dialogue se fait via des commandes, avec (au max) trois paramètres, et deux adresses (envoyeur et destinataire)
- Toutes les commandes ont un retour, même si ce n'est qu'un "OK"
- Il n'y a aucun espace dans une ligne
- La commande se termine toujours par un retour à la ligne ('\n')
- Les paramètres sont séparés par des tirets ('-')
- Un message peut passer par plusieurs cartes, il y a un système de routage, d'où l'obligation des adresses
- Seul la commande de demande de connexion n'a pas d'adresse, mais la réponse en a une (On ne sais pas à qui on se connecte, mais on sait qui nous répond)
- Le réseau peut se constituer d'un maître, épaulé par deux esclaves (pour augmenter le nombre de PIN), une télécommande, et un PC.
- Il y a donc 5 adresses : 1=PC, 2=Télécommande, 3=Maître, 4=Esclave1 et 5=Esclave2.
- Il ne peut pas y avoir deux périphériques du même type, comme deux PC, ou deux télécommandes.
- Le maître, l'esclave1 et l'esclave2 sont distincts, et ne peuvent pas changer (définit à la compilation). De ce fait, les adresses des PIN allant jusqu'à 255, on peut déterminer le N° du PIN (pour 234, c'est 34) et le N° de la carte (pour 234, c'est l'eclave2).
- Les connexions peuvent se faire en série, les commandes seront routées pour arriver à bon port.

Exemple de connexion entre le PC et le maître : PC <===========> {Esclave2 <=> esclave1 <=> Maître} : L'esclave2 recevra le message, le transmettra à l'esclave1, qui le transmettra au maître. c'est le chemin inverse que fera la réponse.

Ce qu'OBR sait faire pour le moment

Pour le moment (version 0.6), OBR gére les connexions entre arduinos, télécommandes et PC. Les commandes sont fonctionnelles, et on peut connaître le nom du robot, ainsi que sa version d'OBR installé. Une session administrateur est gérée, on peut l'utiliser (mot de passe par défaut : 2560) pour configurer le robot. Lorsque l'administrateur se connecte, la LED 13 s'allume pour dire que la configuration est susceptible d'être modifiée, sauf si la sortie 13 est utilisée. On peut lui configurer des moteurs, servomoteurs, sorties digitales et des entrées, ainsi que les MIN et MAX des sorties PWM et des entrées analogiques. La configuration est enregistrée en EEPROM, et est inchangée après un redémarrage. On peut lier une sortie (PWM ou digitale) avec 1 PIN analog, et 3 PINs E/S. Ces liens permettent de sécuriser une sortie, en lui empêchant de bouger si un des liens lui interdit (ex : un moteur peut tourner jusqu'à ce que le capteur sur A0 soit à plus de 80%, ou que l'entrée sur le PIN 10 soit à 1). Pour augmenter le nombre de PIN, On peut mettre jusqu'à 3 arduino (un maître et deux esclaves) reliés via les ports séries, la communication entre les cartes se fait toute seule grâce au protocole de communication OBR3. Pour le moment, OBR v0.6 ne sait pas utiliser les PIN des autres cartes (Maitre, Esclave1 et Esclave2).

Ce qu'il sera sensé faire plus tard

Dans le futur (version 1.0), OBR devra toujours gérer les connexions automatiquement et à chaud, mais le maître saura aussi gérer les deux esclaves (si présents), pour piloter ses entrées/sorties. OBR devra gérer les batteries, et se désactiver si nécessaire. Un système de WatchDog fonctionnera sur les ports séries, pour détecter la déconnexion d'un périphérique.

TeC'OBiR (Terminal Configuration pour Open Bidouille Robot), un programme PC pour configurer OBR

Le Terminal TeC'OBiR est codé en C, en console, et permet de communiquer aisément avec un arduino tournant sous OBR. TeC'OBiR intègre la bibliothèque de communication OBR, ce qui lui permet de dialoguer avec OBR (un maître, un esclave ou une télécommande) facilement. Lorsqu'on lance TeC'OBiR, les 10 premiers ports séries sont scannés en boucle, tant qu'une carte sous OBR n'est pas connectée. Les avantages d'utiliser TeC'OBiR plutôt qu'un terminal série quelconque, sont multiples :

- La connexion se fait toute seule en arrière plan, aucune commande n'est à taper
- Une fois connectée, on a le nom du robot, et la version d'OBR installée.
- Les commandes que l'on tape sont mises en norme : Toutes les lettres sont mises en majuscule, les espaces sont remplacées par des tirets, les adresses sont automatiquement ajoutées, ainsi que le "OBR_" au début de la commande.
- L'adresse est automatiquement définie selon la carte sur laquelle nous sommes connectés (maître, esclave, télécommande).
- Il est possible de choisir sont destinataire en ajoutant 'x:' avant la commande, x étant variable (p: pour le PC, t: pour la télécommande, m: pour le maître, e1: pour l'esclave1 et e2 pour l'esclave2).
- Si le mot de passe est 2560, la connexion en tant qu'administrateur se fait automatiquement, sinon, le mot de passe est demandée, pour une connexion automatique.
- Entre chaque commande envoyée, le programme vérifie la connexion avec OBR, et se déconnecte si la carte est débranchée.

Exemple de commandes qu'on peut écrire avec TeC'OBiR, pour connaître le nom du maitre :

- "[1|3]OBR_NOM\n"
- "OBR_nOm"
- "nom"
- "m:nom"

Code Arduino

Le code de la version en développement, sur GitHub : ici.

Code C de TeC'OBiR

Bibliothèque de communication OBR en C

Une bibliothèque a été créée pour faciliter la communication entre un programme codé en C, et un arduino tournant sous OBR. Cette bibliothèque est dépendant d'une autre, qui gère les connexions séries. Les deux bibliothèques (OBR.h et Serial.h) sont disponible au téléchargement, [github.com/Aglesia/OBR/blob/master/Dev/Bibliotheque_C ici].

Code OBR.h, sur GitHub


Le code de OBR.c, sur GitHub


Des suggestions ? Des conseils ? Je suis preneur ;)

Code de TeC'OBiR

TeC'OBiR utilise la bibliothèque OBR pour fonctionner...

Code : main.c, sur GitHub.

Changelog

OBR

0.1 :

- Première version, non fonctionnelle

0.2 :

- Mise en place du système de question/réponse, sous forme de commande de type OBR_COMMANDE-PARAMETRE1-PARAMETRE2-PARAMETRE3
- Ajout du mode administrateur
- Ajout des modes configuration et pilotage
- Première version du calcul du niveau de batterie
- Passage du port série en 57600 bauds
- Ajout du mot de passe, et son système de réinitialisation à "2560"

0.3 :

- Utilisation du protocole de communication OBR3
- Ajout du système d'authentification sur les ports série
- Ajout de la prise en charge des cartes d'extension (jusqu'à deux cartes d'extensions) via RS232 (Mais les cartes seront inactives, sauf pour demander la liste des connexions externes)
- Ajout du mappage réseau, permettant de relier le PC, télécommande et les cartes d'extensions sur n'importe quel port série (de n'importe quelle carte d'extension)
- Ajout du système d'adresse dans les commandes, permettant le routage des données à travers les cartes ([1|2]OBR_...)
- Ajout des constantes de compilation pour définir le nom du robot, et son rôle (maître/esclave), ainsi que le type (MEGA, UNO...)
- Ajout de la détection de déconnexion série, et déconnexion auto de l'administrateur

0.4 :

- Ajout des fonctions de gestion des E/S dans le noyau
- prise en compte des limites imposées dans les sorties PWM
- Mise à jour auto des valeurs des E/S
- Réorganisation du code et séparation des fonctions du noyau, des autres fonctions
- Ajout de deux fonctions (user_setup et user_loop) modifiable par l'utilisateur

0.5 :

- Mise en place des codes d'erreur dans le noyau du système
- Mise en place des fonctions de copie RAM->EEPROM et EEPROM->RAM, contenant les données de fonctionnement (liste des moteurs, capteurs...)
- Ajout des fonctions de mise en place des périphériques (moteurs, capteurs...)
- Sauvegarde des PIN E/S pour les restaurer au boot
- Ajout d'une commande de redémarrage du système
- Ajout de toutes les commandes de pilotage

0.6 :

- Redémarrage d'un moteur en douceur après un arrêt brutal (Lien qui bloque le moteur d'un coup)
- Suppression du système de blocage de la carte, remplacé par un redémarrage complet du système
- La remise à 0 du mot de passe ne bloque plus l'arduino
- Changement de la gestion des commandes, chaque commande enregistre sa réponse et le système la retourne à la fin des commandes (permet de dire quand une commande est inconnue)
- Séparation des commandes de pilotage et de configuration
- Ajout de la gestion des liens, au sein d'une carte
- L'état de l'activation du watchdog est enregistré en EEPROM, et est restauré au démarrage
- Renommage des fonctions du noyau

0.7 :

- Changement de la gestion des numéro de PWM : maintenant on envoie son n° de PIN (et non plus n°PWM) en paramètre
- La liaison entre le PIN 12 et 13 au démarrage réinitialise le mot de passe, mais aussi toutes les configurations
- WatchDog plus intelligent, évite la surcharge du réseau lorsque ça discute
- Correction du BUG qui laisse la LED 13 allumée quand on la déconnecte
- Déconnexion de l'administrateur lors du pilotage

0.8 :

- Utilisation de F() pour économiser de la RAM, sur les String des différentes commandes
- Correction de Bugs empêchant la connexion entre deux arduino
- Refonte totale de la gestion des connexions entre les cartes
- Passage partielle au protocole OBR4
- Utilisation de la bibliothèque <Servo.h>
- Déconnexion automatique des PWM connectés sur les PIN verrouillés par la bibliothèque <Servo.h>
- Arrêt complet des moteurs lors de la déconnexion (Valeur_Voulue mis à 0, sauf pour les servomoteurs)
- Ajout de la valeur à 0 pour une sortie (peut être 0 ou 1)
- Watchdog non désactivable

0.9 :

- Ajout d'identifiants devant la commande pour connaître le type de message (réponse, commande, watchdog...)
- Gestion centralisée par le maître, on peut configurer une E/S d'une autre carte, en passant par le maître
- Mise en place des liens entre toutes les cartes
- Ajout des entrées/sorties virtuelles, qui se mettent à un automatiquement si tous les liens le permettent
- Doublage du nombre de liens (passage à 2 liens Analogique et 6 liens numériques

1.0 :

- Première version finale
- Contient toutes les commandes de pilotage
- Contient toutes les commandes de configuration
- Utilise le protocole OBR4, non compatible OBR3 (utilisé jusqu'à la v0.7)
- Le système de WatchDog des connexions séries est fonctionnel
- On peut brancher et débrancher une carte du réseau à chaud
- On peut connecter une télécommande OBRoC sans problème
- Entièrement compatible avec TeC'OBiR 1.5 et supérieur

Pour le moment, la dernière version est la 0.8.

TeC'OBiR

1.0

- Utilise le protocole OBR
- On peut enlever "OBR" et "OBR_" au début de la commande
- Tous les espaces sont remplacés par des tirets
- Commande 'HELP' affiche l'aide et les commandes existantes lors de la création de la version 1.0
- Commande 'EXIT' Ferme la connexion et quitte le programme

1.1

- La casse est automatiquement mise en majuscule sur les commandes envoyées
- Ajout de la couleur bleue
- Ajout de la commande 'VERSION' qui affiche la version du programme
- Connexion automatique en essayant les 10 premiers ports en boucles
- Détection de la déconnexion de l'arduino
- Ajout de la connexion admin
- Passage au baud-rate de 57600 bauds.

1.2

- réécriture du noyau
- Adaptation au nouveau protocole OBR 0.3
- Prise en compte des adresses

1.27

- Désactivation automatique du WatchDog inclus sur l'OBR 0.37 et +

1.3

- Ajout du choix de l'adresse destinatrice (Commande sous forme "add:OBR_COMMANDE-PARAMS" ex : pour connaitre le nom du maître, "M:OBR_NOM")
- Ajout de l'adresse émettrice dans la réponse
- Séparation du code TeC'OBiR et de la bibliothèque OBR_Communication

1.4

- Passage à l'essai des 50 premier ports séries
- Adaptation partielle au protocole OBR 4, qui inclus un watchdog obligatoire sur la connexion série
- Ajout d'un thread pour la gestion du watchdog

1.5

- Adaptation complète au protocole OBR 4

1.6

- Prise en charge des fichiers de config .map
- Peut être ouvert avec, comme paramètre, un fichier .map. La configuration auto se fera dès que la connexion est effectuée

Pour le moment, la dernière version est la 1.3, le chien de garde est désactivé à la connexion, pour éviter les déconnexions intempestives. (il faudrait mettre moins de 5 secondes à taper une commande, et ne jamais s'arrêter...)

Liens de téléchargements

Un compte a été ouvert sur GitHub pour centraliser les fichiers sources...

Documents techniques + notices

Notice d'utilisation d'OBR

Binaires finalisées

Open Bidouille Robot (à compiler sur un arduino)

OBR v0.6

Terminal Console for Open Bidouille Robot

TeC'OBiR Win32 1.3 TeC'OBiR Linux 1.3

Open Bidouille Robot Contrôleur Arduino (à compiler sur un arduino)

Open Bidouille Robot Contrôleur PC

Changelog

Changelog OBR Changelog TeC'OBiR

Lien GitHub

GitHub Open Bidouille Robot