I am trying to use the Baby Orangutan to drive the motors in a self balancing robot. To do this I need to have the forward and reverse directions work the same way. I can’t figure out how to do this with the built in hardware PWM.
In particular: If the hardware PWM drives PB1 then, to go forward I set PD5 low and, PD5 high to go backward. The problem is that when going forward to H-bridge goes between forward and standby in the forward direction but between reverse and brake in the backward direction.
This makes the motors behave differently in the two directions.
Is there a way around this or am I missing something?
You’re definitely right about the motors behaving differently. Jim Remington’s page has a neat discussion about this, and about Orangutan PWM motor control in general. You’ll probably want to use break mode in both directions for a more linear speed/PWM ratio (or maybe not, its worth testing).
I would try using Timer0 for PWM on PD5 and PD6 for one direction, and Timer1 for PWM on PB1 and PB2 for the other. Basically you’d have both timers running all the time, but for each motor, one input would always have either a 100% or a 0% duty cycle, while the other actually twiddled. If you Set Timer1 to 8-bit fast PWM mode, Timer0 to fast PWM mode (naturally also 8-bits), and use the same prescaler for both, you should have precisely the same operation forwards and backwards!
The LB1836M could really use an “enable” pin separate from the mode selection pins. Another solution would be to get such an H-bridge, but you would need to do some fine soldering to get at the timer compare pins. Probably better to make use of the Baby-O’s internals for compactness.
So, do you have plans for the rest of your balancing-bot yet? Have you picked your motors, and what kind of sensors it is going to use? And not that you want something prefab, but have you checked out BalBots.com?
Good luck, and please post any project updates/questions!
Thanks for the suggestion to use BOTH Timer1 and Timer0. I was trying to use 16 bit PWM so I didn’t consider Timer0, but that’s silly. Using both timers doesn’t allow the really fine control that Timer1 has but I suppose that isn’t really needed.
I’m trying to do the whole thing for a parts cost of $50 or less. Not sure if I can but that’s the goal. To meet that, I may need to abandon the Baby-O, which would be a real shame. To make things harder I’m using an accelerometer as the sensor instead of IR like BalBots.
Thanks again for the suggestion and I’ll report back if I get something working.
Sounds cool! Yeah, for small motors eight bit resolution should be plenty, especially since you can adjust it on the fly. A nice high PWM frequency is going to be much more important, and higher resolution actually limits you to lower frequencies on the same clock. My guess is that with the 20MHz clock and eight bit counters you’ll want to use 8 as your prescaler (~9.7KHz).
Yeah, it’d be tough to keep the whole thing under $50 with the Baby-O eating half your budget. What kind of accelerometers were you looking at?
I’ll be curious how the accelerometer-only approach works. One of the guys in our local club built a balancer, and wound up using both an accelerometer and a rate gyro. I’m pretty sure he was trying hard not to take that route. I get the feeling the reason is the same as why pendulum-based parachute deployment systems don’t work for model rockets: When the rocket is nosing over, it’s more or less in free-fall. So what’s “down”?
I’ve been interested in doing a Balbot style balancer using a Baby-O. I’ve got the Sharp IR rangefinders on-hand, so it’d be low-cost for me. But yeah, if you’re trying to keep your total parts budget under $50, the rangefinders blow the cost up in a hurry, too. Depending on your source they can eat up a good 2/5 of your budget.
Another approach to doing the symmetric forward/reverse thing is to use a completely interrupt-based approach. The 168 is busier this way, but since the interrupt handler just fiddles the bits in whatever way you want, it has a lot of flexibility. This is how Orangutan-lib works at the moment. (Though after running into some problems with my line follower, the next rev is going to have more options.)
Please keep us posted on how your balancer turns out. I haven’t built one, but it’s fascinating to see how many different sensing approaches have been used with such good results.
The rate gyro and the accelerometer make up for each other’s problems.
The rate gyros can’t tell where down is. You can have a zero rotation because you just managed to stop the robot from falling over as you start to get the wheels under it. If you interpret this as balanced you just start to fall again. Not good.
The accelerometer can’t tell the difference between tilting and accelerating. So if you correct your tilt by moving, the acceleration of moving can result a zero reading before you are balanced. Also not good.
In the standard approach the two sensors check each other.
I’m going to try to use that fact that the controller knows when the motors are on to account for non-tilt accelerations. I don’t know if I can get it to work.
I decided against the IR approach for two reasons:
It’s too easy.
It won’t work on an uneven surface.
I realize that I have no right to reason (1) because I haven’t built one. If I can’t get my approach to work I may back-pedal and try IR.
The newer Orangutans have symmetric behavior for forward and reverse built into the hardware. For the original Orangutan and Baby Orangutan, the only way you can get symmetric motor driving is to toggle the appropriate I/O lines in software. You can use the timer you would have used for hardware PWM to generate interrupts to limit the processing overhead.
