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
I followed the link, looks quite interesting. PID algorithm and tuning are definitly the key points for efficient balancing. In our global village, you have to bite the bullet and use the Dominant Language (used to be French some centuries ago :). gbm, care to prepare a "variable PID for dummies" and post it here ???
I just wanted to thank you again for your post *balancing robot for dummies* it helped me a lot, and want you to be the first one to see my improvements:
this is using a complementary filter and PID with a sparkfun IMU... going to use encoders soon and then RC control.
I was wondering, is this any good? how much better can I get without using encoders? why is it drifting like that when I push it harder? Tunning more P or D doesn't help! any comments about it would be greatly appreciated
Hi Nahua, welcome Thanks for your PM and the nice words your bot is balancing pretty well, congratulation
P(i)D tuning seems optimal The forward/backward drift is typical and normal, it will disappear with your encoder implementation
Are you still using EMG30 motors?? can you quantify backlash ??
Oh... one last comment. Don't be shy, make it taller
I have used the xBees for a wireless serial link and also for wireless code uploading.
I am currently working on wireless debugging using Xbee and Patrik's Balancing Bot GUI. The two ways communication between bot and PC is OK, but I didn't succeed wireless code uploading sofar. I understand additional components are needed to force reset, please elaborate.
Is your bot balancing now ??
Has anyone tried this project with stepper motors? Would this make the task easier or more complicated?
I have seen lots of balancing bot using continuous rotation servo motor or DC motors (with or w/o encoders). I have yet to see a working implementation based on stepper motors. I am not to familiar with stepper motors, but I clearly see the interest of your question. Others will certainly jump in with additional info.