Here is the Jegway Rev2, an improved version of the Jegway Rev0. It uses a gyroscope and also an accelerometer. In addition, I added a PS2 remote controller so I can send it around the house and bother people.
Here are several videos of the device.
The first video just merely a demonstration of the device.
The second video show in more detail the PS2 controller’s individual inputs, as well its response to disturbance.
The last video shows failure to compensate for forward angle tilt, and as a result the device falls and fails (and subsequently the earth explodes).
There are a great many resources on the web about the control system required by an upright pendulum. There are also many ways to implement such a device. I have decided to use PID controller to do the job.
A PID controller stands for a Proportional, Integral, and Derivative controller. In the case of a Segway, it is best to visualize the contraption as a upright pendulum. The pendulum has two steady state solutions: standing upright, and dead on the ground. The goal of the circuit and the program in the NXT brick is to keep the device in one of the steady state solutions. Since the natural tendency of a upright pendulum is to fall down, the contraption must constantly fight this phenomenon. In a PID controller, the actuation to the motors is calculated depending on what the “error” is. In order to calculate the motor actuation, the error must first be measured precisely. This is done by reading the accelerometer and the gyroscope. By comparing the current reading and the previous measurement, the error is calculated. Next the P, I, and D portions of the actuation is calculated from the error and added together. This error compensation is then scaled to a motor actuation command and then corrects for the measured error. The concept of a PID goes something like this:
1. Measure the sensors
2. Compare with previous measurement to obtain the error
3. The compensation is calculated with the P, I and D from the error
4. The motor actuation command is scaled from the compensation
5. Motors correct the pendulum, and the process is repeated
The reason that a PID controller works so well is because each portion of the P, I and D compensates for a certain type of error. P indicates that if the device is significantly tilted, the motor needs to turn a large amount to compensate for the tilt. If the tilt angle is small, then the motors need to turn a small amount (hence “proportional”. The I portion signifies an added sum of tilting. For example, if my pendulum has been tiling in the same direction for a very long time, even though the P portion has been trying to compensate, then obviously it’s not doing a great job. Despite the P portion of the correction, it is still tilting in the same direction, and the device is in danger of falling down. The integral adds up all those errors, such that the longer the device has been tilting in a direction, the greater the motor compensation will be. Lastly, if my upright pendulum is falling fast, then the motors need to make a huge compensation, if it is falling slowly, then it needs to make a small compensation. Since the speed of the fall is the derivative, this is the D portion of the motor compensation.
Through this process I wrote a RobotC script that loops every 1 millisecond and repeat the measurements and and motor actuation. The end result is a super cool little toy that is homemade, and completely customizable.
If you ever want to try it out for yourself, here is the RobotC code. Of course you’ll need to buy the Lego NXT set on your own. Leave a comment if you got questions. You’ll probably need to change some of the constants for your own device.
Enjoy!
Hi,
Great work and thanks for publishing the code. The question I have is your gyro seems to be mounted to point downward, whereas earlier HiTechic gyros were designed to point upward. How old is your gyro? Could you please post some closeup pictures of the sensors. Using your code and my old gyro sensor mounted upward spins the wheels, and the bot doesn’t balance at all.
many thanks — Rade
Hello!
It looks very nice! Is that binary code, not source?
I’ve built my own NXT segway, using the hitechnic accelerometer and gyroscope. However, I cannot for the life of me get the PID constants tuned correctly. I’m using a complementary filter to combine the two signals. It seems no matter what I do, I can’t find stable constants. What is your secret? How did you decide on the constants you chose? It really doesn’t help that these things are so tiny and have such a low moment of inertia.
Thanks,
Dylan
Hey Dylan,
I’m glad you tried to do it on your own. Set all P, I and D constants to zero and pick an arbitrary constant for the motor. Next increase P until the device starts to balance (it should fall in a few seconds due to over/under compensation). Next increase I, slowly, keeping P constant. When it can stay up for a few more seconds, you can increase the D just slightly so stabilize. It took me two weekends of trial an error, so if you’re having trouble, it means you’re on the right path. If you got it on the first try, then you’re probably doing some wrong.
-J
J,
Thanks for the information! I’ve just been willy nilly changing the constants trying to improve the balance. I’m happy to see that there is actually a method
. I’ll give it a shot tonight and let you know my results.
Thanks,
Dylan
J,
I’ve still yet to get my little segway to balance. Your tips did help a lot and I have a much better understanding of P.I.D. control. However, I think where my problem lies now, is that as I’m tuning the constants, my batteries are getting lower and changing the actual speed of the motors. Did you face this issue at all? If so, how did you correct for battery drain? I don’t remember seeing anything in your code that combats it.
Any comments on this?
Dylan
Also, I’ve actually rebuilt my little segway to more closely resemble what you show in your videos. It’s by no means exact, but I’ve now supported the axle on each motor on both sides so that there is less unintentional toe on the wheels and things are generally more rigid.
Dylan
I’ve only had problems when the batteries were extremely low. The control system will compensate for any changes in motor drive. The placement of the acceleromenter is critical. If you think about it from a physics perspective, the position at which you will get the most precise reading from the acceleromenter is if it is placed at the axis of rotation (of the system, NOT the wheels! Ie. When the system is trying to balance, it is the spot that receives the least amount of movement). If it is placed far from the axis of rotation, then things such as centripital force and/or readings from falling will make the readings inaccurate. The gyroscope however, since it is a mems device, should be fine placed anywhere.
Tell me how it goes.
-J
J,
Man, ok, so I think I figured out why I’m having so much trouble tuning the PID coefficients. I’m using a complementary filter to combine my accelerometer and gyroscope data. I think the response time on this type of integration is too slow. I was reviewing your code, and it appears that you barely even utilize the accelerometers signal, accept for minor adjustments to the angle depending on the direction of the error. I can only assume that this is to correct the gyroscope drift (as well as get a reference angle at the beginning of the program).
Have I made a correct observation?
Dylan
Something like that. I wrote the thing 2 years ago, so I don’t remember most of it. If you read the write up for the Jegway I think I might mention something about how I use them.
-J