You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 the setController method (currently part of EngineMultiRobot) 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 of Model should be removed, in favor of manually accessing name attribute of pinocchio_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.
The text was updated successfully, but these errors were encountered:
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.
duburcqa
changed the title
[core] Introduce system options.
[core] Get rid of system notion.
Sep 26, 2022
duburcqa
changed the title
[core] Get rid of system notion.
[core] Get rid of the confusing system hierarchy.
Sep 26, 2022
duburcqa
changed the title
[core] Get rid of the confusing system hierarchy.
[core] Get rid of confusing system hierarchy.
Sep 26, 2022
duburcqa
changed the title
[core] Get rid of confusing system hierarchy.
[core] Get rid of confusing system hierarchy
Oct 9, 2023
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.
The text was updated successfully, but these errors were encountered: