Correct, This one uses O rings. The wheel is printed with a cupped center so that the O ring fits around it and stays on.
By the way this robot of this size does exists and does balance very nicely using NEMA17 motors. The new version uses an inverted drive belt of about 280mm and is mounted on a flat wheel with a radius of about 44mm.
Making it taller reduces the rotation rate dramatically. (I think the relationship of angular velocity to length is N^4 - that's why small quad-rotors are freakishly nimble). Putting the weight higher up also makes the motors have to work less, and helps stabilize the top.
My first iteration:
My second:
The first was too short, and hard to keep stable. For the second, I made it about 6 inches taller, and moved the battery up more. That was significantly easier to control.
Oh yea, so I mentioned before, I'll be using rubber bands for tread this weekend. But long term... I have no idea. I'd love to hear some ideas for what you might use in this scenario.
I suspect the Parallax Bands are a bit too small for these wheels. Considering that where the bands will go is smooth and has no groove for the bands to sit in, you might want to go with an over sized rubber band that is wider than the width of the wheels otherwise it might just slip off.
We use the Asparagus rubber bands for a lot of different things here.
Good idea. Perhaps we'll have asparagus for dinner tonight!
So the chassis is built and electronics are mounted! Exciting!
Unfortunately... one of the motors has way more resistance than the other (I can feel it when I spin the motor by hand, and the motor doesn't start spinning until after the other one). Not sure what to do about that. I can certainly try and come up with some software that compensates, but that seems like a very non-ideal solution.
Other than that, I just have to tune the PID constants now.
Well.... this has been a disappointing afternoon. The robot is built and the software doesn't seem to have any bugs... but it doesn't run for Smile. I just tested the center of mass and it's only about 1/4 the way up the chassis... that probably isn't helping. These motors are way too big
We have some lead weights and various steel beams, angle brackets, rods, etc that we might try adding tomorrow to get the center of mass higher up. The chassis that you see above is entirely aluminum, and the battery pack is just 8 AAs, so as you can imagine, there isn't much mass anywhere except in the motors.
On top of that, I seem to have about 1 degree of slack in each of the motor shafts. I imagine that's not helping either
Tomorrow morning I'll see about making this taller and moving the sensors higher. With added weight and height, we might be adding some braces to combat twist.
I'm really glad I drove down to my dad's place, where he has all the tools and scrap to make this happen. So far we've only made two trips to the hardware store, and that was just for bolts & nuts to mount the motors and brace.
No calculations are done in the first two lines, other than to convert the accelerometer to units of gravity and gyro to degrees per second.
The to_degrees function simply evaluates to "atan2f(par1, par2) * 180 / M_PI".
ACCELEROMETER_WEIGHT is hardcoded and GYRO_WEIGHT = 1 - ACCELEROMETER_WEIGHT. I've 10% seems to be the most stable value for the accelerometer right now, which is quite a bit higher than the 2% Jason was recommending.
I do have independent offsets for both the gyro and accelerometer. I'm using the gyro offset to counteract the constant motion that i'm getting when the system is stationary, and the accelerometer offset as a trim.
I then run the PID loop in a separate cog (based on the runtime and desired frequency of 250 Hz, it could be the same cog... i just haven't merged them yet). Its code isn't too complex either:
If you need more context for any of that, see SensorReader.h, PIDController.h, and PWMDriver.h for the core functionality: https://github.com/DavidZemon/MiniSegway
Oh, and I brought special attention to the 10% accelerometer weight being different than Jason's recommendation not because I think Jason was wrong, but because I'm hoping that helps anyone reading this have some idea of what might be going wrong.
First thing I'd want to check is what is the current_angle being fed to the PID? Is it correct?
Does that current_angle read correctly as the stationary bot is tilted forwards and back?
Does the current_angle read correctly when the bot is tilted at some constant angle and being accelerated horizontally forward and back?
I would suspect the latter goes a bit screwy under horizontal acceleration.
I have a UART logger that prints a line every 30ms. At slow tilt speeds (moving by hand), it is pretty accurate. I have definitely noticed that angle is drastically affected by lateral acceleration.
I just found out that we have a Microcenter here in St. Louis, so I'm off to go buy a BNO055 and use its algorithm for angle. If I can get that working I can tune the PID algorithm. Then I might go back and try to figure out my own angle algorithm for the fun of it... but the BNO055 should get me started hopefully.
Not sure if anyone has drivers for it yet that will work with the Prop. But we bought a couple anyway about a year ago in anticipation of our balancing bot.
The accelerometer gives a great indication of orientation when stationary, thanks to gravity, but is messed up when things are accelerating.
The gyro gives a great indication of rate if change of orientation no matter what. But drifts.
Somehow these two sensor inputs can be fused to arrive at a more stable orientation. I have never really got my head around this but I did get this sensor fusion code working very well as while back: http://x-io.co.uk/open-source-imu-and-ahrs-algorithms/
There is a C version of the imu algorithm. Not sure if it will fit in a Prop though.
I'd be very interested in how you get on with the BN055. I have been meaning to get hold of one to play with for ages. Basically it does all that IMU fusion for you. Sounds great.
My crazy Javascript version of Sebastion Magwick's IMU sensor fusion is here (Including original C source): https://github.com/ZiCog/madgwick.js
The one I showed above was using the full IMU I developed for my quads (which is what the Elev8-FC's IMU is derived from), but that's complete overkill for something like this. A simple complimentary filter should be plenty.
Your complimentary filter pseudo code is simple enough that even I can understand it.
It looks like some parts of a 1D Kalman filter, where inputs from different sensors are mixed in various proportions to get a more accurate estimate. Except in the Kalman the proportions are changed dynamically depending on how much you trust them at the time.
Not that I have looked into or understood Kalman very much.
It's all moot now. All of this is built into the BNO055.
Jason, the algorithm you posted is exactly what I'm already doing. Seems like it should work, which is part of why I got pretty disappointed yesterday when it refused to balance. Putting a bit of lead at the top seemed to help a little, but I still couldn't get it right. Anyway, I'm just dead tonight. I was only able to give the robot a couple hours of attention all day. Tomorrow I drive back to Omaha first thing in the morning, so I sure hope my chassis doesn't need any more significant work.... It will be a lot harder from here on out. When I get back, I'll replace my sensors with the bno and try tuning the PID constants again. Only once I get *that* working will i go back to the original sensors to see if I can make it work. I still fear the slack in the motors is hurting me, and I don't know if the center of mass is high enough yet (though I think it is)
Comments
Sounds cool! Do you have a picture of that one?
My first iteration:
My second:
The first was too short, and hard to keep stable. For the second, I made it about 6 inches taller, and moved the battery up more. That was significantly easier to control.
Mike
Good idea. Perhaps we'll have asparagus for dinner tonight!
So the chassis is built and electronics are mounted! Exciting!
Unfortunately... one of the motors has way more resistance than the other (I can feel it when I spin the motor by hand, and the motor doesn't start spinning until after the other one). Not sure what to do about that. I can certainly try and come up with some software that compensates, but that seems like a very non-ideal solution.
Other than that, I just have to tune the PID constants now.
We have some lead weights and various steel beams, angle brackets, rods, etc that we might try adding tomorrow to get the center of mass higher up. The chassis that you see above is entirely aluminum, and the battery pack is just 8 AAs, so as you can imagine, there isn't much mass anywhere except in the motors.
On top of that, I seem to have about 1 degree of slack in each of the motor shafts. I imagine that's not helping either
Tomorrow morning I'll see about making this taller and moving the sensors higher. With added weight and height, we might be adding some braces to combat twist.
I'm really glad I drove down to my dad's place, where he has all the tools and scrap to make this happen. So far we've only made two trips to the hardware store, and that was just for bolts & nuts to mount the motors and brace.
How are you measuring the tilt angle from vertical?
What actually is your control algorithm?
No calculations are done in the first two lines, other than to convert the accelerometer to units of gravity and gyro to degrees per second.
The to_degrees function simply evaluates to "atan2f(par1, par2) * 180 / M_PI".
ACCELEROMETER_WEIGHT is hardcoded and GYRO_WEIGHT = 1 - ACCELEROMETER_WEIGHT. I've 10% seems to be the most stable value for the accelerometer right now, which is quite a bit higher than the 2% Jason was recommending.
I do have independent offsets for both the gyro and accelerometer. I'm using the gyro offset to counteract the constant motion that i'm getting when the system is stationary, and the accelerometer offset as a trim.
I then run the PID loop in a separate cog (based on the runtime and desired frequency of 250 Hz, it could be the same cog... i just haven't merged them yet). Its code isn't too complex either:
auto pidResult = this->pid(g_angle - g_trim); if (pidResult > 0) { leftMotor.clear(); rightMotor.clear(); pidResult += MOTOR_DEAD_ZONE; } else { leftMotor.set(); rightMotor.set(); pidResult -= MOTOR_DEAD_ZONE; pidResult += DualPWM::MAX_DUTY; } g_leftDuty = g_rightDuty = static_cast<unsigned int>(pidResult);And the pid() method:
int32_t pid(const double currentAngle) { static double previousAngle = 0; static double integral = 0; // Proportional const auto error = currentAngle - g_idealAngle; // Integral integral += error; // Derivative const auto derivative = currentAngle - previousAngle; previousAngle = currentAngle; const int32_t output = static_cast<int32_t>(KP * error + KI * integral + KD * derivative); g_pidError = error; g_pidIntegral = integral; g_pidDerivative = derivative; g_pidOutput = output; return output; }If you need more context for any of that, see SensorReader.h, PIDController.h, and PWMDriver.h for the core functionality: https://github.com/DavidZemon/MiniSegway
Does that current_angle read correctly as the stationary bot is tilted forwards and back?
Does the current_angle read correctly when the bot is tilted at some constant angle and being accelerated horizontally forward and back?
I would suspect the latter goes a bit screwy under horizontal acceleration.
I have a UART logger that prints a line every 30ms. At slow tilt speeds (moving by hand), it is pretty accurate. I have definitely noticed that angle is drastically affected by lateral acceleration.
I just found out that we have a Microcenter here in St. Louis, so I'm off to go buy a BNO055 and use its algorithm for angle. If I can get that working I can tune the PID algorithm. Then I might go back and try to figure out my own angle algorithm for the fun of it... but the BNO055 should get me started hopefully.
Not sure if anyone has drivers for it yet that will work with the Prop. But we bought a couple anyway about a year ago in anticipation of our balancing bot.
The accelerometer gives a great indication of orientation when stationary, thanks to gravity, but is messed up when things are accelerating.
The gyro gives a great indication of rate if change of orientation no matter what. But drifts.
Somehow these two sensor inputs can be fused to arrive at a more stable orientation. I have never really got my head around this but I did get this sensor fusion code working very well as while back:
http://x-io.co.uk/open-source-imu-and-ahrs-algorithms/
There is a C version of the imu algorithm. Not sure if it will fit in a Prop though.
I'd be very interested in how you get on with the BN055. I have been meaning to get hold of one to play with for ages. Basically it does all that IMU fusion for you. Sounds great.
My crazy Javascript version of Sebastion Magwick's IMU sensor fusion is here (Including original C source):
https://github.com/ZiCog/madgwick.js
Got the BNO055 in front of me now. Time to get to work creating a driver in PropWare.
http://forums.parallax.com/discussion/comment/1417473/#Comment_1417473
The one I showed above was using the full IMU I developed for my quads (which is what the Elev8-FC's IMU is derived from), but that's complete overkill for something like this. A simple complimentary filter should be plenty.
Your complimentary filter pseudo code is simple enough that even I can understand it.
It looks like some parts of a 1D Kalman filter, where inputs from different sensors are mixed in various proportions to get a more accurate estimate. Except in the Kalman the proportions are changed dynamically depending on how much you trust them at the time.
Not that I have looked into or understood Kalman very much.
It's all moot now. All of this is built into the BNO055.
The BNO055 module is great. I can recommend it for experimentation and development.
I was guided by rjo's excellent work - see this thread;
http://forums.parallax.com/discussion/163121/adafruit-9-dof-breakout-for-quads.