Bluabot has a suspension system and a 50lb drive train that’s meant to conquer the bumps like they’re a Mars rover with 120 amps to spare while always staying upright. Yet on a cross-field escape from Redabot’s defensive moves, Bluabot doesn’t turn enough before trying to climb the bump, thus in the ascent Bluabot flips over without even climbing… How could the team have easily prevented this?
They could have programmed in a Gryo and PID control. Bluabot’s drivers could have pushed a button that quickly re-centered the robot’s true heading to a vector orthogonal to the climb. In plain English terms, with most robots this would be the same heading as the robot’s starting orientation, or 90 degrees from it, so long as that heading points parallel to the sides of the field (aka straight down the field).
Sure, it’s not a perfect protection since the driver could still try to climb before the bot is done turning; yet if it prevents your team’s robot from tipping over just once this season I believe it’s an idea worth evaluating. More probable is that drivers will constantly use it to save time by auto-aligning to the bumps and then gunning it up/over. Tunnel-goers may see benefits too, but it might not be as useful as those who want to do both.
All it takes is a couple of ounces and a couple of hours!
FWIW - you can also solve this problem by using the (linear) accelerometer in the kit. When your robot is stationary, you know the total acceleration sqrt(aX^2+aY^2+aZ^2) should be 1g. When your robot is on flat ground, aZ (vertical axis) should equal 1g and the other two axes should each be 0g. When your robot is pitched up the ramp (driving perfectly perpendicular to the ramp), aX (your “roll”) should be 0g, and aY and aZ will have the square root of their squares add to 1g (depending on the degree of pitch). You can monitor aX to ensure there is no “roll”.
Granted, this would require that you stop the robot momentarily, but it would have a significant advantage over the gyro - it’s measurement doesn’t drift over time (since you are reading the raw accelerations and not integrating them).
By the time aX is showing roll that stands out above the noise floor, isn’t your robot in a pretty precarious situation already? I mean, that means that you’ve both already started to list, and you’re not in a position where it can be quickly corrected(the robot has to turn first).
I’m thinking about maybe a hybrid strategy–if the 1g from earth’s gravity drops, the robot automatically checks its heading and corrects using a gyro. Of course, this has the same issue with having to integrate the gyro value over the course of a match. Maybe a digital compass?
I spent about a week of December doing a tolerance analysis of using an accelerometer as an inclinometer. For the specific part I used, my conclusion was that determining pitch and roll using the X and Y axes was more accurate than using the Z axis. This was assuming a single point calibration at start up.
Hmm. Is there a way to experimentally determine the gyro drift as a function of time (or amount of degrees already turned…) and use that as an error adjustment during a match? Or is the drift non-constant?
Take a look at the documentation for our kit accelerometer.
If set to +/- 2g operation, we’re talking a resolution of 4mg (that’s milli-g’s) per LSB. The noise ceiling is spec’d at worst case +/- <1.5 LSB for the Z axis, <1 LSB for X and Y (at 100Hz data rate = 50Hz bandwidth).
In other words, at a 100Hz data rate, at roll of 5 degrees (0 degrees pitch), we would expect aX to read sin(5 degrees)*1g = 0.0872 g (or 87.2 mg). That’s >20 LSBs - significantly above the expected noise margin.
In other words, I think you will find the accelerometer responds EXTREMELY quickly to angular changes. There’s a reason they use accelerometers like ours on SUVs to detect roll conditions to deploy airbags.
AFAIK, you need to use the Z-axis to prevent contamination of your tilt sensing with actual XY acceleration of the robot. You would have to use the X axis if you wanted to do roll sensing, but for a system where you’re using a gyro to align yourself, you should only need the z axis.
Integration drift arises because we are integrating a noisy signal. In other words, every time we read signal X, we are actually reading a random variable which consists of the true X, plus or minus a noise term with a given mean and variance.
If Xobserved is what we see, the effect is:
Xobserved = Xactual + Noise with mean and variance (usually modeled as a Gaussian distribution)
Over time, all these small variances result in a “random walk” in position - you can’t recover exactly what the variances were, but you can estimate the uncertainty of your current position estimate.
In other words, you can estimate (with reasonably high confidence), the variance of your current position reading, but you won’t know where inside of this error bound you actually are.
In industry, we often try to augment fast measurement sources that drift (like gyros and accelerometers that get integrated) with slower, but stable, measurement sources (like compasses and GPS). Then, you get the best of both worlds.
(Though getting a compass to work on a metal FIRST robot is a challenge in itself).
That is correct - you either need to look at all three axes to isolate the robot’s accelerations from gravity, or you need to stop the robot (thus ensuring that the only acceleration is gravity).
