Dave - I have drift compensation in the IMU code, but the terms aren't properly set for this board. I have a mode in my Groundstation-X code that will read the gyro and temp values and compute the necessary drift compensation factors to plug back into the code. You'll still get integration error, but that's very low in my experience.
By making the bot taller, I want to achieve two things : a slower fall and a higher center of mass. I actually want to mount the battery at the top, because this will help dampen vibration, and it'll make the amount of mass driven by the motors lower, which should let them be more responsive. Also, having the battery up top will mean that, discounting the weight of the motors, the center of rotation should be basically at the battery, which will be very close to the board / sensors.
The rounding term you suggest in the code could work, but that's assuming the numbers will always be positive, which they won't. The approach used by the original DCM implementation was to use another PID (just a PI, actually) to handle the error correction term. With the integral term set properly, it would handle that last little bit of offset required to get a nice vertical, but I don't think that's my problem here.
The 'bot does actually "know" that it's falling, it's just not responding fast enough. I need more data logging on the PC to see what the internals are doing. Steppers are also not a great choice for this because they lose torque as they go faster, and they're always holding at full power. This bot, when perfectly balanced, would need no power applied at all if using regular motors with PWM. On the other hand, I wanted to use the Hoverfly Gimbal board to drive this, and it doesn't have NEARLY enough I/O to work with if you need to talk to motor drivers, encoders, and a remote. It was good of them to sell them to us so cheap, and beggars can't be choosers, but I sure wish the rest of the pins were available.
Mostly I just need to spend more time on it, log some outputs, and play with my implementation. I have it very close to stable, but I'm missing something - I just haven't figured out what yet.
The rounding term you suggest in the code could work, but that's assuming the numbers will always be positive, which they won't
The rounding works if you do a signed right-shift by 8 instead of dividing by 256. If you use a divide you have to subtract the rounding offset for negative numbers, and add it for positive numbers.
Doing a signed shift of a negative number cannot produce a zero if the source is non zero. A divide will.
You will get a zero value when you're supposed to. (-127 + 128) ~> 8 will give you zero. Rounding with a shift is almost the same as rounding with a divide. The shift will always give you equal size steps, such as one step for every 256 values when shifting by 8. Rounding with a divide will also give you one step for every 256 values, except around zero, where zero is obtained from 257 different values. A divide is symmetric around zero, and a shift is not. However, for divisors of 256 or 128 it's close enough. I've always used shifts in everything from digital filters to FFTs. In digital circuits it's just too expensive to do a divide.
EDIT: Note that in Spin you must use ~> instead of >> to handle negative numbers correctly.
I haven't tested this on the Prop, but I suspect it's the same, and it's not quite what I expected. I knew that negative numbers, when shifted, would produce a negative result. Adding a positive rounding offset fixes that, so it only differs by one number on the rounding when compared to the divide. I'm going to have to use this - The proper signed offset divide is the only one that's *perfectly* symmetric around zero, but the positive offset case is only off by a single entry, which is good enough for most things, and likely faster even in Spin.
I little more progress. I made it taller and added remote control. It's still having a hard time catching itself if it starts to fall, but hopefully I'll get enough time on it this weekend to solve that.
@Jason
Seems stable. I suspect there is always a point of no return that will cause a flop. The bot should have a couple of pads to absorb 'flop shock', maybe a couple of kitchen sponges -- one on each face.
I finally got some time to review everything in the 7 pages of the thread. Watching the YouTube presentations is slow going, but I am going back and forth between reading and watching.
I got 2 of them after long mail travel of 2 weeks.
I run the demo hoverfly10, and notice the x-axis spindle slowly.
I put the hoverfly board on the desk and after 10 minutes it is shifted +/-45° on the monitor, not at the desk.
So it drift CCW.
Ltech, that is similar to what I have seen also. The rotation around the Z axis will drift over time. The drift rate starts out very slow at first and increases over time. The PASM code does some thermal compensation, but I think it needs to be tuned for each gyro chip. The drift in the X and Y axes is corrected by the accelerometer, so they should not change over time.
With the temperature compensation calibrated properly, measured the drift *much* lower than that. If you want to do it, you'll need to get the GroundStation program from the Quad-X (Open) post. It's not difficult to do, but there are a couple hoops to jump through at the moment. I'll try to get some time in this week and update the DCM viewer app to include it, or just make a special version of the GroundStation app for this board. The SensorDriver code at the top of this thread has an old version of the drift code, and it's commented out, so it's currently unused. I have an updated version that's more generalized, and handles drift on all three axis.
The temp drift compensation involves taking a sample of the gyro readings and temperature when the board temp is low, and again after the board has warmed up. You do this by leaving the board stationary and heating it with a hair dryer for 20 seconds or so. The GroundStation software plots the graph for you so you can see how the gyro readings change as the board warms up, and it computes the scale factors that you plug in to the PASM code to compensate for the shift.
Comments
By making the bot taller, I want to achieve two things : a slower fall and a higher center of mass. I actually want to mount the battery at the top, because this will help dampen vibration, and it'll make the amount of mass driven by the motors lower, which should let them be more responsive. Also, having the battery up top will mean that, discounting the weight of the motors, the center of rotation should be basically at the battery, which will be very close to the board / sensors.
The rounding term you suggest in the code could work, but that's assuming the numbers will always be positive, which they won't. The approach used by the original DCM implementation was to use another PID (just a PI, actually) to handle the error correction term. With the integral term set properly, it would handle that last little bit of offset required to get a nice vertical, but I don't think that's my problem here.
The 'bot does actually "know" that it's falling, it's just not responding fast enough. I need more data logging on the PC to see what the internals are doing. Steppers are also not a great choice for this because they lose torque as they go faster, and they're always holding at full power. This bot, when perfectly balanced, would need no power applied at all if using regular motors with PWM. On the other hand, I wanted to use the Hoverfly Gimbal board to drive this, and it doesn't have NEARLY enough I/O to work with if you need to talk to motor drivers, encoders, and a remote. It was good of them to sell them to us so cheap, and beggars can't be choosers, but I sure wish the rest of the pins were available.
Mostly I just need to spend more time on it, log some outputs, and play with my implementation. I have it very close to stable, but I'm missing something - I just haven't figured out what yet.
(1024 + 128) >> 8
Is the same as
(-1024 + 128) >> 8
but
(1024 + 128) / 256
is different than
(-1024 + 128) / 256
?
I've generally taken the sign of the source value, applied an offset of the same sign, and done the divide, like this:
Val := -1024
Round := Sign(Val) * 128
Result := (Val + Round) / 256
Doing a signed shift of a negative number cannot produce a zero if the source is non zero. A divide will.
One of us is wrong, but I'm not sure who. :-) I'm going to have to go verify my assumptions.
EDIT: Note that in Spin you must use ~> instead of >> to handle negative numbers correctly.
I haven't tested this on the Prop, but I suspect it's the same, and it's not quite what I expected. I knew that negative numbers, when shifted, would produce a negative result. Adding a positive rounding offset fixes that, so it only differs by one number on the rounding when compared to the divide. I'm going to have to use this - The proper signed offset divide is the only one that's *perfectly* symmetric around zero, but the positive offset case is only off by a single entry, which is good enough for most things, and likely faster even in Spin.
I learned something today!
Seems stable. I suspect there is always a point of no return that will cause a flop. The bot should have a couple of pads to absorb 'flop shock', maybe a couple of kitchen sponges -- one on each face.
I finally got some time to review everything in the 7 pages of the thread. Watching the YouTube presentations is slow going, but I am going back and forth between reading and watching.
I run the demo hoverfly10, and notice the x-axis spindle slowly.
I put the hoverfly board on the desk and after 10 minutes it is shifted +/-45° on the monitor, not at the desk.
So it drift CCW.
Nice vga monitoring
The temp drift compensation involves taking a sample of the gyro readings and temperature when the board temp is low, and again after the board has warmed up. You do this by leaving the board stationary and heating it with a hair dryer for 20 seconds or so. The GroundStation software plots the graph for you so you can see how the gyro readings change as the board warms up, and it computes the scale factors that you plug in to the PASM code to compensate for the shift.