This cannot be done with the ezb - also, the code is not as simple as change direction based on falling.

Firstly, the data from an accelerometer is noisy due to the nature of the sensor. This is why sensors combine gyro. A gyro combined with the accelerometer with a complimentary filter is the most efficient method. There are other more complicated filters, but that's usually not necessary.

Once you get the two sensors combined to return a trusted value, the next step is to define a pid filter.

The pid filter uses three parameters to calculate the power/force required to correct the error. The value inputted into a pid filter is the sensor data, which is considered the "error".

The pid calculation will provide the force necessary to correct the error.

It's also a good idea to convert the error into degrees rather than an arbitrary number returned by the sensor. That's simple atan2 math.

The values of the pid must be adjusted per application - and per battery charge, because the force of the motors over time will decrease as the batteries drain.

The ezb communication is too slow. You will need to sample the sensor data every 10ms. I guess that can be done with the /2 but not the regular ezb v4.

The way reliable balancing robots work, such as the woweee toy is because the entire platform is engineered static. Meaning you can't change it. It is what it is and that's all you will get.

The inverted pendulum that ezrobot has been struggling with is a dynamic calculation to balance nearly anything. This complicates things, you can imagine - because it's never been done before. We have been close many times but not with varying hardware.

If the Inverted pendulum included an hbridge and motors and wheels that MUST be used within specified weight and height measurements, it can be done.

Releasing a product of that nature might end up being all we can do - due to the complications of doing it dynamically per application.

If you'd like to know more, research some of the pid and filters used online. Most balance projects don't work very well. I've ordered every balancing robot kit available and none of them work - I repeat, NONE.

Thanks DJ. So much for that project! I was looking for a project to learn more about the 4-in-1 sensor and how to program it. Perhaps I'll look at something that involves regular servos instead of continuously rotating ones. Any suggestions?

I have seen two self balancing robots work at MakerFaires.

1. husarion
2. sociallyshaped - the guy put a bottled water on the top and it was still balancing ok.

Just curious if you own those two and had different experiences?

I don't think either of those are available to purchase - or haven't seen them.

But again, as I stated - if you get the pid values tweaked for your application, it will work. I have had plenty of balancing robots working with the inverted pendulum prototype. But tweaking the pid was the biggest pain, as it took days! And with small changes to the structure or power, it required more tweaking.

It's best to reread my original post above to fully understand the challenges of a dynamic balancing solution.

I should also add that without encoders, balancing is darn near impossible without moving in one direction or the other. This is because the algorithm has absolutely no concept of the physical position of the robot. All it knows is the force it has applied in either direction to keep it upright (ie reduce error). Because of that, without encoders the robot will just run away.

Even though DJ does not need my support I have to validate his statement that PID's are a pain in the but and take day's (or even weeks) to get (even close to) right. I've been studying this issue for a while now because it's one of the issues I've had to overcome in trying to get the motors on the very heavy human sized arms of my Lost in Space B9 robot to move smoothly. Even motor controllers with an auto tune feature will fall short on anything but the most simple of movement needs. Then if any constant changes, even a little, like the weight of the load, external forces or power supply, the tune will fall flat and your motor will be jerky at some points. You can only imagine what a jerky motor would do to a self balancing robot.

In fact there are many automated manufacturing plants around the world that depend on proper PID adjustments to run manufacturing robots where the plant operators end up taking the machines off auto and run them manually. These plants spend tens of thousands of dollars to hire contractor technicians to come in to these plants to tune the PID's just to have the operators switch back to manual later on.

I should add that I have not given up on a dynamic inverted pendulum module. Everything is possible given enough time

There are plenty of projects for self balancing robots or Segway clones using gyro/accelerometers and Arduino. The difference is that that the Arduino can respond very quickly where EZ-B needs to report back to ARC, the computer needs to respond. By that time, the robot has already fallen over. Also, as DJ has pointed out, each of those need to be tuned to the specific h-bridge/motors or rotation servos.

If you need to build this before EZR gets the pendulum working, I would use an Arduino and sensor for balance, and communicate drive commands to it from the EZ-B via UART. (this is 3rd on my project list that I will probably never get to. I have plans and sketches for a Segway Clone from a Robotics with Arduino book, want to add EZ-B to make it able to drive independently)

Alan

None of the arduino sketches actually work. I've gone through a year of constant research to get ideas. That's why there are terrible quality videos and absolutely ridiculously inefficient and confusing code. If you do find a video that looks like it works, it was a fluke recording that took the person all day or week to get right.

All responses from anyone with no experience on this matter are hypothetical, even if you post links to "working balancing robots". It's a far more complicated rabbit hole than you're aware. The amount of fudged/fake arduino stuff on this subject is overwhelming as well. I do highly encourage anyone of you to explore the rabbit hole as well. It's valuable knowledge at any extent!

I have a number of self balancing kits, and they're all based on arduino - pretty much the same code as well.... they hardly work, if at all. I assure you most of the stuff out there is truly made up and faked or accidentally worked for one video. Take a look at the code and you will see how it's nearly all based on the same base, which uses one of two filters and a few variations of PID loops. The most remarkable thing you will find is all the arduino code out there contains redundant variables and some variables that are never assigned or even used. There's so many bizarre things in the code if you take a minute to look through it.

My code for the specific build i test with actually does work - but it requires specific configuration and the pid values constantly need tweaking. Also the encoders are absolutely necessary for the common sense reason I posted above.

Lastly, Alan is incorrect in that the ezb v4/2 can do it alone - but I wouldn't dedicate such a task to the controller. The slash 2 will communicate at well beyond the necessary poll rate. So will the iotiny.