Functionality for the robot implemented in ROS?

Software
1

Are the different gaits for the robot implemented and tested in ROS? If not, could you maybe summarize your software stack for how you implement different functionality for the robot? My team has not been able to find documentation to get started on that :slight_smile:

Any help is much appreciated?

1 Like
2

Our software stack is based on the dynamic_graph concept.
One need to generate a graph of control dynamically using python and execute it in real-time.
Hence our software strategy is the following:

  • implement a prototype in python/simulation (pybullet)
  • translate it in C++
  • embed it in the dynamic-graph
  • execute it on the robot.

We have access and are compatible with all Stack-of-Tasks software (https://github.com/Stack-of-tasks)

Our public repos are available at:


I sadly report that the documentation is not good enough currently…
Though you can start by having an idea on how the conexion between the controller and the robot drivers is made by reading thoroughly this documentation:

More information on how to build and use robot are upcoming in:


2 Likes
3

I am just curious as to why your team did not decide to use ROS?

4

In your sentence ROS could mean anything,
are you talking about:

  • creating a control loop using ros topics? In this case it is not possible for us as we use 1 kHz control loop and real-time control. Ros topics are not real-time.
  • Using ros-control (hardware/control interface)? We do not as some of our sensor are not yet supported and we want to manage all the stack from firmware driver until control.
  • Using a Ros simulator? We do not use Gazebo we use Pybullet.
  • Else? …

Finally we DO use ROS inside our interface (dynamic_graph_manager) in order to handle the asynchronous calls to the hardware or controller: user interface.
We also allow the dynamic-graph to subcribe and publish to ros-topics so our control architecture is Ros compatible.

2 Likes
5

I am a little interested in why you decided on a 1 kHz control loop. Is it a requirement for the solo8?

6

The fact that we need a 1kHz real time control loop comes from the fact that we control directly the current on all the BLMC robots (Solo(s), Bolt, Trifinger, …).
The current being more or less homogeneous to torques in terms of dynamics we need to be able to capture it’s evolution.
Hence a 1kHz control loop.
More over if we want to tackle the torque reple on the motors we benefit from implementing a position PD on board of the udrivers at 10kHz.

I hope this clarify why ROS as user interface but why NOT ROS as a controller.

2 Likes