Closed duburcqa closed 8 months ago
After thinking about it. I suggest requirement naming robots, in the exact same way as sensors and motors. Being able to identify uniquely a robot after getting it without having to move around a reference to the engine is very convenient. Anyway, it does make sense that each robot owns its identity. Note that the name of the robot would be different from the "name" that can be found in the pinocchio model itself. It is not a problem because it refers to the version of the mechanics. Both are relevant, the former is about the unit, the latter is about the platform.
Currently, the sensor and controller update periods are set at engine level, while it should be specific to every robots. It would be natural to move the controller as an attribute
Robot
, and request the user to thesetController
method (currently part ofEngineMultiRobot
) to set it on-the-fly.This way, the notion of "system" can be removed altogether and replaced by "robot". The engine would still be responsible for calling the controller and its internal dynamics itself, but it is already the case for any physical quantity anyway.
To avoid any conflict or confusion,
getName
method ofModel
should be removed, in favor of manually accessingname
attribute ofpinocchio_model
. The robots themselves as no name anymore apart from the ones the engine is giving to them to distinguish between them. This mechanism is different from the sensors and motors and maybe should be refactor. It seems more rationale to identity them from the name their owner is giving them since they are basically all identical.In the same vein, registered forces should be named. Everything should return lists ordered by motors, sensors or rotor instead of a mix of unordered dicts and list as it is currently the case.