Hexapod

To Do List

Main objectives:

• Jump around! (Rokus and Marcello)

Secondary objectives and tweaks:

• Rewrite everything in one OROCOS component
• Use Matlab/Simulink
• Use fifth order reference trajectories for gait implementation (Marcello) -done
• Create reference for jumping (Rokus) - done
• Improve ground contact robustness
• Improve height estimation
• Create centralized kinematics and reference components (without need for demux and mux) for better synchronisation between legs
• Measuring if the software is now really running real time using an oscilloscope
• Attain some namespace convention and make sure all existing software uses this convention
• Convert spatial reference velocity and acceleration to joint reference velocity and acceleration for use in feedforward

Furthermore:

• Document all existing Orocos components with input, output and algorithm
• Document launch and deploy files, including their use and started components. Delete obsolete launch and deploy files.

Installation

The installation assumes that Ubuntu 12.04 LTS is installed. If not you should install an Ubuntu version. Notice that the version of Ubuntu determines line 3 in the following code i.e. precise.

# Setup your computer to accept software from ROS.org
# 12.04 (precise)
sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu precise main" > /etc/apt/sources.list.d/ros-latest.list'

# Set up your keys
wget http://packages.ros.org/ros.key -O - | sudo apt-key add -

# Installation
sudo apt-get update
sudo apt-get install ros-fuerte-desktop-full
sudo apt-get install ros-fuerte-orocos-toolchain
sudo apt-get install ros-fuerte-rtt-common-msgs

# Create your personal ros directory
mkdir ~/ros_personal

echo "source /opt/ros/fuerte/setup.bash" >> ~/.bashrc
echo "export ROS_PACKAGE_PATH=/opt/ros/fuerte/stacks:~/ros_personal" >> ~/.bashrc
echo "export RTT_COMPONENT_PATH=/opt/ros/fuerte/stacks/orocos_toolchain/install/lib/orocos" >> ~/.bashrc
echo "source /opt/ros/fuerte/stacks/orocos_toolchain/env.sh" >> ~/.bashrc
. ~/.bashrc

# Build SOEM
cd ~/ros_personal
git clone http://git.mech.kuleuven.be/robotics/soem.git
cd soem
git checkout origin/electric
rosmake soem

# Build hexapod
cd ~/ros_personal
svn checkout http://hexapod.wtb.tue.nl/svn/hexapod ./hexapod
roscd hexapod
rosrun rtt_rosnode create_rtt_msgs hexapod_msgs
rosmake

# You still should get
## (1) pr2_spring_transmission_example
## (2) rtt_generic_components (from the amigo trunk, ask with the amigo team)

It is possible to put the code in a shell-file and run it.

SVN

The code can be found on: http://hexapod.wtb.tue.nl/svn/hexapod/.

To obtain an account you should contact Patrick van Brakel. To keep the svn clean i.e. no build, bin or lib files do the following:

sudo gedit /etc/subversion/config 

Uncomment, by removing the '#' and add

global-ignores = *.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo
  *.rej *~ #*# .#* .*.swp .DS_Store lib build bin .tb_history msg_gen srv_gen

Hardware

The TU/e hexapod is a six legged robot with compliant joints. The compliance is obtained by using torsional springs between the actuators and the joints. The motors as well as the joints have absolute encoders. From the difference between these readings, the torsion in the springs can be calculated.

There are three main PCBs on the robot. The PCB inside the bottom of the robot (data acquisition module or DAM1) communicates with a computer. This can be the on board computer or an external pc. It is also equipped with an IMU that can measure pitch and roll angles, roll rates about three axes and acceleration along three axes. Furthermore, it receives power directly from the battery or external power supply and feeds it to the other boards.

Start-up

The PCB on top of the robot (DAM 2) translates the signals it receives from a controller to electric currents for the actuators. The middle PCB is the on board computer on which it is possible to run the robot's software.

To power the hardware, there is a 24V connection on the bottom of the robot. There is a possibility to connect one of the LiPo battery packs or alternatively to wire the robot to a laboratory power supply. When connecting a power supply, make sure the current is not limited too much (you need more than 3A, 10A should be enough. Alternatively, wiring a capacitor in parallel is an option). Once this is connected, the DAM 1 can be started using the small red button that is connected to two loose wires and after that, pressing the large white button on top starts DAM 2.

Connection to a computer, either the on board one or an off board pc, can be established using the "In" port on the piggyback EtherCAT board on the DAM 2. The "out" port should be connected to the "Out" port on DAM 1.

Software

The software on the SVN contains, among other things, a Gazebo model and control programs that communicate with the hardware through SOEM-drivers. A basic structure of the software is shown in the figure below. The grey components are not used, the grey components with grey text are not (yet) implemented.

Simulator

For simulation purposes, the Gazebo simulator is adopted. As a first step, proceed with the installation following the instructions here. Choose the latest stable release.

It's important to specify the robot model in the SDF format. The *.urdf.xacro format is no longer supported. To convert such a file, a script is available in the repository. Once you have defined the correct filename of the model to be converted, type

roscd hexapod_model/models/scripts
source update.bash

Hierarchy convention

The folder tree has this structure:

• hexapod_model
  • model_name
    • hexapod.world ("launch" file)
    • model.config
    • model.sdf
    • model.urdf
    • meshes
    • plugins
      • build

Plugins

Gazebo plugins are lines of code compiled as a shared library and inserted into the simulation. The plugins have direct access to all the functionality of Gazebo through the standard C++ classes. They are used to load models, control the robot, etc. From gazebosim.org:

Each plugin type is managed by a different component of Gazebo. For example, a Model plugin is attached to and controls a specific model in Gazebo. Similarly, a World plugin is attached to a world, and a Sensor plugin to a specific sensor. The System plugin is specified on the command line, and loads first during a Gazebo startup. This plugin gives the user control over the startup process.

Write your plugin_name.cpp in the hexapod_model/model_name/plugins folder. Then edit the CMakeLists.txt so that it looks like this:

cmake_minimum_required(VERSION 2.8 FATAL_ERROR)
include (FindPkgConfig)
if (PKG_CONFIG_FOUND)
  pkg_check_modules(GAZEBO gazebo)
endif()
include_directories(${GAZEBO_INCLUDE_DIRS})
link_directories(${GAZEBO_LIBRARY_DIRS})


add_library(plugin_name SHARED plugin_name.cc)
target_link_libraries(plugin_name ${GAZEBO_libraries})

As a next step, go in the plugins/build folder and build the library.

cmake ../
make

It's important to define the models and the plugins that you want to load in your hexapod.world file. Here's its generic model:

<?xml version="1.0"?>
<sdf version="1.4">
  <world name="default">
    <include>
      <uri>model://ground_plane</uri>
    </include>

    <include>
      <uri>model://sun</uri>
    </include>

    <plugin name="plugin_name" filename="libplugin_name.so"/>
  </world>
</sdf>

It's important to set the GAZEBO_PLUGIN_PATH correctly, pointing to the shared libraries. To do so, edit your .bashrc file:

gedit ~/.bashrc

#GAZEBO
export GAZEBO_PLUGIN_PATH=$HOME/ros/hex/hexapod/trunk/hexapod/hexapod_model/''model_name''/plugins/build:${GAZEBO_PLUGIN_PATH}

source ~/.bashrc

To have more insight, follow the tutorial.

Model spawning

The hexapod_model folder contains the models, each one with its model_name folder.

It's important to set the GAZEBO_MODEL_PATH correctly, pointing to hexapod_model. To do so, edit your bashrc file adding this line:

gedit ~/.bashrc

#GAZEBO
export GAZEBO_MODEL_PATH=$HOME/ros/hex/hexapod/trunk/hexapod/hexapod_model/:${GAZEBO_MODEL_PATH}

source ~/.bashrc

Getting Started

The 'SOEM_hexapod_drivers' package contains a launch file named 'start.launch'. This runs the basic interface of the hexapod robot. From the Soem process, it is possible to, for instance, read the encoder signals or write commands to the actuators, using the Slave_1001 service. The Slave_1002 service is the interface service of the IMU.

The 'Hexapod_Launch' package contains much more launch files, which can be used for various purposes indicated in the names of these files. These launch files start orocos deploy scripts, which in turn may call other scripts.

Some of the deploy scripts contain hard coded paths. Make sure to substitute them with your own. A shell file, rename.sh, was written to automatically do this, but be sure to change the path in this file to your own path. It is located in hexapod_launch. Another possible solution for the future is to seperate the scripts more clearly and call them in a launch file, in which ROS launch syntax can be used to avoid hard coding paths.

OROCOS components

Hexapod Encoder

This is the encoder component. It reads a message coming from the encoder port on the Soem board and outputs three different messages: a status, necessary for the actuators to be enabled, and a joint and actuator reading.

Hexapod Actuator

This is the actuator component. It reads two messages at its input ports: the command message, that can be either 0 or 1, enables the actuators. The control message is what the motor is receiving and it's written to the output port of the component, connected with the Soem board.

Hexapod Safety

This is the safety block that handles the limits in the joints revolution such that motors and cables are not damaged. It enables/disables the motors according to that.

Joint Error

This component is the error block. It has 6 inputs for the six legs references, plus one additional input that reads the encoder to recover the actual joints positions. It computes the error and copies it to the output port.

Hexapod IMU

The IMU component is connected with the Soem Slave_1002 encoder port, and gives as output the roll and pitch angles plus three components of acceleration.

Hexapod Height

This component roughly computes the height of the robot from an average of the tip positions of the legs that are touching the ground.

Ground Contact

This component determines if the leg tips are touching the ground. The conditions that are used are the following:

• The difference between the actuator encoder and the joint encoder is large enough and in the right direction for ground contact (This is very buggy as backlash in the gearheads and joints is in the same order of magnitude as the spring torsion);
• The tip position is below the bottom of the robot (may be improved by adding the height and angle of the robot);

An alternative for this Ground Contact component is to let the reference decide which feet should be touching the ground. This would be less buggy, but also less robust, because if the robot steps on something, this will not be perceived by the robot.

Structure of the Ground Contact component

Hopping

One of the main goals of the design of the TU/e Hexapod robot is for it to be able to run and/or jump. To achieve this, the idea is that the resonance frequency is utilized. The approach that is used, is the one proposed in . The authors of this article use 9 steps to generate a joint reference for a jumping robot. This method is adapted to work on a hexapod and applied here.

Determining the resonace frequency

The first step in this approach is to determine the resonace frequency of the standing robot. In our case, this is done by making the robot stand up (up to position_3) and giving it a sudden push on the top, as a way of applying a delta function. As we are interested in the vertical displacement, and the IMU only gives accelerations, the vertical acceleration is measured. As a sinusoidal response is expected in the displacement, the second derivative should also be a sinusoid at the same frequency. This measurement is documented using a reporter component in OROCOS and the resulting data is imported into matlab to calculate the single sided amplitude spectrum.

The resulting amplitude spectrum is shown in the figure on the right. A clear peak is visible at 4.0 Hz, which is a reasonable value for the resonance frequency, looking at the robot in practice.

Single-sided amplitude spectrum of the Hexapod in vertical oscillation mode with 6 legs on the ground.

Troubleshooting

• The Soem master could not initialize on eth1

Make sure that you are connected to eth1 or otherwise change it in the *.ops file. To list the network ID's form your PC use the following command in the terminal:

ifconfig

• If the setcap cannot be found.

Install the setcap.

sudo apt-get install libcap2-bin

• If the followin error occurs:

[ ERROR  ][Soem] Could not initialize master on eth1

Set the permission for the deployer-gnulinux such that it can use ethernet.

roscd ocl
cd bin
sudo setcap cap_net_raw+ep ./deployer-gnulinux

• If, while running the orocos software, you are getting errors/warnings like

Actuator CF & FT disabled, difference act-jnt is too large"

or HexapodSafety will not start, giving a similar error.

Stop and restart HexapodDriverEncoder while in position_init

Log

Log any hardware failure and/or breakdown here. After repair works, ALWAYS recalibrate the encoders! Look for hardware_calibration.ops in hexapod_launch.

Mar 21	Femur cable of leg 1 broke during testing of walking gait. Fixed by Speciaalmachinefabriek Ketels.
Mar 31	Femur cable of leg 6 broke during testing of hopping/jumping. Fixed by Speciaalmachinefabriek Ketels.
Apr 7	Femur cable of leg 6 wrapped around the wrong slot during testing of new walking gait trajectory. Fixed by Speciaalmachinefabriek Ketels.
Apr 16	Femur cable of leg 6 wrapped around the wrong slot during testing of jumping.

Useful references

Some interesting tips and tricks can be found on the wiki of AMIGO. Regarding realtime performance, also look at this page. For these links, an account for the AMIGO wiki is needed. This can be obtained with the AMIGO team.

Reports

Boris Mrkajic	Systems and Control Library Development	pdf
Max Baeten	Control of the Philips Experimental Robotic Arms using EtherCAT	pdf
Niek Bilterijst	Low Level Spindle Control of AMIGO	pdf
Tim Clephas	Design and control of a service robot - The birth of AMIGO	pdf
R. Woering	Simulating the "first steps" of a hexapodal robot	pdf
Jeroen Willems	Control of a hexapodal robot	pdf
Rokus Ottervanger	Reviving the Hexapod	pdf

Timetable

• April
  • Week 1
    • Restore simulator
      • Look into Gazebo/OROCOS online documentation
      • Order the models
      • Spawn the robot on new Gazebo 2.2 version
  • Week 2 & 3
    • Elaborate a simple model for the jumping dynamics
  • Week 4
    • Simulate the model and find torques to be sent to enable the jumping feature
• May
  • Week 1
  • Week 2
  • Week 3

• • Week 4

• June
  • Week 1
    • Restore simulator
  • Week 2
    • Implement feedforward when robot is in STATE_LAND
      • Write suitable command to joint actuators
  • Week 3

• • Week 4