EquipoiseBot is my two wheeled self balancing robot. It can be controlled using a homebuilt IR remote. This robot is based on a couple of PIC microcontrollers that work together. I have built all the mechanics and electronics from scratch.
The robot uses two accelerometers and one gyro to make it balance. Two different values representing the angle of the robot are calculated. One from the accelerometers using the mathematical tangens-funktion and one from the gyro using integration. Those two angle values are combined in a filter to make one new value which is used as input in a PID regulator to contol the motors, keeping the robot in balance.
The remote is built in the casing of an old transmitter from an RC helicopter. The transmitter sends the X and Y positions of the control stick over IR using using standrad 1200 baud serial data modulated with 38KHz and a homemade data protocol.
The steering signal from the remote is just added to one of the motorsignals and subtracted from the other. The forvard/reverse signal from the remote are added to the angle value after the filter described above. The steering works great but the forward/reverse is far from perfect. The remote is commanding the robot to lean at an angle, not to drive at a commanded speed. There is nothing preventing the robot from driving to fast, if this occurs it falls over. This makes the robot hard to control.
EquipoiseBot is equipped with quadrature wheel encoders. Those are not used at all but in the future they can be used to make the robot stand still in one place, or to improve the remote control function.
mathematically mix-in RC command as angle into the stabilizer
The way you mounted the cables using a serial cable plug is smart. But to mathematically mix-in the remote control command as angle into the stabilizer is brilliant. Thank you for sharing this. Collected!
Using some sort of rotation to convert linear movement into a turning moment, could that help to attack the “fall due to driving to fast” problem? That could be: When velocity exeeds threshold then rotate 90° very fast and stabilize.
Wow another nice build. I remember your first post and what a great build that was. Runs really well too. I can’t wait to see what you’ve got for us next. One thing,well two I’ve wondered about balancing robots is can they be driven at a tilt say to go under something lower than them and how far can they tilt before they reach the point of no return?
Thank you NilsB for your comments. I think converting the linear movement into turning moment would just make the robot fall over to the side. I believe it is better to try something like: When the velocity exceeds a predefined threshold, apply maximum power to the motors to make the robot lean the other way and then slow down. But of course, I would have to use the encoders to do this. I will not continue to develop this robot right now, but probably in the future…
Thank you Merser. I do not believe it is possible to make the robot lean enough to get clear under an obstacle as you describe. To counteract the force from the leaning the robot has to accelerate. In a very short time the robot will reach its maximum speed and fall over. The maximum tilt angle depends on the maximum possible acceleration.
In the first picture with a part of the Baltic Sea in the background you can see that the robot is leaning slightly forward. This is because the wind, one of the disturbing factors, is affecting the robot.
Your workmanship is superb. There are not many people who have a mastery of mechanical, electronics and software and you are one of the few, what excellent work! All your projects are testimony to the effort and attention to detail you apply.
I’m interested in how you program all the separate PICs, do you do this external to the robot and plug them into the hardware or do you use a port and multiplex the ICSP bus ?
