Super article, merci beaucoup !
Je ne connaissais pas du tout DBUS, très interressant (et l’article est génialement écrit 🙂 )
Pour info, dans le meme genre, il y a la couche de base de ROS.
Très similaire dans l’approche bien sur, encore que ROS pousse pour l’utilisation de Topics (i.e. des bus multi-producteurs/subscribeurs) plutot que des Services (i.e. RPC) chaque fois que c’est possible, pour limiter encore le couplage : cf les concepts runtime de ROS.
M’enfin quelque soit le bus utilisé, un choix crucial pour l’interopérabilité et la longévité est celui du contenu des messages.
Beaucoup de tentatives de standardisations de ce coté, depuis Player jusqu’à ROS, pour un certain nombre de concepts.
Donc tant qu’à faire, lorsqu’on cherche à definir un nouveau message (surtout avec des concepts ’standards’ tels que des coordonnees, des angles, des consignes d’accélération, etc.), un petit tour de ceux qui existent aide parfois. Par exemple les messages de base de ROS.
Super article, merci beaucoup !
Je ne connaissais pas du tout DBUS, très interressant (et l’article est génialement écrit 🙂 )
Pour info, dans le meme genre, il y a la couche de base de ROS.
Très similaire dans l’approche bien sur, encore que ROS pousse pour l’utilisation de Topics (i.e. des bus multi-producteurs/subscribeurs) plutot que des Services (i.e. RPC) chaque fois que c’est possible, pour limiter encore le couplage : cf les concepts runtime de ROS.
M’enfin quelque soit le bus utilisé, un choix crucial pour l’interopérabilité et la longévité est celui du contenu des messages.
Beaucoup de tentatives de standardisations de ce coté, depuis Player jusqu’à ROS, pour un certain nombre de concepts.
Donc tant qu’à faire, lorsqu’on cherche à definir un nouveau message (surtout avec des concepts ’standards’ tels que des coordonnees, des angles, des consignes d’accélération, etc.), un petit tour de ceux qui existent aide parfois. Par exemple les messages de base de ROS.