The walking-controllers project is a suite of modules for achieving bipedal locomotion of the humanoid robot iCub.
The suite includes:
- Walking_module: this is the main module and it implements all the controller architecture that allows iCub to walk.
- Joypad_module: this module allows using the Joypad as reference input for the trajectory generated by the Walking Module
- WalkingLogger_module: an module that can be useful to dump data coming from the Walking Module
- 📙 Some theory behind the code
- 📄 Dependencies
- 🔨 Build the suite
- 💻 How to run the simulation
- 🏃 How to test on iCub
This module allows iCub walking using the position control interface. It implements the following architecture where two controller loops can be distinguished:
- an inner ZMP-CoM control loop http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4359259&tag=1;
- an outer DCM control loop:
- model predictive controller;
- reactive controller.
Two different inverse kinematics solver are implemented:
- a standard non-linear IK solver;
- a standard QP Jacobian based IK solver.
A paper describing some of the algorithms implemented in this repository can be downloaded here. If you're going to use the code developed for your work, please quote it within any resulting publication:
G. Romualdi, S. Dafarra, Y. Hu, D. Pucci "A Benchmarking of DCM Based
Architectures for Position and Velocity Controlled Walking of Humanoid Robots",
2018
The bibtex code for including this citation is provided:
@misc{1809.02167,
Author = {Giulio Romualdi and Stefano Dafarra and Yue Hu and Daniele Pucci},
Title = {A Benchmarking of DCM Based Architectures for Position and Velocity Controlled Walking of Humanoid Robots},
Year = {2018},
Eprint = {arXiv:1809.02167},
}
- YARP: to handle the comunication with the robot;
- iDynTree: to handle the robot kinematics;
- iCubContrib: to configure the modules;
- osqp-eigen: to solve the MPC problem;
- qpOASES: to solve the IK problem;
- Unicycle footstep planner: to generate a trajectory for the DCM;
- Gazebo: for the simulation (tested Gazebo 8, 9 and 10);
- Catch2: to compile the tests.
git clone https://github.com/robotology/walking-controllers.git
cd walking-controllers
mkdir build && cd build
cmake ../
make
[sudo] make install
Notice: sudo
is not necessary if you specify the CMAKE_INSTALL_PREFIX
. In this case it is necessary to add in the .bashrc
or .bash_profile
the following lines:
export WalkingControllers_INSTALL_DIR=/path/where/you/installed/
export PATH=$PATH:$WalkingControllers_INSTALL_DIR/bin
export YARP_DATA_DIRS=$YARP_DATA_DIRS:$WalkingControllers_INSTALL_DIR/share/yarp
-
Set the
YARP_ROBOT_NAME
environment variable according to the chosen Gazebo model:export YARP_ROBOT_NAME="icubGazeboSim"
-
Run
yarpserver
yarpserver --write
-
Run gazebo and drag and drop iCub (e.g. icubGazeboSim or iCubGazeboV2_5):
gazebo -slibgazebo_yarp_clock.so
-
Run
yarprobotinterface
YARP_CLOCK=/clock yarprobotinterface --config launch-wholebodydynamics.xml
-
Reset the offset of the FT sensors. Open a terminal and write
yarp rpc /wholeBodyDynamics/rpc >> resetOffset all
-
Run the walking module
YARP_CLOCK=/clock WalkingModule
-
communicate with the
WalkingModule
:yarp rpc /walking-coordinator/rpc
the following commands are allowed:
prepareRobot
: put iCub in the home position;startWalking
: run the controller;pauseWalking
: the controller is paused, you can start again the controller sendingstartWalking
command;stopWalking
: the controller is stopped, in order to start again the controller you have to prepare again the robot.setGoal x y
: send the desired final position,x
andy
are expressed in iCub fixed frame.
Suppose that you want to run the Joypad application, called
WalkingJoypadModule
in the same machine where the physical device is
connected. The only think that you have to do is running the following command from
the terminal
YARP_CLOCK=/clock WalkingJoypadModule
The application will take care to open an SDLJoypad
device.
While, if you want to control run the WalkingJoypadModule
in a machine that is
different form the one where the phisical devce is connected. The
JoypadControlServer
-
JoypadControlClient
architecture is required. In details:
-
Run the
JoypadControlServer
device in the computer where the joypad is physically connected:YARP_CLOCK=/clock yarpdev --device JoypadControlServer --use_separate_ports 1 --period 10 --name /joypadDevice/xbox --subdevice SDLJoypad --sticks 0
-
Run the
WalkingJoypadModule
in the other computerYARP_CLOCK=/clock WalkingJoypadModule --device JoypadControlClient --local /joypadInput --remote /joypadDevice/xbox
The Joypad allows you to send all the rpc commands using the buttons. In details:
A
for preparing the robotB
for start walkingY
for pause walkingX
for stop walking
Before run WalkingModule
check if dump_data
is set to 1
Run the Logger Module
YARP_CLOCK=/clock WalkingLoggerModule
All the data will be saved in the current folder inside a txt
named Dataset_YYYY_MM_DD_HH_MM_SS.txt
You can change the DCM controller and the inverse kinematics solver by edit these parameters
You can follows the same instructions of the simulation section without using YARP_CLOCK=/clock
. Make sure your YARP_ROBOT_NAME
is coherent with the name of the robot (e.g. iCubGenova04)
Currently the supported robots are only:
iCubGenova04
icubGazeboSim
icubGazeboV2_5
Yet, it is possible to use these controllers provided that the robot has V2.5 legs. In this case, the user should define the robot specific configuration files (those of iCubGenova04
are a good starting point).
iCubGenova04
) to avoid such saturations.