Seg...stick.

Do-it-yourself self-balancing...things...have been around almost as long as commercial self-balancing things. Obviously the homemade versions are not as smooth, reliable, or failsafe as the real thing, but they are still pretty captivating. And they make great mechanical/electrical builds with some interesting control theory mixed in. In the final step, I provide a few references to good DIY self-balancing...whatever...builds.

In 2007, I helped with this other self-balancing scooter build at the MIT Edgerton Center, and since then we've gotten many interesting questions by email about how it works. Baseline self-balancing functionality is actually surprisingly simple, and maybe the purpose of this Instructable is to take this simplicity to the extreme. To that end, I present: Seg...stick.

Segstick is a self-balancing...well, literally some kind of broomstick I found in the MITERS workshop. It is powered directly by two DeWalt cordless drills chucked to two 6" wheels. The controller is an Arduino. Additional supporting devices include an Inertial Measurement Unit (IMU) from Sparkfun and two motor drivers from Pololu.

Is it the best DIY self-balancing vehicle ever? No, not even close. But it only took about two days to build, and it is stripped down to the bare necessities. Thus, I hope to point out the modules and concepts involved in making any self-balancing vehicle rather than the specifics of this one. To start with, some physics...

Step 1: Physics says it's easier to build a full-size self-balancing thing.

One question we get a lot is: Can this work on some kind of miniature self-balancing robot? Yes, but, the laws of physics make it harder to control a small inverted pendulum bot than a full-sized rideable self-balancing vehicle. 

For one, the mechanical time constant of a small self-balancing robot is faster. Imagine the difference between trying to balance a broomstick on your finger and trying to balance a pencil on your finger. The controller for a small robot has to be that much faster to keep up with the physical system.

Additionally, a human rider takes some of the burden off the electronic controller, since the human mind is a pretty good controller too. For example, the accelerometers used on self-balancing platforms can't distinguish between standing still and moving at a constant velocity, but a human rider can. The human rider can adjust by leaning forwards or backwards to speed up or slow down.

So, this Instructable focuses on a full-size vehicle, albeit a relatively small one. In the final step, there are some links to balancing robots.

Comments

[rkahn1]

Can you please tell me where I can find the schematic for the controller board. Machine Science is asking for BOM + schematic + CPL. I could not find those.

Thanks
-r

[scolton]

The controller on this project is different from the one on the "DIY Segway" project, which was based on a Machine Science board. This one is simply and Arduino Nano (manufactured by Gravitech, sold by many distributors) connected to sensors as in Step 7. Unfortunately, it seems that Sparkfun has discontinued the 6DOF Razor IMU in favor of newer, cheaper digital versions. I haven't converted this project over to digital sensors yet, so you'd have to adapt it on your own.

Hope that helps!

[rkahn1]

Thanks Scolton for your reply. Do you think using the newer sensor to be a challenge? I ask this since I have no experience what so ever working with electronic boards and sensors. Was the older sensor an analog one? And does the new one still connect to the same ports as the older one?

[Young_Maker]

How did you calculate the angle from the accelerometer? none of my values from several different methods seem to work very well, or line up with the angle from the gyro.

[scolton]

Steps 9 and 10 have all the details for how the accelerometer and gyro are merged together to create an angle estimate. I also have it in Steps 14 and 15 of my PCB Quadrotor instructable for a different IMU.

For the accelerometer, I use a small-angle approximation that says sin(theta) ~ theta, in radians. This is good to within 5% between -30º and 30º. So, to get the angle you need to subtract a "zero" value and then scale by the correct constant.

If you need to work outside of -30º to 30º, the most common method is to take the arctan of two accelerometer axes.

[prabhatnarayan]

hi scolton.
here i got 2 18x25 pololu motor driver but the pins are
TIXN
ERR
RST
TX
RX
VIN
GND

instead of
V+
5V
FF2
FF1
RESET
PWM
DIR
as shown in your 18x25 motor driver

so plz tell me what r the PWM & DIR pin in my motor driver.

[scolton]

Seems like you got the 18v25 Motor Controller instead of the 18v25 Motor Driver. Pololu separates "drivers" which have no on-board logic from "controllers" which have an on-board microcontroller. Drivers take a PWM and direction input and directly send it to the motor. Controllers need a different kind of interface.

On the controller, you should be able to use the RC interface (pins labeled RC1 and RC2) and the Arduino servo library to command the motors.

[ludina]

answer, please! what is the function of steering pot? How it affects on the controlling of ballancing robot?

[scolton]

The steering pot applies a differential command to the motors, after all the balancing calculations. It adds some amount to one motor and subtracts some amount from the other motor, which causes the platform to turn. The amount it adds and subtracts is set by the steering gain, KS.

[irethedo]

Where did you get the heat sinks for the Polulu High-Power 18v25 motor drivers and how did you attach them?

A picture would be nice...

thanks

[scolton]

They came from a scrap bin, but any old heat sink should work. A processor heat sink might be the right size (but overkill).

To attach, I used screws from the board into the heat sink. I put a couple of layers of Kapton tape between the board and the sink to insulate it.

[irethedo]

Thanks Shane-

after a little bit of thought, I am thinking of taking the fan off an old PC CPU heat-sink and just suspending it with 4 standoffs above both Pololu controllers but without a heat sink or mechanical contact point. This should be better than nothing I hope...

[irethedo]

Another question for you:

Your schematic shows A0 - A5 of the arduino connected to the Razor 6D0F but your code only uses A0 for the accelerometer input and A4 for the gyro input.

Is it necessary to connect the other Razor 6D0F outputs (A1 - A3 & A5) to the arduino and if so why?

(I might want to use those analog inputs for other things...)

thanks

[scolton]

No, it's not necessary to connect the other four IMU outputs to the Arduino. I connected them since they were convenient and because I didn't know which way I was going to mount the board. But you only need one accelerometer axis and one rate axis.

[aEx155]

Hey Shane,

I'm working on making a small robot balance, you can see my first attempt in this blog post:
http://makerandomstuff.blogspot.com/2011/12/introduction-fail-way-crappy-balancing.html
I've tweaked the platform a bit to make things neater but I'm still having trouble balancing.

The sensors from the Wii Motion Plus (gyros) and Wii Nunchuck (accelerometers) are outputting data over I2C and I'm filtering it to get g_roll, a_roll, and a filtered angle, so I think that part's good.

When I try to have my robot balance, it either oscillates a lot, or responds too slowly. I think the problem lies in my Kp/Kd values, my motor responsiveness, or my robot's small size (or a combination of 2 or more).

Any suggestions?

[scolton]

Cool project! It sounds like you're running up against what I call the "robot segway" problem. It's the reason I said in the Instructable that I think building a robot segway is actually harder than building a full-size rideable segway. You're right that the small size makes it harder to control (faster time constant, like balancing a pencil on your finger as opposed to a broom). But there's something else even more fundamental that makes it hard:

The sensors are inertial, meaning they respond to acceleration. They can't distinguish between standing still and moving with a constant velocity. So, even when tuned properly, the robot segway can't really stand still by itself. It will either oscillate (if the gains are high) or stay near vertical but drift off in one direction until the motors can't keep up, at which point it falls over.

A human rider can sense that the segway is drifting off in one direction and correct by leaning forwards or backwards to bring it back to zero speed. To mimic this, the controller would need to know the velocity (maybe from wheel encoders) and control it to be zero. This adds extra states to the control system and makes it more complicated. I attempted an autonomous balancing robot with no encoders with moderate success here:

http://scolton.blogspot.com/2011/05/mini-segstick-my-mid-quals-crisis-robot.html

Others have definitely done it with success. There are a few links to robot segways in the last step of the Instructable. Another option is to use radio control to guide it as a human rider would, preventing it from building up too much velocity when it should be standing still. Here's an example of that solution in action:

http://machinescience.wordpress.com/2011/11/29/ps2-module-controls-two-wheeled-balancing-robot/

[aEx155]

Drifting problems aside, I still haven't been able to get it to balance like some of the other robot segways I've seen. Staying upright for at least 30 seconds is doable, right?

I've gotten my hands on a cheap nunchuck clone so I'll be updating the sensor system soon, and maybe making things a bit more solid.

I also have some motors with quadrature encoders built in (9v LEGO NXT motors) so maybe I'll go somewhere with that. Is there any chance I could take a look at the code you used for your mini-segstick? Maybe I can integrate encoders with that strategy.

[marquinho-a]

Hello Scolton,

I still can not stabilize my Segway. Also, I had a problem with my IMU and the gyro stopped working, so I had to use another one. The gyro I had at hand is an Epson XV-3500 (http://www.epson-electronics.de/upload/PresidioIndustries/product/QuartzCrystalDevices/Sensors/GyroSensor/XV-3500CB_710020500_data.pdf) whose sensitivity is 0.67 mV / deg / sec. My accelerometer is the ADXL335. I'm supplying 3.3V.

The calculation bellow is correct?

Accelerometer (ADXL-335):
(57.3 ° / 0.3V) * (5V/1024LSB) = 0.932 ° / LSB

Gyroscope (XV-3500):
[(1 / s) / 0.00067V] * (5V/1024LSB) = 7.287 (° / s) / LSB (?????)

The value for the gyroscope seems very high and the Segway completly unstable.

Kind regards,
Marcos

[scolton]

Am I correctly reading the datasheet for the gyro that it has:

Sensitivity: 0.67mV/(deg/s)
Range: +/-100(deg/s)

and that thus the voltage range is only +/-60.7mV, full scale?

If so, this sensitivity may not be suitable for use with the Arduino's ADC (at 5V or 3.3V reference). The signal might be just too small to get useful information out of. Even the Sparkfun Razer IMU gyro is cutting it close in terms of the available resolution, given the low angular rates typical on a balancing platform. (Under normal operation, 10-20(deg/s) might be the maximum rate.)

[marquinho-a]

Scolton, first of all thanks for your paper. I think everyone should read, it's really enlightening.

I think not because this project (http://diysegway.blogspot.com/) uses the same sensor and works very well (really stable). I would like to test the Trevor algoritm. The angle and the angle_rate are the tilt angle of the scooter in radians and its derivative in radians/sec. Is it the same that are in your code (rate and angle)? So, can I use the bellow code together your code? Are in same unit system?

Thanks for your help, I'm learning a lot!

balance_torque = 5.0 * (angle - rest_angle) + 0.4 * angle_rate;

overspeed = max(0, cur_speed - 0.5) ;
if (overspeed > 0) {
overspeed_integral = min(0.4, overspeed_integral + min(0.2, overspeed+0.05) * dt) ;
}
else {
overspeed_integral = max(0, overspeed_integral - 0.04*dt);
}
rest_angle = 0.4*overspeed + 0.7*overspeed_integral;

steer_cmd = 0.07/(0.3+abs(cur_speed)) * steer_knob;
cur_speed += 1.2 * balance_torque * dt;
left_motor_pwm = balance_torque + cur_speed + steer_cmd;
right_motor_pwm = balance_torque + cur_speed - steer_cmd;

[japper]

I have been having problems making mine stable also but just stumbled across something yesterday in another tutorial about building an arduino segway that I plan to investigate.

In that application, they are using a sparkfun razor gyro & accelerometer which is connected to the 3.3v just as it is in Scolton's instructible but what is different is they tie the 3.3v line on the arduino to the Aref pin an then use the following command in the setup section of the code:

analogreference(EXTERNAL);

Here is the explanation:
the normal range for the 10 bit ADC (pins A0-A5) is 0 - 1023, where 0vDC input yields a value of 0 and 5vDC yields a value of 1023. If you plug a 3.3v sensor into an arduino analog input, the maximum value that an arduino can read is approximately 675 or so. (3.3v / 5v *1023), to get full range using a 3.3v device, you must connect the desied reference volage (3,3v) to the analog reference pin (aref) an add a line of code to the end of the setup() function to tell the arduino to use an external analog reference voltage.


I haven't tried it yet but this might smotthen things out as mine has been vey sporatic...

If you get a chance to try this before I do, please report back waht you find.

thanks

[marquinho-a]

What are you talking to me sounds correct, but I think it is not the solution to problems. I think I've seen most of the tutorials found on the internet and I found more stable until today was one of the first to be created: the Trevor's algoritm. He did several tests, both in high and low speed. I'm thinking of rewriting the code from it to a version compatible with the Arduino, but it will not be easy. The code it is large and somewhat complex. Would you be willing to help?

My MSN is marquinho-a [at] hotmail [dot] com, and my Gtalk is marcospassos.com [at] gmail [dot] com. You can add me and talk more to share experiences.

Kind regards,
Marcos

[marquinho-a]

Hello Scolton,

I'm using a Sparkfun 5 DOF, OSMC controller and two 450w 24v motors (MY1018z). Although my Segway can balance itself, it can't balance a person (seems to have no force, slowly). I've noticed my Gyro (IDG-500) has
2 mV/°/s of sensivity, so my LSB is [(1º/s)/0.002V]*(5V/1024LSB) = 2.4140625(º/s)/LSB, right? Anyway, it can't balance as well.

I also have noticed that over time the platform starts to get steep and considers it as level.

Do you have any tip?

Thanks,
Marcos

[scolton]

I would agree with jaysetlle. From my own experience, if it's balancing itself without oscillating, then the gains are probably too low. Without the rider mass, the gains should be high enough that the platform by itself seems jerky or oscillates. When you add the mass of the rider, it should become stable and have plenty of force for keeping you upright.

(Of course, that's for a very light platform like segstick. The more the platform weight becomes significant compared tot he total weight, the closer the gains should be for rider and no-rider.)

[marquinho-a]

About the LSB, is correct? Scolton, can you provide or explain how we can move forward and backward programatically? I think that is increase or decrease the zero angle but I don't know how to do it right. Another question is about the best place to put the IMU sensor. Can you tell me it?

[scolton]

Yes, your LSB calculation looks correct assuming 10-bit ADC. Do you mean how to make it move forward and backwards on its own with no rider? Or how to change the zero angle so that it is level when you step on?

The best place to put the sensors is in the center of the horizontal platform, as close as possible to the axle line. They should be shock.mounted to prevent mechanical vibration from affecting the MEMS sensors.

[marquinho-a]

Ok about the position of sensor. Yes, with no rider. Do you have any experience about it? I was talking about it with Trevor and he has said it have no secret, it only change the target angle, but in this case the target angle isn't explicit in the algorithm to be changed. I believe that in your algorithm, the target angle is fixed as zero level, and the PID try always keep as 0, right? So, how can it work in this case?

[scolton]

Okay, I understand now. One thing you can do is modify the software to take an average of the first N samples (maybe after a delay to let the power supply stabilize) of the accelerometer and use this as the zero angle (A_ZERO). This way, you can turn it on and hold it at the proper angle for balancing with no rider. Alternatively, you can Serial.write() the raw accelerometer value while holding the platform at the correct angle for balancing with no rider, and then hard-code it in.

Even with the correct angle, it is difficult to get the platform to stay balanced by itself. None of the full-size balancing platforms I've built can do this. The problem is that the sensors are measuring inertial effects, like acceleration. They have no way of knowing the difference between standing still and moving at a constant velocity. So it may be balancing, but it will pick one direction and move until it hits something. To get it to stand in one place, additional code is required that either uses a direct measurement or an estimate of the speed of the wheels. I made a mini self-balancing robot that attempted to solve this problem by very roughly estimating the back EMF of the motors:

http://scolton.blogspot.com/search/label/segstick

It worked okay, but wheel encoders would make it much better.

[jaysettle]

I have the same setup and have a problem with that too. Increasing KP and KD helped. I have KP at .90 and KD at 1.00! It helps a little but it's still just not fast enough-the vehicle doesn't get under you fast enough.

[marquinho-a]

About the LSB, is correct? Scolton, can you provide or explain how we can move forward and backward programatically? I think that is increase or decrease the zero angle but I don't know how to do it right.

[jaysettle]

The ATmega1280 chip has 16-bit resolution on the pins I'm outputting my PWM signals on to the gyro. I noticed you have 10-bit res in your equation:

[(1º/s)/0.00333V]*(5V/1024LSB) = 1.466(º/s)/LSB

I know that my LSB variable would be different but what should it be with 16-bit res and is it even worth it or does it matter?
My DIY segway for some reason runs slower using my ATmega1280(mega) than it did using the ATmega328(Duelmanove)in terms of corrections for it's angle, and corrections for it's angular rate.
I'm adjusting KP and KD in realtime with pots and it seems to help a little but it just isn't like it used to be. I also now have a quick dead spot right when the motors change direction. Not sure if these two symptoms are related but any suggestions would help. Thanks for all your work.

[scolton]

With 16 bits, the denominator would be 65536LSB instead of 1024LSB.

Not sure about the daed spot. Do you think it's mechanical? Both the DIY segways I've worked on have had enough mechanical backlash to make changing directions a pain.

[jaysettle]

Ok yea I got it figured out. It's just that segway already is noticeably slower in correcting itself using my ATmega1280(mega) than it was using the ATmega328(Duelmanove). A significantly lower gain on both the gyro and accelerometer would water down the values, slowing down reaction time even more, but hey maybe not.
I figured out the dead spot as I am using OSMC motor controllers which require four inputs and one of mine was off.
Unfortunately I fried the right osmc last night but will try the LSB change when I re-solder some new transistors on the motor controller.

http://web.me.com/jaysettle/Jay/diy_segway.html

[scolton]

Looks good! How are the leaning wheels working out? Does it feel natural to turn?

[marquinho-a]

Hi Scolton, congratulation for the good job! I'm using a Sparkfun 5DOF IMU (http://www.sparkfun.com/products/9268) and I'm trying get working but the out of output_right or output_left they always are increasing to 255 even when is stabilized horizontally. Do you have any idea what can be?

I have observed the IMU values and this one never stabilizes. The acc_x, for example, is always a random value between 310 and 315. So, even if I have adjusted the a_zero the value of acc_x oscillates.

output_left:
0, -1, -2, -2, -3, -3, -4, -5, -6, -6, -7, -8, -9, -10, -11, -12, -13, -13, -14, -15, -16, -16, -17, -18, -18, -19, -20, -21, -22, -23, -24, -25, -25, -26, -27, -27, -28, -29, -29, -30, -31, -32, -33, -34, -35, -36, -37, -37, -38, -39, -40, -41, -41, -42, -43, -44, -45, -46, -47, -48, -50, -51, -51, -52, -53, -54, -55, -55, -56, -57, -59, -60, -61, -63, -64, -65, -67, -68, -69, -70, -72, -73, -74, -76, -77, -79, -80, -81, -83, -84, -85, -87, -88, -90, -91, -93, -94, -95, -96, -98, -99, -101, -103, -104, -105, -107, -108, -108, -110, -111, -112, -113, -114, -115, -117, -118, -119, -121, -122, -123, -125, -126, -127, -129, -130, -132, -133, -135, -136, -138, -139, -140, -142, -143, -144, -146, -147, -149, -150, -152, -153, -154, -155, -157, -159, -159, -161, -162, -163, -164, -165, -166, -167, -168, -170, -171, -172, -173, -174, -175, -176, -177, -178, -179, -180, -181, -183, -184, -185, -187, -188, -189, -191, -192, -193, -195, -196, -198, -199, -200, -201, -202, -204, -205, -206, -207, -208, -208, -209, -210, -211, -211, -212, -213, -214, -215, -216, -217, -218, -219, -220, -221, -222, -223, -224, -224, -226, -227, -228, -229, -230, -231, -232, -233, -234, -235, -236, -237, -238, -239, -240, -241, -242, -243, -244, -245, -246, -247, -248, -248, -249, -250, -251, -252, -253, -254, -254, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255, -255...

[scolton]

What you're seeing is normal behavior. The analog input will have a bit of noise on it, so 310-315 is an okay range. The filtering will take care of that. Also even if you get the zeros correct to within one bit, there is always a some offset. The outputs are integrated, so the offset will cause them to move to one extreme if the platform is held at a fixed angle. They will never stabilize, and you'll only be able to test if it's working properly by "closing the loop" by putting the wheels on the ground and allowing it to try to correct itself.

[marquinho-a]

Thanks a lot, Scolton! I'll try it tomorrow and return you if I get working. About the potentiometer, what is the range supported? I have not found in the tutorial.

Regards,
Marcos

[scolton]

Anything from 1-100k should work. I used 5k. You can calibrate the center and the endpoints in the code.

[dreadengineer]

This is a refreshingly clear explanation of both the angle sensing and the control system. Thanks!

[teamtestbot]

Because I want to build your own Segway, I want to do this very project. But I only have a gyroscope, it is sufficient? It is to use any type of motor you have? I do not have a set of wheels without a motor wheelchair. I have found a coconut from fishing vessels that can be adapted in order to understand how to use the Segway. What will i do? Slope of the Segway, or I, I, I do write software or programs? I