The original idea of the robot was to create a Octopod (eight legged) robot. Octopods can solve a lot of movement problems that robots have. The robot we designed is holonomic, once the code is in place for it to move in all directions. Through part malfunctions and printers breaking down, we have sense switch the robot to a Hexapod. The Hexapod is designed in OpenSCAD and the base is fully parametric. It can have any number of legs that we want and we can change the size of the base.
There were many designs for hexapod robots on Thingiverse. Most of these designs were the animal style of hexapod, meaning the legs are symmetric down the center of the robot with a clearly defined front. Other designs used fewer number of servos, but this limited the range of motion of the robot.
For servo control, there are many pre-designed solutions for controlling many servos, but they were expensive. There are also pre-written libraries for controlling servos included in the Arduino IDE that we ultimately used.
The robot is made from the same parts as the Plex Bot I described in a previous post. The hip of the Hexapod and the two connecting servos are in the same configuration as the Plex Bot. This means all that I needed to design was the base of the robot and modify some of the joints size to better allow for a better range of freedom. The base of the robot is shown below. All of the joints are located in the center of the hexagon sides. This is probably not the best place to place these as it allows for less movement than if the servos were placed at the corner.
As a size comparison there is an arduino mega on the bottom. We wanted the bot to be as small as possible so the Mega, the biggest component, fits within the bounds of the main body.
After designing the base, next was the joints. This robot did not use bearings at the joints opposite to the servo horn. This made fitting all the parts a lot harder as the joints did not want to fit properly without a lot of dremeling down the edges. In the end all joints fit and can be moved by the servos but less friction would certainly be prefered.
The hardware solution for servo control was using an Arduino Mega for control with a shield to connect the servos to the Mega. With the idea of building an octobot, the shield was designed to handle 24 servos. The shield supplies power to all the servos and connects the control wire on each servo to the correct pin on the Mega. Additionally there were four headers for ultrasonic sensors. When the servos change position, the current spikes, which could cause servos to not move. The solution was to add a capacitor to smooth out the current. Additionally, we were using a wall USB power supply that supplied 2 A. When the servos have a torque applied on them they draw 0.3 A. With 18 servos, they can draw a combined 5.4 A. We ended up using a NiCad battery that could supply 6 A.
In laying out the shield, I didn’t realize the problem with connecting servos to the Tx and Rx pins. The Tx and Rx pins are used for the communications between the computer and the microcontroller. With a servo connected to those pins, the servo would twitch when the code was being uploaded. Also it prevented the use of Serial.println() for debugging. As a quick fix we just removed the servos attached to the Tx and Rx pins and moved them to open headers.
The Arduino servo library was used to simplify the programming. Each leg was written as a class to help with the control of the robot. The legs were incorporated in a robot class that has functions for each planned movement.