Synchronisation des robots

Au vu de l'architecture actuellement présente, chacun des robots aura sa base de connaissances du monde extérieur. Il est intéressant dans ce cas de prendre en compte les divergences entre les robots synchronisés.

Certaines propriétés sont spécifiques au robot les détenant (rotation des roues ou position d'un actionneur par exemple), alors que d'autres définissent le monde extérieur et sont donc utiles aux deux.

Il va de soi qu'on partagera uniquement les propriétés non-spécifiques.

Fonctionnement des mises à jour

Les mises à jour seront effectuées par intervalles de temps fixes, pour éviter ainsi de surcharger le réseau par une mise à jour continue.

Partage "normal"

Un partage est considéré comme “normal” quand une modification d'une propriété a eu lieu au cours d'un intervalle de temps, chez un seul des robots.

Dans ce cas, la mise à jour se propage normalement en modifiant la propriété avec sa nouvelle valeur.

Partage "conflictuel"

Un partage est considéré comme “conflictuel” quand une modification d'une propriété a eu lieu chez plus d'un robot au cours d'un intervalle de temps.

On ne peut par prendre la modification la plus récente, car les intervalles de temps seront de l'ordre des dizaines de millisecondes, ce qui est plus petit qu'un décalage d'horloge entre deux machines. La solution serait de trouver ce décalage et de se baser là-dessus, mais c'est une tâche supplémentaire assez complèxe et n'apportant que peu de retours.

Au final, dans ce cas on choisira de prendre la dernière mise à jour effectuée par un des robots (qui sera donc maître), mais en prenant uniquement les mises à jour, et non les valeurs existantes.

L'idée est principalement d'associer à une modification 1) l'auteur de la modification, et 2) la date de la modification (intervalle de temps). Pour résoudre le conflit en prenant en compte les modifications, mais en maîtrisant ce conflit en choisissant un “auteur dominant”.