Journal de bord
S’applique à : Robot réel
Le robot garde en mémoire ses 256 derniers événements importants, datés, dans la mémoire flash de sa carte. Ils survivent à l’extinction : c’est ce qui permet de comprendre, le lendemain, ce qui s’est passé pendant la nuit.
Note
Le journal raconte le passé. Pour l’état du robot en ce moment, ce sont les diagnostics : voir Diagnostics.
Le lire
Depuis le Raspberry Pi du robot :
cd ~/ratbot_ws
./scripts/ratbot log
Ou depuis le PC, en disant quel robot — le numéro est alors obligatoire :
./scripts/ratbot log 1
La lecture prend de quinze secondes à une minute : la carte parcourt toute sa mémoire, puis envoie les lignes au Raspberry Pi. Rien ne s’affiche pendant ce temps, c’est normal.
376 2026-09-27 14:32:00 b112 boot 1094 0
377 2026-09-27 14:32:00 b112 watchdog restart 0 0
378 2026-09-27 14:32:13 b113 boot 1094 0
379 2026-09-27 14:32:13 b113 watchdog restart 0 0
380 2026-09-27 14:32:17 b113 micro-ROS agent connected 0 0
381 2026-09-27 14:33:59 b114 boot 326 0
382 2026-09-27 14:34:04 b114 micro-ROS agent connected 0 0
Chaque ligne se lit de gauche à droite :
colonne |
ce qu’elle dit |
|---|---|
|
le numéro d’ordre. Il ne fait que monter : un trou dans la suite veut dire que des lignes ont été perdues |
|
la date et l’heure, en temps universel (UTC) : en France, ajoutez 2 h l’été, 1 h l’hiver |
|
le numéro de démarrage : |
|
l”événement, en anglais — voir le tableau plus bas |
|
deux nombres qui précisent l’événement — leur sens dépend de l’événement, voir le tableau plus bas |
Note
Une ligne datée boot+12.3s au lieu d’une date a été écrite avant que le
robot ne connaisse l’heure — typiquement juste après un démarrage sans
réseau. Le temps indiqué est celui écoulé depuis la mise sous tension.
Les événements
Le journal ne garde que des changements : rien de périodique, aucune mesure. Un journal noyé dans la routine ne se lit plus.
Démarrages et plantages
événement |
signification |
les deux nombres |
|---|---|---|
|
la carte a démarré. C’est toujours la première ligne d’un tour |
le premier dit pourquoi, voir Pourquoi la carte a démarré |
|
la carte s’était bloquée, ou le Raspberry Pi ne lui répondait plus : le chien de garde l’a relancée |
— |
|
la carte s’est arrêtée sur une erreur au tour précédent |
le premier donne la cause : 1 pile de tâche, 2 mémoire pleine, 3 faute matérielle, 4 un composant a refusé de démarrer. Le second est un détail pour les développeurs |
Le Raspberry Pi
événement |
signification |
les deux nombres |
|---|---|---|
|
la carte a trouvé le Raspberry Pi |
— |
|
elle l’a perdu : Raspberry Pi arrêté ou redémarré, programmes relancés, câble débranché |
— |
|
écrit juste avant la ligne précédente : ce que la carte savait de la liaison au moment où elle est tombée |
le premier : erreurs sur le câble, cumulées. Le second : échanges de contrôle restés sans réponse. Zéro erreur sur le câble veut dire que les fils vont bien et que c’est le Raspberry Pi qui s’est tu |
|
des octets sont arrivés abîmés sur le câble |
le premier dit le type d’erreur (1 trame, 2 bruit, 4 débordement, 8 parité, additionnés). Le second : le total depuis le démarrage |
La sécurité
événement |
signification |
les deux nombres |
|---|---|---|
|
le bouton d’arrêt du robot a été enfoncé |
le premier : combien d’arrêts depuis le démarrage |
|
le robot a été réarmé |
le premier : combien de réarmements depuis le démarrage. Le second : comment — 0 par une commande depuis un ordinateur, 1 par 5 appuis sur SW1 devant le robot |
|
la batterie passe sous 10,2 V |
le premier : la tension en millivolts (10150 = 10,15 V) |
|
la batterie passe sous 9,6 V : le robot s’arrête et l’alarme sonne |
le premier : la tension en millivolts |
|
l”arrêt automatique a coupé le robot. Voir Arrêter et relancer le robot |
le premier : pourquoi — 1 renversé, 2 roue bloquée, 3 patinage, 4 choc. Le second : pour un renversement, l”inclinaison en degrés (180 = à l’envers) ; pour un blocage, la roue (1 gauche, 2 droite, 3 les deux) ; pour un patinage, l”écart entre les roues et le gyroscope, en centièmes de rad/s (47 = 0,47 rad/s) ; pour un choc, le pic en centièmes de m/s² (720 = 7,2 m/s²) |
|
le mode banc a été activé ou désactivé |
le premier : 1 activé, 0 désactivé. Le second : comment — 0 par une commande depuis un ordinateur, 1 par SW2 tenu sur le robot |
Le matériel
événement |
signification |
les deux nombres |
|---|---|---|
|
une roue ne répond plus |
les roues qui répondent après, puis avant : 3 les deux,
1 la gauche seule, 2 la droite seule, 0 aucune. |
|
une roue répond de nouveau |
pareil : après, puis avant |
|
un capteur ne répond plus |
les capteurs qui répondent avant, puis après, additionnés :
1 centrale inertielle, 2 température, 4 batterie. |
|
un capteur répond de nouveau |
pareil : avant, puis après. |
Note
Attention, l’ordre n’est pas le même : pour les roues c’est après, avant ; pour les capteurs, avant, après.
Le reste
événement |
signification |
les deux nombres |
|---|---|---|
|
des réglages ont été enregistrés (après un calibrage, par exemple) |
le premier : le nombre de sauvegardes réussies |
|
l’horloge de la carte a été remise à l’heure sur celle du Raspberry Pi |
le premier : de combien elle était décalée, en secondes. Le second : combien de remises à l’heure depuis le démarrage |
|
le journal a été effacé à la demande |
— |
Pourquoi la carte a démarré
Le premier nombre de la ligne boot dit ce qui a provoqué le démarrage.
Les valeurs courantes :
nombre |
cause |
signification |
|---|---|---|
254 |
mise sous tension |
on a allumé le robot, ou le courant a été coupé |
1094 |
chien de garde |
la carte s’est relancée toute seule. Toujours suivie d’une ligne
|
326 |
redémarrage demandé |
par un programme, ou lors d’une reprogrammation de la carte |
70 |
bouton de reset |
on a appuyé sur le bouton de reset de la carte |
Astuce
Une série de boot 1094 juste après une mise sous tension est
normale. Tant que les programmes du Raspberry Pi ne tournent pas, la carte
se relance toutes les quelques secondes, pour repartir d’un état propre.
C’est exactement ce que montre l’exemple plus haut, lignes 376 à 380 : deux
relances, puis la carte trouve le Raspberry Pi et tout se stabilise.
Des boot 1094 en plein fonctionnement, en revanche, méritent qu’on
s’y intéresse : regardez la ligne Pi link lost qui les précède.
Lire une histoire
Un extrait réel :
366 2026-09-27 09:38:16 b109 emergency stop 1 0
367 2026-09-27 09:38:20 b109 rearm 1 1
368 2026-09-27 09:42:24 b109 emergency stop 2 0
369 2026-09-27 09:42:28 b109 rearm 2 1
Deux arrêts d’urgence pendant le même tour (b109), à 4 minutes
d’intervalle. Chacun a été levé 4 secondes plus tard devant le robot, par
SW1 (second nombre du rearm à 1).
Un autre :
347 2026-09-27 08:53:07 b104 Pi link lost: serial errors, failed syncs 0 3
348 2026-09-27 08:53:07 b104 micro-ROS agent lost 0 0
349 2026-09-27 08:53:08 b104 Pi link: reception error 1 1
350 2026-09-27 08:53:16 b105 boot 1094 0
351 2026-09-27 08:53:16 b105 watchdog restart 0 0
La carte a perdu le Raspberry Pi, sans aucune erreur sur le câble (premier
nombre à 0) : les fils vont bien, c’est le Raspberry Pi qui ne répondait
plus — ses programmes redémarraient. L’unique erreur de trame qui suit
(ligne 349) est typique d’un Raspberry Pi qui relance sa liaison. Neuf secondes
plus tard, le chien de garde
a relancé la carte, comme prévu.
Et un exemple trouvé le jour même où le journal a été mis en service : deux
lignes wheel lost / wheel back à quelques secondes d’intervalle. Le
robot roulait normalement, les diagnostics ne montraient rien — la panne était
déjà repartie. Le journal, lui, l’avait gardée : un contact intermittent sur le
câble d’une roue.
Repartir de zéro
./scripts/ratbot log --clear # sur le robot
./scripts/ratbot log 1 --clear # depuis le PC
La première ligne du journal neuf indique qu’il a été effacé
(logbook cleared), avec la date : un journal vide sans explication
ressemble à une panne.
Combien de temps il garde
256 lignes, en anneau : au-delà, les plus anciennes disparaissent. En fonctionnement normal, un robot en écrit quelques-unes par jour : l’historique couvre donc des semaines. Un robot qui perd sa liaison en boucle remplira beaucoup plus vite, et c’est en soi une information.
L’état du journal lui-même est dans le bloc logbook des diagnostics : voir
Diagnostics.
Pour aller plus loin
Où le journal est stocké, son format, et la « boîte noire » qui garde la cause d’un plantage : voir la page « Journal de bord » de la documentation développeur.