@Argo96 did some work to simplify using acados inside a ROS2 node, see this post below:
Although I am not very familiar with ROS, I think it would be nice to be able to render templates for a ROS2 node directly with the solver creation very similar to how we do it for the Simulink wrapper.
I am not sure, if someone or who in particular has time and motivation to do so.
However, I believe the following could make sense:
Migrate the templates for the ROS2 node in ros_acados_nodegen, to use the tera syntax instead of jinja2 and move them to a subfolder of c_templates_tera inside acados.
Check what additional context is needed to render the templates. Add this optional to the AcadosOcp description. Similar to the simulink_opts, there could be ros2_opts.
Bonus: add test, workflow documentation
@Argo96 what do you think?
In general, I believe that this migration could help a lot of practitioners. Plus an integration with tests would ensure that the workflow is compatible with future acados versions.
Feedback from potential users or developers in this direction would be highly appreciated
yes i totally agree Currently I actually have the time to do so and i will look into it. Although I am not familiar with tera yet. My approach is more like an entry point where we still need to specify a lot. The message handlers are not implemented as well as vizualisers etc. I am also using a timer to run the control loop at a specific frequency which is not very common. I think especially in realtime use cases, people use Nav2 Controllers or ros2 controllers and don’t use nodes. So the question remains then where to start
How would the framework look like, do we build it such that we can modify the generate code and not just use it like we do with the acados generated code (or at least I use it like that). It is hard to create a completely working node that runs from scratch, without a ton of new options which would just be confusing. Furthermore, we have the build process of the ros package, where I don’t know how it could be possible to seperate from the c generated code and created libs. Maybe I lack knowledge of how the build processes work with colcon.
In general a very great idea and I am open for design ideas here.
just wanted to point you to this repository here, which also implements generating custom ros2 ocp plugins from acados: GitHub - ICube-Robotics/acados_solver_ros2: Helper packages to use the Acados solver for non-linear optimization in ROS2 applications.
I am not related to this project and just found it two weeks ago but they handle the integration into ROS2 quite well. They also provide a vendor package to seamlessly integrate acados into the ros build system and it seems like the plugin can also be used within the ROS2 control toolchain. It might be helpful for you.
thanks a lot for pointing to this!
I was not aware of this indeed!
I think it is nice to support ROS2 node generation in acados itself.
Josua already put in a lot of work to create acados PR 1622. @Argo96 did you know about this repo?
I will write an email to Thibault, he might have some good feedback on the current implementation.
no i didn’t know about this repo. It looks quit nice actually. However, I already spend some time implementing at least a node. A lifecycle node and a ros2/nav2 controller is missing, but if someone is intreseted in implementing this, please go ahead. I already added options for these future case.
I did split up the solver and the simulator in acados fashion and I also tried to create a mapper that maps e.g.: the ocp state to the sim state. This mapping is needed if you use sim and ocp together because the interfaces are also automatically created. Here, I can also build theoretically an option to use exactly the same interface, then we would not need a mapper. However, with the mapper I am still sitting on the automatic config implementation, such that i can just throw in my ocp and sim and it just works. Actually now i got the idea. Currently I was doing it with the ocp dicts, which may be nice, but I think its better to do it with the instances automatically damn lost that i didn’t got to this earlier.
I think the beauty of the code I wrote is that it is directly generated next to c_generated_code and ready to use, without any functions or variables in the classes that create some kind of overhead. Maybe I missed some optimization steps, but if so pelase give me hints on this. Thanks
Currently I actually have the time to do so and i will look into it. Although I am not familiar with tera yet. My approach is more like an entry point where we still need to specify a lot. The message handlers are not implemented as well as vizualisers etc. I am also using a timer to run the control loop at a specific frequency which is not very common. I think especially in realtime use cases, people use Nav2 Controllers or ros2 controllers and don’t use nodes. So the question remains then where to start 
