-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Custom controllers: base interfaces, plugins, and fixed-base Computed Torque example #167
Custom controllers: base interfaces, plugins, and fixed-base Computed Torque example #167
Conversation
4e67701
to
6c293ee
Compare
Ready to be reviewed @traversaro @paolo-viceconte @raffaello-camoriano |
6c293ee
to
6a48729
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is quite nice. I think a short description of the architecture somewhere (even something extremly simple for example a sentence that says that controllers are mapped to ignition-gazebo's Systems, and that input/output interconnections are realized by reading from and writing to components buffers) and some examples or tests would be great.
My only question is: both whole body and joint level controllers get updated during the PreUpdate
. As far as I understood from your previous comments at the moment in the ignition-gazebo documentation there is no information or guarantee on when which one will be actually executed before, but in your practical experience did you checked what is the execution order?
6a48729
to
5bcaf88
Compare
I just gave it a try. I have only the This means that if I insert first
I validated this behaviour switching the order of plugins loading.
I agree that it would be nice having some documentation. I have almost ready a simple Sphinx-based website. I will add this piece of information there. I already have tests running locally for controllers and also part of ScenarI/O APIs. I will open a PR to add them all together. The final PR |
And the order of plugins loading is given by the order in which they are found in the SDF file? |
I load the plugins from Python code, not SDF. I'm quite sure though that you would get the same behaviour also from an SDF file. |
I remember I read long time ago a discussion about it, I managed to find it: ignitionrobotics/ign-gazebo#100 Edit: now that I read that PR, I realize that the problems I faced when I tried to implement the non-deterministic mode in #158 were strongly related to this concurrent access to components and the solution prosed in that PR could solve them. I was thinking to a protection with mutexes, but I couldn't find any simple implementation. I believe that having support directly form upstream would greatly simplify it. |
5bcaf88
to
a64ba4b
Compare
a64ba4b
to
9a9f3b2
Compare
Cleaned the history. Merging. |
This PR adds the initial support to insert custom controllers in the simulation as model plugins.
Controllers could inherit from the following interfaces:
scenario::controllers::Controller
Used to initialize / step / terminate a controller.scenario::controllers::SetJointReferences
Used to set the joint references.scenario::controllers::SetBaseReferences
Used to set the base references.scenario::controllers::UseScenarioModel
Controllers could optionally use internally ascenario::gazebo::Model
object to get / set data. This interface streamlines how the pointer to the model object is handled.An example of a fixed-base controller implemented with some of these interfaces is
scenario::controllers::ComputedTorqueFixedBase
.Then, there is a Gazebo plugin
scenario::plugins::gazebo::ControllerRunner
that can be inserted during runtime and executes controllers that implement those interfaces. The configuration of the controller is passed from the plugin as an XML configuration.Right now we do not load the controller classes as plugins (since it would be a plugin loading a plugin). In order to keep things simple, I have implemented a controller factory that for the moment allows executing only the controllers part of the project.
Note that this design choice allows using the custom controllers also with ScenarI/O APIs implemented for a real robot (e.g. for YARP or ROS). In that case, a secondary thread / process will run the controller, and depending about how the ScenarI/O APIs will be implemented, it will read the references from either shared memory of pub-sub. After each call, the controller will send the command to the robot likely through a middleware.