The project

There were three key parts to this project, Mechanical Design, Electronics and LabVIEW Software. Here is the overall system diagram.

All components are shown in blue, bespoke hardware is shown in orange. The system is powered by either an onboard Lithium Polymer (LiPo) battery or a mains power input (selected by a switch). This power input is then regulated by a power regulation board, providing appropriate voltages for the rest of the components on the hexapod.

A TP-link router is connected to the sbRIO to allow for Wi-Fi programming and operation, whilst an Xsens Orientation sensor is connected to one of the serial ports on the sbRIO to allow the hexapod to sense it's own orientation. Signal routing circuitry is used to get the various digital signals from the sbRIO to the various system components.

Mechanical Design

Here are the components that needed mounting to the hexapod.

Lithium Polymer (LiPo) Battery
Hitec Servo Motors (18)
TP-Link WiFi Router
Neopixel 8x8 LED Array
Xsens IMU Orientation Sensor
Power distribution circuitry
Signal routing circuitry

Six legs, each consisting of three servo motors, for a total of eighteen. Mounting the other components onto this frame is not a trivial task. In fact a great deal of thought went into mounting these components to allow for (a) robustness, (b) ease of replacement and (c) neat design.

It also called for some bespoke mechanical component design. At this point in the project I was doing an internship at Fab Lab London, so I decided to give 3D printing a go.

The LiPo battery, Xsens sensor and the Router mount to the bottom of the frame. To protect these components, I designed a battery holder and a bottom case for the hexapod, both 3D printed as bespoke parts. Here's how they all fit together.

And here is the bottom case being 3D Printed.

The hexapod bottom case being printed on an Ultimaker 2

The sbRIO, and various bespoke circuitry was mounted inside the hexapod between the top and bottom plates. On the top of the hexapod, the LED array was mounted. To give a more professional look, I designed and mounted an acrylic plate on top, bearing the National Instruments logo.

The finished hexapod frame, modified mechanically for this project

Electronics

Electronics was needed for this project to:

Convert an unregulated 12V input voltage to a stable 5V for the motors, router, LED array and Xsens IMU.
Route the multiple digital signals (20 in total) from the sbRIO to the motors, and LED array.

To achieve this I designed a main board to mate directly with sbRIOs high density IO (RMC) connector, along with three separate power regulation boards to be distributed across the chassis. Below is shown the RMC connector; 96 separate lines inside a surface mount socket (requires accurate placement for reflow soldering!)

Using three separate power regulation boards, rather than combining them with main board means that the motors cables can be easily accessed and on the whole makes the electronics more modular. Here is the electronic system diagram.

The electronic system diagram of the hexapod. For brevity only one power distribution board is shown here

The Main Board (blue) and Power Regulation Boards (green), were both designed as printed circuit boards (PCBs), manufactured, soldered and tested.

The majority of the electronics infrastructure on the hexapod

This is the majority of the electronic infrastructure on the hexapod; routing the various signals, and regulating the DC power, for the system components. Ribbon cables are used to route the Motor PWM signals to the Power Regulation Boards, making the electronics modular and easy to remove/replace.

LabVIEW Software

By far the most extensive part of this project is the software. Co-ordinating 18 motors to achieve a good quality overall movement is not easy and requires well structured code. Below is the overall software architecture.

The software is divided across the three hardware platforms on the hexapod; The FPGA, RT Processor and Development Computer.

The FPGA is used for the laborious mathematical calculations for needed to perform inverse kinematics (converting XYZ robot leg positions to leg join angles, read more about that here), and low level digital signal generation. This frees up the RT Processor to do the higher level work; in this case generating the list of XYZ positions required to make the robot walk, or calculating desired body orientations based on sensed orientation.

To organise the code controlling the XYZ positions of six legs, I built my own object oriented set of drivers, humourous referred to as LEGmx. They make the process of writing 6 XYZ motor positions (that's 18 values) to an FPGA VI much simpler.

Essentially the FPGA acts almost like a bespoke hardware driver for the RT processor, easily performing the hundreds of calculations needed for control, saving millions of operating cycles for the RT processor. This kind of hardware setup is absolutely ideal for robotics applications, and is one of the key benefits of using the sbRIO.

A VI on the development computer runs a 3D simulation of the hexapod (based on imported STL files), and animates it based on the real angles sent from the RT processor via a global variable. The VIs running on the RT Processor are controlled via Front Panel Communication from the development computer.

In conclusion

Interested in hiring me for a bespoke demo? Contact me...