I got a 4 - in - 1 sensor and have put together a 2 wheeled balancing robot. Now I need to figure out some coding. I have the Initialization script and it works good - getting lots of data. I'm not having any luck after that. Does anyone have some scripting they would be willing to share with me to help me get going?
Here's what I've got so far.Code:
ControlCommand("MPU9150", Init)
sleep(100)
:loop
#Added these because $AccelX and $AccelY were not recognized later in the script for some reason.
$XAccel = $AccelX
$YAccel = $AccelY
if ("x" =0)
print(1)
sleep(2000)
goto(loop)
endif
ControlCommand("MPU9150", RunOnce)
if($AccelX > 1000 and $AccelX < 1000)
servo(d4,108)
servo(d6,108)
endif
print("x: " + $XAccel)
print("y: " + $YAccel)
if($AccelX > 1000)
servo(d4,120)
servo(d6,61)
print(2)
elseif ($AccelX < 1000)
Servo(d4,61)
servo(D6,120)
print( 1)
endif
Sleep(100)
goto(loop)
I am working with a code that d. cochran posted awhile ago.
It will change directions when it is tipped but will never stop. Also, after it has run for 30 seconds or so it will just keep running and the only way to stop the wheels is by disconnecting the power to the EZB.
Asked
— Edited
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.
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?
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.
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.
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
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.
As I've previously stated in all similar conversations, arduino and mcu programming is great for repetitive tasks and monitoring. If I were to have any negative opinion of arduino than I would most surely and logically need to have the same opinion with gcc compiling on stm32 arm or ccs picc on microchip. please do not accuse me of anything not included in the current topic, specifically having a negative opinion regarding something that would contradict tools ezrobot current uses, such as arduino.
Lastly, if you have both of those robots, id love for you to share purchase locations so I can get them for research as well. It would be very useful. If you have something additional to contribute to this topic, that would be awesome - it's not a good use of my effort in this thread to discuss anything off topic.
I would prefer to focus our combined efforts on an inverted pendulum solution.
As I told you above who made them, but here you go, buy one at sociallyshaped.com and the other at robotshop.com.
What I have said in my post was to help out the original topic of 2 wheel balancing robot.
Some more on the Balancing:
A PID cascade should be used, one PID adjust motors speed to maintain the angle and the other PID adjusts this angle. This would also allow a new set point angle for balancing if the center of gravity is moved.
I'll check those links and get those robots to add to my research collection.
The other is on RobotShop.com which I said above - they have it in stock.
I do have access to the codebase, one is opensource and the other is not.
Also, I will try and show a video of balancing robot and adding an adjustable wrench hanging off the front and still balances. I have another one that is about 3 feet tall and balances well also.
Ralph - Self Balancing Robot
This is why many companies pay Google or Microsoft to drive their search engines. Either of them would have searched synonyms.
Alan
*confused*
I type in "balance" and in drop down menu it shows self balance robot.
But I would think proper search would be "self balancing robot", my opinion.
I have only seen one video for this robot, but the robot does has a lot of documentation online.
Maybe a difference in the mobile web interface vs full interface. I was searching from my phone, and had no luck.
Interesting looking device now that I found it. A bit pricey for what it does, but this is not a cheap hobby....
Alan
@thetechguru - not a cheap hobby at all, but it was cheaper that my main hobby of drag racing Mustangs. There are a few pretty decent self balancing robots out there.
However, the challenge ez-robot is taking on isn't a simple balancing robot. EZ-Robot's inverted pendulum is taking the challenge to make anything inverted balancing. Meaning a selection of motors, wheel sizes, hbridges (for differing motor sizes), voltage, and robot sizes.
The reason that above video is working with the inverted pendulum prototype is that the pid and algorithm is tuned for the voltage, hbridge, motors, wheel size, and weight.
The idea of the inverted pendulum is to provide easy options to the user to very simply fine tune an inverted pendulum balancing robot that was built within the range of hardware specifications.
The reason i'm looking at other balancing robots is because everyone does the pid and other work within the main loop a little different - and i'd like to learn what others are doing to assist with our goal. Sadly, all of the open source code that i have seen is either very inefficient or only works due to pure fluke because sometimes the PID's don't even make sense. Those with professional knowledge of programming can view the code and see unused variable declarations, re-assigning variables with nullifying previous calculations, and a pile more.
But - that doesn't mean EZ-Robot giving up on the inverted pendulum
I think the balancing action is neat and ppl r curious about it... that's probably the only interesting part lol
For me it is because it looks cool, which improves the WAF (Wife Acceptance Factor). My wife has been much more supportive of my robot supplies purchases and the time I spend on them since I got a Six. Six is the most useless of my robots, but looks and moves the coolest, so she understands why I want to build them. If I could build a balance bot, it would amaze her, and I would have another year of high WAF.
Alan
@DJ, just don't tap it, push it. Are you using a cascading PDI?
Yours looks like it may be using SainSmart stuff? Could be wrong.
The last one is very crafty (wood details).
@DJ,
Does yours works without encoders ?
Most of them use encoders, i don't know if is a requirement to handle the balance or not.
If there are no encoders, the encoder pid is disabled.
Heck, humans have made it pretty far balancing on two feet!