Hexapod Robot - An ECE 4760 Project
Background Unavailable

Cornell ECE 4760 Hexapod Robot

We’ve designed an obstacle-avoiding, mood-displaying hexapod robot. This robot utilizes 12 servo-powered joints to walk on six legs in a spider-like fashion. During its normal walking pattern, Hexapod avoids obstacles in the forward direction via an ultrasonic sensor calibrated to detect objects 20” away. To mimic spider walking patterns, we programmed Hexapod to back up in a randomly decided left or right direction in the presence of an obstacle. Finally, to include the ability to communicate the state of obstacle detection with a user, Hexapod includes an 8x8 LED display to create a mood-dependent face that increases in happiness with the time elapsed since an obstacle was last detected.


Our Team Of Engineers

We are passionate students of engineering at Cornell!


Megan Backus (mb2532)



Joseph Primmer (jp2228)

also ECE


Kenneth Mao (km63)

yet another ECE


A brief overview of the design
considerations for our project


Rationale and The Idea

Our rationale for building this project was simple. We wanted to build a cool looking robot that could fake some basic personality. We can attribute the sources to our ideas for this project to many places like spider/ant/bug walking patterns, video games, and pre-existing robots.

Logical Structure

Our project has a very systematic logical structure. Although there are many different parts to our robot. These parts tended to be very similar to one another. This meant there were many ways we could reduce duplicating work. In hardware these include using the same 2 CADs for all the legs and having a symmetrical design. In software this meant creating macros and abstractions for reducing code duplication.

Background Math

We utilized math in several places. These include doing physics simulations on the mechanical design in ANSYS. We also had to calculate how often to trigger the interrupt service routine for the PWM signals. We calculated this based on how much granularity we needed for the pwm (about 40 different steps within 1ms or around 80 different steps for the entire range of the servo) and how much CPU utilization we were willing to spend. 40 * 1000 = 40kHz so we defined our ISR to go off every 1000 clock cycles. 40MHz / 1000 = 40kHz.

Hardware / Software Tradeoffs

We made a few hardware/software trade offs. These include the trade off between servo granularity (hardware) and ISR CPU utilization (software) as well as using DMA to do pwm (hardware) vs using an ISR (software productivity). With a higher interrupt rate we could have better servo control, but the CPU wouldn’t have time for other tasks, so we chose a smaller granularity to allow the CPU to do other interesting things. We also chose an ISR to generate pwm instead of DMA as using dma would increase software size and complexity and prevented us from implementing other cool features in this short amount of time.


Some standards relevant to us are the IEEE 802.11 standard used for Wifi and is the standard the esp8266 wifi chip adheres to. The esp8266 chip is also FCC certified and its FCC ID number is 2ADUIESP‐12 and a full compliance report can be found here: FCC Compliance. Although we didn’t end up utilizing the chip, it is still built into our robot and can be utilized in the future. We also used the UART communication protocol used for serial communication between devices. In this project we will use UART to communicate between the esp8266 and the PIC32mx microcontroller. Finally we also used PWM for servo control.

Intellectual Property

There are not very many applicable patents, copyrights, and trademarks. However, we would like to attribute a portion of our code (specifically the neopixel functions) to Bruce Land, who wrote these functions originally for use with a neopixel strip. We reutilized and modified this functionality for use with our neopixel display. We would also like to attribute the design of this website to landingrepo.com from which we found the free template for our website.

In depth overview of how certain portions of our hardware and software were designed


Accuracy and Artifacts

There are certain trade offs we made in this project that brought down the “accuracies” of certain subsystems but did not have an impact on the overall performance of the project. These included aspects of our PWM generation, neopixels, and the ultrasonic sensor.

PWM Generation: Granularity of 40-80 steps

Neopixel: Occasionally has some flickering artifacts (can pass as “blinking”)

Ultrasonic Sensor: Only took readings every ~100mS only while going forward

These accuracies and artifacts are discussed more in the software sections.

Safety and Interferance

Our robot design is both safe in interacting with users as well as generally free of interference with other people’s designs. Our current design does not make use of RF transmission currently, so it does not pose any danger of interfering with other projects. If we do plan to add RF in the future it will be a pre FCC approved esp8266 module that is confirmed to meet certain interference mitigation requirements. It is also includes forward obstacle detection so it also does not pose the problem of physically interacting with any other designs.

Our final robot design has a very simple user interface. It utilizes two onboard pushbuttons: one for resetting the entire robot and one for beginning the walk sequence. The reset button cause the robot to initialize to a neutral upright position and a happy face display. Upon pressing the start button, the robot begins to walk forward until it detects an obstacle. When detecting an obstacle approximately 20” away, the robot turns either backwards left or backwards right until the obstacle is no longer detected. When detecting an obstacle for the first time, the robot’s face turns neutral, and after a certain period of time consistently detecting an obstacle has elapsed, the robot’s face turns angry. Pressing the reset button again causes the robot to resume its neutral, stationary stance. This very simple interface allows the robot to be operated and understood by almost anyone.

Read Our Customer Testimonials

Our clients all love the Hexapod Robot!

The Hexapod robot always helps me cheer up when I'm down!
Jude Thorn - a stock photo
I purchased the Hexapod robot for my son bobbykins, it is the only thing he plays with now!!
Marsha Singer - Mom
Even though I always get the feeling it will jump up and attack me one day, the Hexapod Robot has really proven itself to be a real team player.
Roy Smith - CS Major
At the beginning I thought the price for the Hexapod robot was a bit high, but time and time again it proves its worth!
Ronald Spice - AEM Major
I recommend the Hexapod robot to every business owner who wants to improve moral at their company!
Lindsay Rune - SV CEO
Sometimes the Hexapod robot makes me think really deeply about my place in the universe. I think that's really special.
Ann Black - Philosophy PhD Candidate


Though our final design changed slightly from our initial project proposal, it meets all of the baseline design expectations we intended to carry out. When planning our project we expected to create a hexapod robot capable of a stable forward walking movement using the standard 2-joint-per-leg mechanical hexapod model. We also planned to implement several different movement patterns, including turning and backing up. We met these initial expectations for construction and movement in our final design. In addition, we had several other ideas for additional robot features in our design proposal, some of which we implemented and some of which we decided against using while working on the project.

One of the features from our proposal that we decided to implement is ultrasonic obstacle detection. We deviated slightly from our initial plan by later deciding against using three ultrasonic sensors for obstacle avoidance in the front, left, and right directions in favor of using only one sensor in the forward direction in order to free up header-connected GPIO pins on the PIC32 for other peripherals. Due to time constraints limiting our ability to 3D-print a redesign of our hexapod legs, we were not able to implement a rolling movement as we intended. One feature we added to our design post our initial proposal is the Neopixel Array for displaying robot mood. The removal of the additional ultrasonic sensors made it possible for us to interface with with this LED array.

Our final hardware and software design has very few intellectual property considerations as almost all of the code and mechanical design for the project was created from scratch. We did not use any code in the public domain or reverse engineer an existing project. While we utilized some background information about mechanical design and proportions from various sources (see Appendix), the final design was ultimately created by us. As a result, we did not encounter any patent or trademark issues and our final design is open to any publishing opportunities of its own.

If we were to redo or continue this project, we would add in some of the additional features we were unable to implement, including WiFi control using an ESP8266 module, hexapod rolling, and obstacle avoidance in multiple directions. This would involve modifying slightly our PCB design to allow for more peripheral devices, possibly modifying our software to allow our existing operations to require less of the total CPU time, and redesigning our robot legs.

Ethical, Safety, and Legal Considerations:

  • Throughout the course of our project development we complied with the IEEE Code of Ethics. Our final project is a very safe design, as the hexapod is very unlikely to run into anyone and thing given its obstacle avoidance feature, it has a bright LED display that indicates its presence, and the servos used to power the legs have enough static torque to move the legs but are not powerful enough to pose any risk of injury. This complies with IEEE ethics standards (IEEE Ethics Standards 1 and 9). In the hope of allowing others to recreate this hexapod design, we provide detailed descriptions of hardware design as well as CAD design files and circuit schematics and have made our code open source on Github.
  • The hexapod design has very few safety concerns as well as it is not bio-connected. The robot runs very little risk of running into anyone or anything with its forward obstacle detection for forward movement. To avoid accidental shorts, we have made sure to carefully insulate all wires in our power circuitry and added an easy-to-use Microfit connector to connect and disconnect our LiPo battery to our BEC. In order to prevent our LED display from being blinding (as Neopixel LEDs are normally very bright), we wrapped the array with a semi-transparent paper cloth to diffuse the light. For similar reasons, our project does not have any legal considerations as it does not connect to humans or other vehicles and does not utilize a transmitter.


Appendix A.

The group approves this report for inclusion on the course website. The group approves the video for inclusion on the course youtube channel.

Appendix B.

Commented Code

Appendix C.


Appendix D.

Bill of Materials
Part Part Number Vendor Price
PIC32 Microcontroller PIC32MX250F128D Digikey $4.24
Custom prototype PCB N/A OshPark $8.33
SG90S micro servo (x12) SG90S Miuzei $21.60
3D printed hexapod baseplate and legs N/A *printed in Cornell Rapid Prototyping Lab $0
Battery Eliminator Circuit CSE010-0154-00 Castle Creations $34.00
Ultrasonic Sensor HCSR04 WYPH $1.20
M2 Machine Screws N/A *taken from lab $0
8x8 Neopixel Array N/A Adafruit $34.95
7.4V Lipo Battery A949 Bloomikey $12.50
Various SMD Electronic components (capacitors, resistors, push buttons, male/female headers) N/A *taken from 4760 lab and maker lab $0
Total Cost $116.82

Appendix E.