EddiePlus the better balance bot

by diabetemonster, published

EddiePlus the better balance bot by diabetemonster Feb 23, 2015
2 Share
Download This Thing! Customize Order This Printed Tools & Utilities

Thing Info

12119Views 2046Downloads Found in Robotics
Report Thing


Hello again!

Eddie is back and he's excited to show off his improvements.

This is EddiePlus and he has a much cleaner look, new accessories, and vastly improved performance.

All the great features of the original Eddie still exist:

  • Rechargeable
  • WiFi Enabled
  • Remote Control
  • FPV Capable
  • Open Source
  • 1 hour drive time with USB camera active

New features with EddiePlus:

  • Wheel/Motor encoders
  • Faster Motors -- More speed!
  • Bigger Wheels
  • Dual PID control on each wheel
  • Dynamic balance
  • No exposed screws
  • Interchangeable head designs
  • Backpack to keep electronics safe
  • Build Guide to assist in assembly

Upcoming features:

  • iOS application (can accept a limited number of beta testers)
  • Bluetooth control

Eddie's source code is available on github:

Demo videos:

That is about all I have at the moment for Eddie. I'll be posting new videos, photos, and 3D models as they come and Eddie can be followed on twitter @EddieBalance. I'm hoping others will build to expand and improve upon my design. This was started as a fun project because I wanted to make a self balancing robot and I think he came out so great that I wanted to share him with everyone.

If you need help building your Eddie please send me a message here or @EddieBalance

Thanks for looking!


Please see the EddiePlus Builder's Guide I've started on google drive:


I've also started a Software Setup Guide to get you going once you've built your Eddie:


More from Robotics

view more

Thing Info

12119Views 2046Downloads Found in Robotics
Report Thing


Liked By

View All


EddiePlus the better balance bot by diabetemonster is licensed under the GNU - LGPL license.

Give a Shout Out

If you print this Thing and display it in public proudly give attribution by printing and displaying this tag. Print Thing Tag

All Apps

This App connects Thingiverse with Makeprintable, a cloud-based mesh repair service that analyzes, validates and repairs most common mesh errors that can occur when preparing a 3D design file for p...

App Info Launch App

Kiri:Moto is an integrated cloud-based slicer and tool-path generator for 3D Printing, CAM / CNC and Laser cutting. *** 3D printing mode provides model slicing and GCode output using built-in...

App Info Launch App
KiriMoto Thing App

With 3D Slash, you can edit 3d models like a stonecutter. A unique interface: as fun as a building game! The perfect tool for non-designers and children to create in 3D.

App Info Launch App

Excelent work!!
Dear Diabetemonster,Please explain how it can balance the loads placed on the robot arms.Is there some sensor in arms?Thank you very much.

Thank you. There are no sensors in the arms. Eddie senses his current angle with an IMU and how much his wheels move with encoders. The additional weight can be placed anywhere on the robot and the programming will compensate for the angular and wheel position offset from the applied load.

The bad sound is because of the control coding. Choose a better one

Hello, I'm a high school student in a summer engineering program, and I am working on building a self balancing robot using the Edison platform and the corresponding sparkfun blocks. I was wondering if you could help me uploading your code onto my Edison and getting my robot to balance. including what software I need to download, what drivers and programs, etc. I have been having trouble getting my Edison to interface with my computer and code. I have tried using Arduino IDE, and I have had problems with pin correspondence between Edison and Arduino. I am now trying to compile C code on the Edison, and I am stuck.

If you look in the instructions section, everything should be pretty easy to follow.

This comment has been deleted.

Have you had any problem with over coming the "deadband" in the motor? For example the PWM rate has to be ~40% with the pololu motors before the motors even start to move? I was expecting the "speed" PID to help with this but doesn't seem to be putting a dent in the lag between output speed and actual speed.

Cheers in advance.

Couple of questions.

  1. When leaning forward, in your setup does this result in a positive Pitch Angle? And leaning backwards results in a Negative Pitch Angle?

  2. When moving forward, does this result in positive encoder position counts? And when moving in reverse negative encoder positions counts?

That is what it looks like is going on in the software, I just want to make sure....

Great work. Your software is probably the easiest to follow I have found. Just a few questions.

  1. Looking at your code you use a complimentary filter to filter the pitch then you put it in the Kalman filter as well. Is there a reason you are using both? From my understanding you should only need one or the other?

  2. Other people have said the IMU needs to be placed directly between the wheels in order to not get offset error in our reading. I have also read that if you don't place the IMU in this location that you need to "zero" the IMU in order to compensate for its location. Since your IMU is on Eddies back, have you found this to be a problem as I don't see anywhere in the code where you are "zero"ing the IMU values.

Your thoughts are greatly appreciated, and once a again great work.

Thanks @bleckenstein I'm glad you found the software easy to follow. I try to write clear code when possible =)

For question 1.. I am using both (complementary and Kalman) mainly because I've not taken the time to tune the Kalman filter to give the desired response. By using the complementary filter I can easily smooth the estimated angle given to the Kalman which in turn gives a much smoother output that is easier to tune with the PID controllers. My hopes are someone with more experience tuning Kalman filters might come along and help this aspect of the project.

And question 2.. Yes having the IMU located directly at the point being measured will yield the highest accuracy result. AND You are right about the fact that I do not apply what we call a "casing adjustment" to compensate for the offset of location. However, the accuracy of the MEMS sensor and more so the performance of algorithms (in this case) are greater sources of concern for accuracy in my opinion. Regardless of this offset in position Eddie can balance quite well and in one branch that I'm tinkering with he's super smooth and can drive at higher speeds than what is seen in the original videos I've posted online.

Noted on above. Have you found any examples of people doing "casing adjustment". Does this require some funky trig. to get the vectors all realigned to the center of rotation or is there a simply way of accomplishing this? I have looked at a lot of peoples code and it doesn't look like many (if any) are doing anything to handle it.

Have you done any measurement on how quickly your control loop is running (timenow - last_PID_ms) ? I am considering porting to a slower/cheaper processor with no FPU and wondered how I would compare if I had to run significantly slower. I am thinking of running the control loop about every 5-10 ms.

Bummer. Thingiverse went down as I posted my reply and I lost my original explanation.

Basically you'd have to use a DCM ( Direct Cosine Matrix ) approach and multiply your accelerometer and gyro arrays by a calibration matrix to offset the position. You'd have to develop a calibration routine and jig to properly measure and generate a calibration matrix. I tried a quick google search but didn't find a direct answer to your question but there are a lot of documents on working with DCMs and I believe you can find an answer out there.

I did a quick check for you and the Edison is processing the control loop every 5ms and reports 15-17% CPU usage. I think that's pretty good for the starting point.

Thank for looking out there for me. I probably won't worry about it at this point as it doesn't seem to cause to much of an effect. I am guessing if you have enough torque and speed in your motor/wheel combination you can over come a lot of offset error.

Also thanks for checking your sample rate. Based on the previous version I built using a potentiometer on an lever arm instead of IMU I can probably come close to achieving 5ms.

Just printed parts now ordering electronics!


Hey that's great news! Since I haven't compiled an installation and setup guide yet I'd like to help you out if needed. Plus I have experimental remote control applications for Android, iOS, and Windows. I'll send you a message.

I just emailed you. Thanks for the help!

My plan is to try to do a Eddie with a bin instead of a head for holding small screws and things to help me at work.

Completely useless, but entirely awesome.

I'm looking forward to building a copy for myself. Is there any chance that the native CAD models are available for re-mixing? I would also agree with the comment about the build guide PDF document. It looks well organized and straightforward. Very confidence-inspiring!

Hey that is great to hear! I really look forward to seeing your build. I'm glad you like the build guide, the comments may just inspire me to do a bit more... maybe an install guide in the near future.

For now I'll upload EddieBalance 2.3.skp for you and those who like to edit this from the source in Sketchup 2015. Keep in mind the modeling isn't 100% perfect in a few areas (like the SparkFun logo) but netfabb takes care of what I'm too distracted to deal with =)

Very impressive!

Much appreciated =D

I especially congrat. your for the very clean wiring; a lot of projects should be inspired!

Thank you. And thanks for looking at the build guide. It isn't much I admit but I'm glad you appreciated the wiring.