Lego NXT Hexapod

First Year

Term One

Introduction to Robotics

Hexapod Drag Race

Introduction

This is a report on the design and build process undertaken while producing a hexapod robot from a Lego NXT kit that will compete in a hexapod “drag race” against other teams. This document will detail all the problems I faced during the design and construction of this robot. It will also explain the solutions I came up with and my reasons for choosing particular solutions.

For this challenge I was teamed up with a partner, however due to creative differences, he decided to join another team with similar ideas to his own. Rather than give up and join another team myself I continued the project on my own as this gave me a larger scope for a more varied design.

The Task

The robot was built to take part in a “drag race” against other hexapod robots.

The robots must walk using tripod gate, keeping a minimum of 3 legs in a triangle arrangement in contact with the ground at all times. The objective is to cross the finish line before your opponent. After the finish line there will be a wall which the robot must stop without touching otherwise a 5 second time penalty will be issued. There is also a 2 second time penalty for human interference with the robot once the race has started.

The Design

One of main points for the design was that the robot had to walk with a tripod gait.

Initial I tried many designs to achieve this including designs which had a bar with a sliding pivot in the center and one end attached to an off center cam. This worked well as only one motor input was required to control both vertical and horizontal movement of the foot. I found that, while being able to be run very fast, you cannot have a large step distance without changing the offset of the cam, but this also increased step height distance which caused the robot to “bounce”.

Another idea was to have the leg on a 2 axis joint that allowed vertical and horizontal rotation but not roll. These would then be connected to 2 off center cams, one would connect to the top of the leg above the joint and control the leg height while the other would connect in front of the joint and control the horizontal movement. Initially this design seamed to work well as it gave me individual control of both height and stride because the movement on one axis could be increased without increasing the other. This would allow me to gear up the strides to make them faster and gear down the step height to make it capable of lifting the weight of the NXT easily.

The problem that I found with this design was that it was gard to run from 3 motors. I had to gear together all cams on one side for horizontal movement and have one motor that powered them. I had to gear together all 6 cams for vertical movement so that alternate legs could be lifted and lowered in sync. The problem that I faced was with the gears. I did not have quantity of gears required. I also found during testing that the gears became un-reliable under load. They would skip teeth or come loose and stop meshing all together. This caused legs to stop being synced and the tripod gait would become less affective. This was a concern as the robot may have to do multiple runs on race day.

I decided to keep the idea of separate axis control but try and create another method for connecting the movement of the legs which did not include the use of gears.

The solution that I came up with on the horizontal axis was to join all the legs on one side together with a bar that would connect the legs directly. The middle leg would be pivoted on the opposite side of the bar to the other 2 legs making it move in the opposite direction. Legs would then be controlled by moving the bar forwards and back. Pushing the bar forwards would push the front and rear legs forming a type 3 lever, it would also push the opposite side of the middle legs, acting as a type 1 lever. This bar would then be linked to a cam mounted directly to the motor for that side. This means that there can never be any skipping gears and the horizontal leg movement of each side can never come out of sync. Another decision I made was to move the center leg further from the center of the hexapod. This allowed the control bar to sit straighter and the robot was much more stable as its feet now sat in a hexagon shape instead of a rectangle (3).

For vertical movement of the legs I used a similar method where a bar is fixed to a point above the leg and this is pulled or pushed to raise or lower the leg. However this time I connected the bar to an off center shaft that run up the center of the robot (front to back). this could be rocked from side to side by the motor and would be connected to legs on both sides at the same time. When building this I had many problems with getting one motor to lift the weight of the robot on 3 legs. There was a lot of mechanical losses and without gearing the motor was not string enough. I did not want to gear this down as it would make

changing the points of ground contact slow and affect the over all speed of the robot. I finally realised that I did not need to lift and lower all 6 legs, I only needed to adjust the middle 2. this was because as the middle leg on one side was lowered it would push the outside 2 off the ground. I fixed the front and back legs in position and found that one motor could easily move the center leg and lift the full weight on one moving point.

Another thing I realised during testing was that when reversing the direction of a motor a lot of time is wasted with accelerating and slowing down to change direction. A motor can complete a full 360 degree turn a lot faster than it can go forward 180 and then back 180. Because of this I decided to connect the motors so that they could run continuously in one direction as this was more efficient and made a full leg cycle a lot quicker.

I wrote the code for the NXT in Robot C as this is much more efficient than the standard program that the NXT is supplied with. I had lots of problems with getting the motor encoders to act correctly as the motors needed to be able to move forward in accurate increments of 180 degrees. This was not possible as the motors would overshoot there target and I found no accurate way of accounting for this in software. My final solution was to add a touch sensor to each side that told me when the legs were in the forward position. To step forward I turned the motor 180 degrees and then for the next step I continued the motor until the touch sensor was pressed. This solved the problems of overshoot as the leg position was re-calibrated with every leg cycle. It also helped with keeping the opposite sides in sync as this press was used to tell when to move on to the next command. To walk left and right legs were place 180 degrees out of phase, the middle leg would then be lowered on one side. The drive motors would then rotate 180 degrees moving the robot forward. The middle leg would then be raised and the opposite one lowered. All legs would then step again and this cycle would be repeated until an ultrasound mounted on the front detected close proximity to the wall .

My design was also able to steer efficiently without stopping its alternating step pattern. The bottom two motors run 180 degrees out of phase while walking forwards. If 1 motor is paused for a half cycle to bring both motors into phase the robot will begin to turn on the spot. To return to forward motion the same motor is stopped again for half a cycle and the motor is put back out of phase. This is efficient because the robot can turn in either direction without any of the motors having to change direction.

I also experimented with different leg lengths to find the leg that gave me the maximum stride length without putting to much stress on the motors. I found that lots of joints needed strengthening as the torque produced was causing them to break apart. Other tests were completed with the brick in different places as this changed the center of gravity, making strides easier or harder.

Final Product: (11)(12)

Results from race day:

Robot Name (my robot highlighted)	Time for first run(fastest 6 highlighted)	Semifinals times(fastest 3 highlighted)	Finals Times(winner highlighted)
Harold	01:40:00
Colin	00:38:00 + (3×2)
Number 5 (my robot)	00:29:20	00:25:00
Headcrab	00:11:00 + 5 + 2	00:13:00	00:14:30
Stamphrey	00:37:30	00:46:40 + (2×2)
L-hexasaurus	00:16:00	00:19:00 + 2	00:18:00
Sicheal	DNF (disabled)
Cheric (turtle express)	00:27:30	00:29:00 + 2
The Bug	00:21.60 + 2	00:20:00	00:20:00
Twitchy	03:17:00 + (6×2)
Catdog	01:25:00
Hare	02:40:00
Marvelous	01:12:00 + 2

Standings:

1^st place = Headcrab

2^nd place = L-hexasaurus

3^rd place = The Bug

4^th place = Number 5 (my robot)

Analysis of other robots:

Headcrab had 1 rotary leg on each side, that had 3 “feet” spaced equally around it. This meant that it as the leg spun all 3 points would touch the ground one after the other however it was the only robot in the race that did not use tripod gate. As this was specified in the design brief I share an opinion with many other people that that this design should not have counted in the final standings.

L-hexasaurus came in second with a design based around the R-hex robot. Despite having an unfair advantage by using 6 motors and 2 NXT’s, they only managed to gain a 2 second lead on The Bug. Many people complained that this design was not a true hexapod due to legs being able to turn one full revolution however as there robot was able to perform a tripod gate I believe they were within the design brief and they should have come first.

The bug used a very efficient leg design where 3 legs were powered off of each motor and there were few mechanical losses in there design.

Many of the robots that did not do well had problems on race day with cogs either skipping or failing completely. This led to one robot not finishing and many others not having an efficient tripod gate, this made them curve and incur penalty’s for human interference.

My Robots Performance:

On race day I feel that my robot performed well. It was both fast and reliable and this showed up in the results. On both runs it stopped before hitting the wall and at no point did it need human interference to keep it going straight.

Conclusion:

I believe that on race day although I did not produce the fasted hexapod I did stick closely to the brief and produced the second fastest “natural” walking hexapod, beaten only buy The Bug. The over all design worked well and the large stride length gave me quite an advantage over many of the other robots.

If I were to redo the design and development of my hexapod robot I think that I would look into gearing the drive motors to move slightly faster as I think they had far more torque than was needed to move it forward. I would also spend more time trying to optimise the code as I think I could gain more speed by overlapping commands slightly. eg. If the middle leg was to start to lower before the legs had reached the full forward position it would contact the ground and stop moving forward at the same time, eliminating the delay between actions. This would make for both a faster and more efficient walking cycle.