How about you. It seems you are interested about control as well. Any other interesting projects or something?
I worked for a process control company for many years. We used to produce and sell DCS (Distributed Control Systems) and Plant Automation sensors with 4-20mA interface. I started a new exciting :o :o :o project also based on control/balance. I wont talk about it now to avoid polluting this thread
I have seen balancing robots using simple servo motors which are pretty slow compared to other DC motors. Is the motor choice so important afterall?
My first balancing robot was based upon servo motors, using a Parallax Basic Stamp processor.
I am from Cyprus (where the temperature dropped under 20 degrees just yesterday...oof)
I'am jealous >
The only problem is my motors. I have these http://www.pololu.com/catalog/product/1123 cheap motors. I believe they will be able to balance the bot for tiny angle errors but not if I push the robot. What do you think?
You are right, the processor itself is not the main part of the project. My initial intention was to describe the process using pseudo code only. I wanted to avoid people to just "copy/paste" code, and make sure they understand what they are doing .
You are welcome back with questions , and to share your development.
Not much hardware stores in my country, so everything has to be ordered through the internet which delays the whole procedure a lot!
Short of getting local convenient sources, most of us, in Europe, purchase in the USA (Sparkfun, Adafruit, Pololu...) Out of curiosity, where are you from ??
While my bot is sitting on the shelf, waiting for a new leg, I re read the all thread. :o :o
Let me thank all the contributors: zalo, novice, haha97, thinkaneer, cr0sh, josev, Onions, Gibby623, Ro-Bot-X, granyte, killersquirel11, WanaGo, Patrik, wowmir, gbm, hoyeungl, T.J.L., pramlie, Jon D., uncle_tom, RWehner, GuzZzt
Some have been rather silent recently, please stop by and share your new positive/negative experience.
For the silent others who helped generating the 28,000 read pages in the 2 threads, please introduce your project (with photos ). Let's establish this thread as a reference for others to find both inspiration and technical information.
If your boot tells you he can fly , [size=14]don't trust him[/size] The takeoff from the mezzanine was OK, only the landing 3 meters below did create problems
Well c'est la vie :-/
I have to stop active development for some days (Xbee wireless RC is 90% completed) For those who have started building a balancing bot, please register and share your design and/or your source code. Any new development ideas are also welcome.
I use one encoder, one channel only. As you say, 464 counts per wheel revolution is more than adequate. In your case, quadrature (look here) will definitly increase resolution. I currently use only one interrupt (#1) and check, whithin rencoder, the other channel logic state (regular I/O). I make a first right/left motor speed adjustment within code, and fine tuning through micro joystick trim:
The second encoder can also be used for this task, but I hesitate to create a second interrupt within the code.
[size=14] ** Balancing robot for dummies **[/size]
[size=14]Part six: Motor encoders and V2.0 code[/size]
Before even thinking about R/C wandering, a well-mannered balancing robot has to learn to stand still > Without encoders the best achivable attitude is The bot is aware of his vertical tilt angle, he does know anything about his position. Lets add motor encoder(s)
A two-channel Hall effect encoder is used to sense the rotation of a magnetic disk on a rear of the motor shaft. The quadrature encoder provides a resolution of 64 counts per revolution of the motor shaft. To compute the counts per revolution of the gearbox output, multiply the gear ratio by 64. The A and B outputs are square waves from 0 V 5 Vcc, 90° out of phase. The frequency of the transitions tells you the speed of the motor, and the order of the transitions tells you the direction. The oscilloscope capture shows the A and B (yellow and white) encoder outputs.
By counting both the rising and falling edges of both the A and B outputs, it is possible to get 64 counts per revolution of the motor shaft. Using just a single edge of one channel results in 16 counts per revolution of the motor shaft (16 X 29 = 464 counts per wheel rotation).
- plain DC motors - coreless motors - brushless motors - continuous rotation servos - spurs gearbox - planetary gearbox - belt transmission - ... the perfect cinematic chain still needs to be identified :-?
patrik, I also noticed that motors have different forward/backward response. Make sure that you use the total potential power of your motor. Monitor you PWM output, and check that value is not clipped by the K parameter.
Backlash may be addressed within the code Look at this one:
cheap motors with plastic gears, small wheels, excellent results :o I hope Dominic will jump in and share his experience
just bought 2 RE-max graphite,22W, 16Amax, VNA30A dual control fron spark and ITG-3200 for my next 4-wheel balancer, I need to learn about li-po whats that coming over the hill, is it a monster, its a BF952.
beautifulsmall, This new digital output gyro looks promising. Please let us have a link to the motors you mentioned
How did you read the SPI bus? Does your processor support SPI, or did you implement a bit banged solution?
ATmega168 and 328 are supposed to have built-in hardware support for SPI I still manage the MCP3208 by the bits Look here and here
What processor are you using ??
@Jon Shall I understand that you build robot at school?? lucky guy You are also lucky because robot technology will develop quickly, and you will probably never fear unemployment... I understand you are developing a different software, but still, can you check your raw sensor value and make sure that you get a symetrical pattern, as per photos in reply #113 Looking at the bot height, I suspect you are not a shy guy Anycase, good luck for your exams. I hope you will come back later and give us additional infos on state-feedback.
@Patrik Belt transmission is probably the way to go for zero backlash, but not easy to implement Are you using the Pololu 350RPM motors ?? I confirm that backlash is noticiable, but it doesn't prevent proper balancing.
I started to check the differences of the motors by using the encoders to try to see the distance the motors turned in a constant time and get a factor for the diff. I drive the motors in both directions in four different speeds 50, 100, 200, 250..
Im starting to implement encoders and then make: torque = P1 + D1 + P2 + D2 (1 = error from sensor --> complementary filter) (2 = error from encoders)
You are on the right track More info later this week
Hi Osman, welcome, thanks for your comments
1. Is a 10ms loop sufficient, or should I try to go faster if my peripherals allow it?
100hz is plenty. I adjusted loop time up to 200Hz without any significant change in attitude. Try for yourself and make sure that your processor can cope with the situation (STD_LOOP_TIME - lastLoopUsefulTime should be >o), especially if you send wired or wireless debug info to your PC
2. I can't access the A2D on my CPU. I need to purchase a separate A2D chip to read the gyro. Is a 10 bit A2D sufficient, or should I go 12 bits?
Go for a 12 bit ADC
3. Can anyone suggest a good standalone A2D for a balancing robot?
I strongly suggest MCP3204 or 3208. I am currently testing this chip, source code available on request
The robot Is starting to get heavy, 2.359 kg , don't know if that can give me some troubles..
Thanks for the link IR memotes are nice and inexpensive for R/C They are very good at ON/OFF control, but for Analog/proportional they lack flexibility. In our case, analog joysticks are much better for the job
I will post new tutorials (encoders, R/C control) later this week