Structure and packages for physical robot control software

Re: Structure and packages for physical robot control software

I am currently in the process of setting up the software to run controllers on the physical Solo 8 robot, and I was wondering if I could get some suggestions and discussions regarding the structure and which github packages to make use of.

I have already set up a PC running Ubuntu 18 patched with RT_PREEMPT, and I used the Machines in Motion lab ubuntu installation scripts to set up necessary dependencies, such as ROS2 and treep.

My lab will likely primarily experiment with controllers trained through deep reinforcement learning, where the resulting controller consists of a single neural network that takes robot state as input and outputs joint torques, or some variation of this idea. Therefore, the structure of the controller is simple and there is likely no need to combine many control submodules together, such as a trajectory planner, tracking controller, inverse dynamics solver, etc.

Therefore, my current plan is to use the machines-in-motion/real_time_tools package to create real-time enabled threads, and to call the open-dynamic-robot-initiative/odri_control_interface package within it to communicate with the robot. Conceptually, the robot script would look like:

import odri_control_interface
import real_time_tools
import neural_network_controller

main script:
	initialize communication with robot

	real time loop:
		sensor_data = robot.get_sensor_data()

		joint_torques = neural_network_controller.get_torque(sensor_data)


		real_time_sleep_milliseconds(1.0) # ensure 1kHz control loop

	end real time loop
end main script

In fact, I already set up a simple template for this setup on this github repo: GitHub - yunifuchioka/robot_script

Most notably, I am choosing not to use the dynamic graph framework, as its ability to stitch together different control modules at runtime seems overkill for our use case. Additionally, reducing the dependency on packages maintained by other organizations may be useful for us in terms of learning how to use it, debugging, etc.

I am also choosing not to use the open-dynamic-robot-initiative/solo package, and instead opting to use odri_control_interface as the robot communication API. This is because the solo repo has support for functionality that we don’t need, such as dynamic graphs, TI evaluation boards, and slider inputs, and the core functionality of initializing an odri_control_interface/robot with the parameters for solo8 does not seem too hard to reimplement.

I wanted to check with someone familiar with the codebase whether this plan seems reasonable, and whether I misunderstood anything about how the repos from ODRI and MIM work. Any suggestions and discussions would be hugely helpful.

hi yunifuchioka,

your choices make absolutely sense for what you are intending to do.

Please let me know in case you run into any issues.


1 Like

Hi jviereck,

That’s great–thank you very much!! It’s very valuable for us to get feedback directly from the designers of the robot.

I’ll be sure to follow up with any issues that I encounter.