ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

ROS2 + RPi3+ dynamic walking robot

The project I present here is the continuity of a personnal project I started 14 years ago about making a dynamic walking robot in the passive philosophy and open source.
Until now, the software for these robots where based on python 2.7 scripts with a unique control loop.
I use ROS1 professionnaly already as roboticist.
The new project I start uses ROS2 on a RPi3 with Ubuntu server installed. The motors are Dynamixel piloted by USB2AX dongle. The sensors are managed by an Arduino Nano Every connected to RPi via UART.


Here are the links for the different parts of the project still in evolution :

The Arduino Firmware repository is here : Arduino Firmware
The ROS2 source repository is here : Lapin lab sources
The NodeJS source repository for web control : Web control sources
The playlist with experiments : Youtube playlist

The philosophy is to study an easy way to pilot dynamic and low cost biped robots. I know this is a big challenge but it is very exciting even if I never succed. I did understand a lot of things thanks to this long term project.

I started my study on this subject in the Delft Biorobotic Laboratory that is why I want to understand walking and make it mechanical and soft at the same time.

The structure of the ROS2 code

All the drivers of the sensors are gathered on an external Arduino Nano with a specific firmware. The sensors are

  • an IMU (MPU6050) for which I use the DMP hardware to compute pitch and roll angles. It is placed on the upper body. The roll and pitch rates are computed a posteriori so that there are consistent with the angle measurement.
  • two resistive force sensors on each foot (front and back) read by a HX711 analogic reader
  • A start button to make a race

All the motors are Dynamixel, with a USB2AX dongle and the Python Pypot library. The driver has the inverse kinematic of the parallel mechanism

The control of the robot is made by a web based interface connected to zeromq protocol to send and receive very simple messages. This is done by a zmq driver which agreggate all the states of the robot.

This node makes the link between the others nodes, security and web control. The controller is based on a finite state machine. This is the part to be improved.

Custom messages to support ROS2 communication

1 Like

The first tests of walking were done in a single Python 2.7 script without any way to save data bags to analyse the dynamics and with difficulty to modify tunings. This is why I decided to switch to ROS2.

I did the install of ROS2 Foxy (base) on Ubuntu-Server 20.04 on a Raspberry Pi 3b.
The install is done quite easily (except for the headless wifi which is not well documented)
The robot is connected to my laptop Ubuntu 20.04 with ROS desktop. The topics are communicating between the two hardwares.

I did follow the tutorials to create my first ROS2 nodes.
I also installed NodeJs12 for the web interface

The first start led to spurious crashes of the RPi (unable to connect via SSH). The thanks to the work on turtlebot3 there were this issue resolution

I first started with a sampling time for each nodes at 20ms but the Raspberry Pi hangs after 2-3minutes.

I wanted to publish my project here to share the project, the issues and happy moments of robotics :slight_smile:

And also to get help if possible.

1 Like

Neat project, Thomas!

The install is done quite easily (except for the headless wifi which is not well documented)

Take a look here and here, hope that helps a bit. It’s based on the instructions, but a plain vanilla install of the latest Ubuntu and the latest ROS simplifies things quite a bit.

The first start led to spurious crashes of the RPi (unable to connect via SSH).

In addition to the kernel issue you mentioned, there’s also a cloud-init bug that hits only on a wirelss first boot. Net effect is that the wireless interface is not brought up on first boot even if it’s properly configured in network-config. No first-boot networking tasks complete (software installations, adding ssh keys, etc). The wireless interface will come up after a reboot first boot tasks will no longer run. If you reboot too quickly the cloud-init tasks may not be completed–particularly creating ssh server keys–and leave your pi in an awkward state.

I find a headless boot is easiest when I just let the pi rest for at least five minutes and reboot before connecting with ssh. It’s also possible to add a cloud-init startup task to restart the wireless interface if you have a more complex setup.


Thanks to a friend, I have new mecha. Soon the BOM !

1 Like

Here is the partial BOM for the robot, I still have to draw electronic schematics.