Our team is looking into this and I wanted to do some research. I know the general use of the gyro and accelerometer, so what I’m really looking for is some discussion on how to use them specifically for balancing on the bridge. I did some searching on CD and I don’t think this has been brought up this year. I couldn’t really find relevant things from the past, maybe I’m just a bad searcher. :o
Apparently either can be used (gyro if you mount it sideways), though the accelerometer would seem to be the most logical choice because one of its main applications is to sense what direction “down” is. Is one easier/better to use? Program? Wire? More sensitive/doesn’t wander as much? Doesn’t matter?
For programming, it could just be as simple as hold this button once you’ve started to drive onto the bridge, and the robot will let you control the drive motors unless it detects that the robot is level. In that case we assume the bridge is tipped back to horizontal, so the robot will hold the drive motors at zero automatically and quickly. Simple test of the sensor, with a switch case/if statement/case structure allowing the output to the motors to be the joystick values, or a constant zero speed value.
Some additions could be to automatically reduce drive speed by 2x or 3x in this mode, or to disable when the robot is nearly level, or just under the maximum angle, in an attempt to stop driving once the bridge starts tipping.
If you want to have another robot join you on the bridge, you might want to program other features to help out. I’m not sure what those could be.
And of course you could do it all autonomously. Hold/press the button and the robot slowly drives forward similar to above description. This would complicate things a little more, especially if you want the speed to adjust based on how “tipped” the bridge is.
But all this begs the question…is using sensors and programming really necessary??? Are the drivers going to be able to drive on and level the bridge easily enough? Is it not worth the time and complication? How advanced should one go? As a programmer, I always have to remember that I am serving the drivers, so I need to make the robot easy for them to control in an FRC match environment. Help from automation or leveling sensors may complicate life more than help. I don’t know. Personally I think a simple version of the options I described above would simply be helpful and easier than manual driving. Especially if there’s an option to avoid or disable and revert to manual methods.
Thoughts? 2cents worth? Has another thread already been started?
That’s what I am doing and what the mentors expect from me.
It’s not really as simple as holding a button. Sure, the user end experience is that easy, actually developing is not as easy as that. How far do you want to drive? How will you know how far?
(gyro if you mount it sideways), though the accelerometer would seem to be the most logical choice because one of its main applications is to sense what direction “down” is. Is one easier/better to use? Program? Wire? More sensitive/doesn’t wander as much? Doesn’t matter?
The gyroscope and the accelerometer are useful for different tasks. The gyroscope gives accurate angular velocity data. The accelerometer gives an accurate angle off vertical but is sensitive to vibration and motion.
The most accurate system would use both sensors and a kalman filter (http://www.cs.unc.edu/~welch/kalman/) to combine the data. This will give you the best possible measure of your angular position, but will be hard to implement. I would try this if you want fast and accurate fully autonomous balancing.
If you just want to drive forward/backwards until the bridge tips, the accelerometer should be plenty. Just be sure to think about which readings you expect while the bridge tips.
There are a couple ways you could use the gyroscope alone, but I wouldn’t.
Regarding Kalman Filters… I wrote a simple one two weeks ago. I expect to expand on it and try getting the robot to balance.
You’ll need a PID Controller too. Kalman Filter just estimates a state from noisy measurements. You use that estimate as your input in the PID controller.
The sensor (gyro or accel) will tell us when we’ve driven far enough. The drivers themselves will control the robot until then, in my idea.
I suppose you could have it drive forward a certain distance, controlled by encoders, or time based, but that’s tricky and tweaking it takes a long time and it may be too variable.
Thanks Matt, how sensitive is the accelerometer to vibration and motion? I assume this means that it gives back a noisy signal that’s harder to make sense of? Will the bridge rocking back to level be any problem with this? We’ve never really used the accelerometer on a competition robot.
Yeah, the Kalman filter sounds nice. I’ve read a little bit about it and my first impression is that it’s a little too advanced for most teams, including my team. But all the power to you if anyone could get it working with better results. That would be cool.
For this post assume the Z axis is vertical and the robot drives along the Y axis.
The sensor has a resolution of ten bits. So your readings will be accurate to plus or minus 1/1024 of the full range (2G). So you can expect your readings
to be accurate to plus or minus 0.002G.
When the bridge is tipped it makes approximately a 6 degree angle=arctan(4/41). This means your accelerometer will read:
Z–0.995G
Y–0.105G
The Y component tells you the bridge is tipped. The Z component isn’t very helpful (same vibrations from the motors could easily induce a 0.003G difference).
Example 1:
Now say you start moving backwards slightly (perhaps to realign your robot). This is acceleration in the Y direction. If you accelerate forward at 0.1G your accelerometer now reads:
Z–0.995G
Y–0.005G
This looks like the bridge has tipped, but it hasn’t.
Example 2:
You move forward and the bridge tips. Your robot is falling so the accelerometer briefly reads:
Z–0.5G
Y–0.0G
What does your program make of this?
Example 3:
Your accelerometer is subject to a consistent 0.1G vibration in Y direction. Your accelerometer reads:
Z1–0.995G
Y1–0.2G
Z2–0.995G
Y2–0.0G
Z3–0.995G
Y3–0.2G
A crude program might decide the bridge tipped at time 2.
The gyro helps eliminate most of these problems by telling you if a rotation occurred. In example one, no rotation implies no tipping. In example two, rotation implies tippings. In example three, no rotation implies no tipping.
Wow, your post brings up some good points. You’re right, the gyro would eliminate a lot of problem from the accelerometer. I forgot that the accelerometer responds to motion (i.e. acceleration), not just the force due to gravity.
Another thing I thought of is that when the bridge stops tipping and slams down to a rest, there will be a spike in acceleration. This will be positive (upwards acceleration to bring downwards velocity to zero), and it will appear that the robot is angled, allowing the drive motors to move, or jerk for a moment. Of course the robot will roll and send the bridge off-balance if the jerk is large enough (I’m sure it would be).
This movement makes everything more complicated. I wonder if that means the gyro is the way to go for this task?
I was thinking of testing a sideway gyro and an accelerometer and see how it goes, but I was also going to add input from a sonar pointed down on the front and back to make sure it does not drive off and a sonar pointed forward and backward to detect other robots. Really this should be a human driver task, but a good “auto park” function could be handy.
There are relatively simple ways to do both. The following is how I would do them.
Gyro:
(This assumes the gyro is mounted so that it’s measured axis is parallel to the ground and drive base. So it measures pitch)
A simple PD controller should suffice for a single balancing routine. You may or may not want to add I if you plan to run it with multiple robots.
The PID controller’s output is fed to the drivetrain’s forward/reverse power. Simple as that
Accelerometer:
You would call atan2(accel.getY(), accel.getX()) to get the robot’s Pitch angle relative to the ground.
Follow the PD controller advice from the gyro.
Personally, I would go with a 2+ axis gyro. Mounted so that it would measure robot yaw and pitch.
Two PID controllers are running at the same time. One makes sure the robot is parallel with the bridge(don’t want to balance if you’re > 45 degrees to the bridge :yikes: ). The other behaves as above, maintaining the pitch.
Sure, it’s a little more complex, but it saves the driver the trouble of maintaining heading while on the bridge.
Controls wise, I would make all of that run only while a button is pressed. this allows for quick cancellation just in case something happens on the field.
Then again, you can go completely open loop and put all of this on your drivers. With practice, single robot balancing becomes a cinch. But the real fun happens when you get two or three robots on there :). The sensor way to go doesn’t care about other robots in the way.
For all of the methods, I would shift into low gear.
Ask away if you have any more questions.
Jeremy G.
I think that even a PD controller on the gyro may be overkill in this application. When we were trying to balance one or more robots manually on our ramp, we found that our drivers essentially implemented the following algorithm:
Start creeping up the ramp
Keep going until the ramp has begun tipping
Stop and/or reverse by a pre-specified distance
We found that putting your drive speed controllers in “brake” mode (or alternatively, using a drive PID controller that prevents rolling when the driver backs off the throttle) is essential.
Our ramp (being of the home-made variety) is much more sensitive than the competition ramp, but this basic approach seems like it works pretty well. The ramp has a fairly stable balance point; you just need to get it there!
Thanks Jared, that is insightful.
Then maybe all that is needed is a button for move forward slowly (so that hand jitter doesn’t affect careful driving). Then when the bridge starts tipping, drivers could release this button and the robot would stop driving. The whole task might be simple enough for the drivers to control.
However, the brake function could be automated. I can see where the robot would need to be held in place. It might coast and roll if you just didn’t drive the motors.
So, maybe a button as described immediately above, then another button enables a brake mode. This would likely need to be done with PID (and don’t forget encoders). It would have to be very quick, responsive, and effective (read: not spike and move the robot too much as it tries to keep it still ) Could some effective code be done without PID? Maybe an extremely simple P function related to encoder displacement (still kind of PID related)? Maybe a relay-style go forward/backward at a very low constant speed based on slight encoder offset, just to hold the robot in place (like while the bridge is tipping but still angled). This could be an electrical issue by stalling the motors, if you know that driving the motors at 0.01 speed will hold, but not move the robot.
The button for brake could be pressed independently of the first, that is, it overwrites whatever the first button is doing. This way the drivers don’t need to think about letting go of the first button during that critical moment when the bridge starts tipping. They just need to focus on mashing the brake button.
Oh, and a slow reverse button, similar to the first, would be handy too if the robot went to far and tipped the bridge forward. Wouldn’t want to turn the robot around just to use the same “drive forward slowly” code. :eek:
Thanks everyone, this is an interesting and helpful discussion. What other ideas are there? Do people still think it’s worth using a sensor?
Found this recently, might be helpful. Very interesting.
A Google talk on sensor fusion, namely, using multiple sensors to get the data that you want, like how someone was mentioning before about using both the gyro and accelerometer. He even talks about that exact thing early on.
Yes, that’s what we’ve been talking about. Simply said, the robot would sense if it is horizontal with a gyro or accelerometer (or both) and then stop moving.
I was giving an alternative to that in case the sensor implementation was too complicated, or as a backup if it never worked out, or if balancing was easy enough for the drivers to do it semi-manually.
) Could some effective code be done without PID? Maybe an extremely simple P function related to encoder displacement (still kind of PID related)? Maybe a relay-style go forward/backward at a very low constant speed based on slight encoder offset, just to hold the robot in place (like while the bridge is tipping but still angled). This could be an electrical issue by stalling the motors, if you know that driving the motors at 0.01 speed will hold, but not move the robot.