Hexapod-robot running ROS

The hexapod robot is a platform that uses six legs to move. After watching a lot of videos on the Internet, it became clear that it is very interesting to watch the movement of such robots. And then there was a desire to do something similar, but with a BeagleBone Black single-board computer (hereinafter referred to as BBB) on board, because there were no such projects yet. Information about such robots was not easy to find, especially with regard to the software component. For some time, it was not clear where to start, but it was soon decided to start with the manufacture of a robot constructor - the chassis and the electronic component, and then start programming what had happened.

Having studied on Robocraft.ru some articles about the operating system for robots - ROS - it was decided to build the control on it, especially the BBB's power should have been enough for that. In addition, ROS is a very promising direction in robotics with a variety of tools and ready-made solutions for development.

The choice of "iron"

As noted above, BeagleBone Black has become the brain of the system:
')


BBB also supports Ubuntu, but with a core for the ARM architecture.

The experimental mode, in which ROS for ARM is still working, did not affect the work process in any way, since tools that work stably on linux-arm were used.

The next important part is the servo controller. BBB has several PWM channels, but they are clearly not enough for 18 servos. In addition, the PWM control will unnecessarily load the processor. It is more logical to use ready-made servo controller with control through any interface. The choice fell on the appropriate Mini Maestro 18-Channel USB Servo Controller:



This controller has 18 channels for servo, UART and USB interface. It is controlled through “its” protocol, which includes setting the target angle of the servo, as well as its speed and acceleration, besides it has convenient calibration tools in the graphical environment.

But quickly connecting the Mini Maestro to the BBB does not work, since the UART interface levels are different: 5 V and 3.3 V. The output was the use of an additional device - a logic level converter, which converts 3.3 V to 5 V and vice versa. Such a thing came from Sparkfaun.com. This is BOB-08745 :



Now you can easily connect the BBB and the controller so that they communicate on the UART.

For future research, IMU wanted the robot to somehow feel itself in space. IMU with accelerometer, magnetometer and gyroscope is also ordered on Pololu:



This is a small MinIMU-9 v2 board with two L3GD20 and LSM303DLHC chips, communicating with peripherals on the I2C interface. MiniIMU is capable of working from 2.5V to 5.5V, so no converters are needed.

On many videos, the hexapods were controlled by a gamepad from various consoles. And for good reason. With its many buttons and two “analog” knobs, the joystick becomes a convenient control device. In ROS, there was a driver for a standard joystick and, in order to avoid connection problems, it was decided to purchase the original PS3 Dual Shock 3:



To connect via Bluetooth, obviously, a USB adapter was needed. As a result, I had two of them, because one of them did not want to work with the existing driver (more on that later). And MobileData UBT-206 - earned.

For BBB communication with a desktop computer, the SSH protocol is used, which in turn uses, for example, Ethernet, Ethernet-over-USB (technology that allows to emulate an ethernet network via USB) or Wi-Fi. Connecting the wires every time is not very convenient and another USB Wi-Fi adapter was added to get rid of it. After reviewing which adapter is best for BBB, it became clear that the arm-linux kernel supports the rtl8192cu driver based on which a wide range of devices work. The compact NetGear WNA1000M was chosen (in the picture together with the MobileData UBT-206):




Although many recommend using adapters with an external antenna, this one works quite stably.

Well, in order to expand only one USB Host BBB connector, a USB hub is required. I liked this one - MobileData HDH-700, because it has buttons-switches for each of the four devices:



The next item is the batteries of all the onboard devices. Battery - Li-Po 2200mAh, consisting of two cans. Together with it, two voltage stabilizers convert the battery voltage to the required 5V (for BBB and servo controller) and 6V (for servo drives). Also, a low-charge alarm is installed on the battery, which squeaks when the battery voltage drops to its minimum.

The choice of design and servos

There are many designs of hexapods made from various materials. I will not upload photos here, as they are easy to find on the Internet. The classic version consists of three drives for each leg, which gives a sufficient degree of freedom. Of course, you can do with two drives - but the movements will become more “jerky”.

Different materials and manufacturing technology of parts of the suspension. It can be printing on a 3d printer or laser cutting from plastic, plywood or metal sheets. Since the 3d printer was not at hand and the strength of the printed parts leaves much to be desired, a metal construction was chosen, namely aluminum and duralumin. Especially at work, I had access to a CNC milling machine, so it was decided to make parts from metal sheets by milling.

The main example that has created its own design is Lynxmotion Phoenix :



The creation was also greatly helped by the model with GrabCAD .

One of the main parts of the robot are servos. They must have sufficient torque and, for reliability, the gear should be chosen from the metal. Such servi from well-known companies Hitec and Futaba cost about $ 20- $ 30. Therefore, instead of the “not cheap” servo drives of the Hitec HS-645 / 485MG, Chinese were ordered, which are two times cheaper than the Turnigy TGY-S901D :



When powered at 6V, they are able to cope with a maximum load of 12.5 kg / cm, which is enough for a robot with an estimated mass of 2 kg. And the stock in the Chinese servah is necessary, since the quality of them leaves much to be desired. Some of them work with extraneous sounds from the very beginning. They also have a fairly large backlash and curved axes. But for $ 10 apiece - this is acceptable.

Aluminum disk fasteners on the shaft were purchased for servam to increase the strength and elasticity of the structure:

Creating 3d models in SolidWorks and manufacturing parts

Thus, having decided on a basic set of component parts, I began to create a 3d drawing using SolidWorks. Here's a render of what happened (I didn’t draw all the screws):



Separately, probably, it is worth stopping at some details and knots. In addition to flat parts, of particular difficulty were the parts obtained by bending:



A scan of these parts is obtained using a special tool in SolidWorks. They are cut from a sheet of aluminum 2 mm, removed from the body of an unnecessary device. It was flexible, so the aluminum grade was apparently suitable for this. The problem to bend all the parts in the same way and exactly was solved with the help of a special tool, a vice and a hammer. It turned out even better than I expected from the manual method of manufacturing.



The next item is the sleeves on the side of the servo opposite from the shaft. Through these bushings the servos are mounted in the bottom of the frame.



Sleeves are necessary for uniform distribution of the load on the two plates of the frame, otherwise the servo shaft may be bent. The sleeves are made on the same milling machine from caprolon - a polymer used in anti-friction parts.



And the last thing worth staying at is the details on the ends of the legs.



They are printed on a 3D plastic ABS printer. Next, rubber feet for instrument cases are glued into their round grooves. The result is a complete part, contributing to increased friction of contact with the surface. Without them, the ratio of inertia of the robot and the "tenacity" of the legs, leads to the slipping of the latter when walking and other actions on any flat surface.



The remaining flat parts are made of duralumin with a thickness of 2.2 mm.

Build robot

The assembly took place in several stages. This is due to the debugging of its individual parts. At first, only chassis with a servo controller were assembled, and control was exercised from the amd64 desktop computer via USB. Then there was a BBB with a hub, and last of all - a battery with stabilizers and IMU.

In the photo - the various stages of assembly and the final result.

Beaglebone

On the BBB installed Ubuntu 13.04 system from the finished image . Today this distribution is not available for download, but there is only the latest and LTS. Kernel version 3.8.

eMMC was stitched through a microSD card. The easiest way to write an image to a USB flash drive is with Image Writer for Windows. Instructions for the firmware can be found here .

Now about the initialization of the UART in the BBB. This is done through the Device Tree Compiler (DTC) and more details can be found here . You can install on the BBB in this way:

wget -c https://raw.github.com/RobertCNelson/tools/master/pkgs/dtc.sh
chmod +x dtc.sh
./dtc.sh

Taken from here .

After Rx and Tx UART appeared on pins P9_11 and P9_13 (in the case of uart5), you can transfer data. And in order to change the bitrate, the stty utility is used. It is launched through a script, before starting work with the servo controller:

stty -F /dev/ttyO4 cs8 115200

On the controller, the speed is set via the Maestro Control Center .

To make the UART “start up” every time you start the system, you should add a line
sudo bash -c "echo enable-uart5 > /sys/devices/bone_capemgr.*/slots"
in rc.local.

As described above, IMU uses the I2C interface. I2C on BBB works by default, no additional action is required to run it. But before writing the ROS node for IMU, it was useful to verify that the interface was connected correctly using the i2c-tools utility for Linux. Understanding I2C still helped video .

A big problem was to make the bluetooth joystick work normally. Connecting it was not difficult - all in accordance with the description of the ps3joy node and the tutorial to it. Only the driver for the joystick, starting with version 3.5 of the kernel, began to receive events from a device with a low frequency: about 5 Hz. This is not enough for normal control. The problem is just mentioned here . Therefore, having tried a bunch of other drivers, I found one worker for arm-linux. This is a sixad driver. But to make it to the BBB, it must be collected manually. This was done for the Raspberry PI and is described in detail here . When compiling for some reason, I got an error:

error: ... was not declared in this scope

It was resolved by adding a header unistd.h to each driver source file.

After the driver is assembled and installed, the gamepad still did not connect right away. This was decided by changing the bluetooth configuration:

echo "DisablePlugins = input" >> /etc/bluetooth/main.conf

After that, you could start the driver as a daemon and freely connect the joystick by pressing the PS3 button.

USB Wi-Fi works out of the box. In order for the client to connect to the router, you need to change the fields in / etc / network / interfaces:

wpa-ssid ""
wpa-psk ""

Ros

For starters, ROS was installed on a desktop computer. The version of the distribution kit of Hydro Desktop-Full, was installed without problems on Ubuntu 13.04. On the "big" computer, it is convenient to debug the written nodes and the kinematic model in the ROS visualization tools. In addition, the compilation is much faster than on the BBB. Therefore, everything was developed on a computer, and then only transferred to the BBB and compiled there. Unfortunately, cross-compiling for ROS is still a difficult task.

For visualization there is a handy tool - rviz . It was used to view the resulting model and how it behaves when driving. To do this, there is a joint_state_publisher - a package containing configuration tools and changing the position of the "joints" and a robot_state_publisher - a package that translates the position of the robot in tf . The model itself is contained in the URDF file. It describes all the segments (links) and their joints, as well as their relative position. For clarity, attached 3d models of parts in STL format. But since the robot contains duplicate parts (legs), it is convenient to use the XACRO format (XML Macros), which is then converted to URDF. The main advantages of XACRO: the presence of macros, mathematical operations and constants. Thus, it is possible to minimize the code describing the model of the robot. The figure shows the structure and visualization of the model in rviz.




When writing the basic nodes in C ++, the IDE Eclipse Kepler was used. About the configuration of Eclipse can be read here . In general, before starting it is worthwhile to get acquainted with the textbook , roscpp and catkin .

Software development

In this article the code of nodes will not be described, only their general structure and purpose will be presented. Learn more about writing code in the next article.

So, the general scheme of the structure of ROS nodes on the BBB (in ellipses - the name of the nodes, in the rectangles - the name of the topics):



joy_node is a complete package that allows you to convert data from a standard Linux device file (/ dev / input / js) into “ Joy ” messages and translate them into ROS topics. It will be useful to look in the tutorial package. Almost always they contain many answers to questions.

crab_teleop_joy is the node that processes data from the joystick and converts it into messages to control the hexapod. For example, from the position along the two axes of the “analog” handle, the course angle is calculated, and its distance from the center affects the stride length. These values ​​are then used in the gait generator. Also builds the logic of using certain combinations and sequences of keystrokes. Received messages are transmitted further in three topics.

crab_leg_kinematics is a service node. Its purpose is to solve the inverse kinematics problem, that is, based on the coordinates of the end-effector (in my case, these are the tips of the legs), calculate the angles of the position of the joints (the angles of the servo drives). The request to the service is formed in the form of six vectors of the target position of the tips of the legs, and the answer comes in the form of the 18 angles of the servos. Written node using Kinematics and Dynamics Library ( KDL ), which is integrated into ROS. The node clients are crab_body_kinematics and crab_gait.

crab_body_kinematics - calculates the vectors of the ends of the legs based on the URDF robot model and data from a message that contains the desired linear and angular deviations of the frame from the initial position, as well as the radius of the legs. Also implemented are the lifting commands from the starting position (when the robot lies on the frame and the legs are folded) and return to the starting position.

crab_gait is a node that generates position vectors for the ends of the legs for the implementation of two types of gait. At the entrance there are messages containing commands about the type and state of the gait (to go / stand) and the values ​​of control: course and trot angles and step size. The types of gait are tripod and ripple:



The tripod-type gait is faster, but at the same time the load on the central legs is greater than on the front and back, which has a bad effect on the lifespan of the serv.

The control is carried out with the help of two “analog” joystick knobs: the left one - changing course while constantly ransacking (moving with “crab”), the right one — changing course with changing yaw (moving back and forth and left-right).

crab_imu - MinIMU-9 driver, assembled from parts of an Arduino sketch . Contains an algorithm for calculating Euler angles based on data from MEMS sensors. Also contains a simple P-regulator, forming effects, compensating for deviations in pitch and roll. These impacts are transmitted through the topic move_body in crab_body_kinematics to set the desired position of the legs.

crab_maestro_controller - the last driver node for the Mini Maestro. At the entrance it has 18 angular positions of the servos, which it converts into the communication protocol of the servo controller over the UART.

The structural diagram of the visualization is slightly different from the scheme of the robot system. In the visualization, all the same nodes except for the crab_maestro_controller node, which are replaced by the crab_joint_publisher, joint_state_publisher, robot_state_publisher, and tf nodes.



About the latter was written above.

crab_joint_publisher - converts messages intended for the controller into messages " JointState ", which are fed to the input joint_state_publisher.

Now about some stages of development with video.

First, all control of the hexapod was carried out from a computer. The beginning was the test of inverse kinematics by drawing the circumference of one of the legs:



Then collected parts of the control position and orientation of the body:



And the embodiment of this on this robot:



After that, I started all this on the BBB and tested the IMU node:



Then the robot went ripple gait, controlled with a joystick:



And at the end of the possibility of a hexapod today:

Conclusion

Creating a hexapod was a very interesting process, and the ROS capabilities and BeagleBone Black performance allow you to add and improve the software component of the robot. In this article, I wanted to show first of all the possibilities of convenient development using ROS, and also to pay attention to what tools were used to create the robot, without going into details. At the initial stage, it was most difficult to figure out where to start and what means to use. I hope this article will help to navigate in choosing the path of development.

PS project sources on github