Last weekend, on Sunday night after BANG 21 wrapped up, I pulled everything together and ported the simple pitch/roll tilt sensor Kalman filter code to the onboard Propeller CPU, hooked it up to a simple PID controller (actually a P controller for now), set the collective to a low value (so it wouldn't actually fly), and... it went crazy. When the motors were running, the orientation reading would vary by as much as 50 degrees, even though the device was sitting on a desk. It would try to compensate for the huge perceived tilt, and the motors would start and stop spastically. Fortunately I had ramped down the power so nothing actually happened, but...
I theorized that the vibration caused by the motors was throwing the IMU out of whack. Today I finally got around to looking into it, and indeed, if you watch my host-based IMU sensor readout graphs when the motor turns on, you can see quite a bit of noise in the accelerometer data:
The motors were off at first, and then turned on; you can see the transition about 40% of the way across the line charts (especially visible on the X axis accelerometer). I did several things to try to make this better. First, I mounted both the IMU and the motors on rubber washers to isolate them somewhat from the frame:
The neoprene washers were from Home Depot, which had a limited selection of sizes, but anyway I got them to fit. Running a similar test, you can see that the vibration is improved somewhat, but by no means gone. Maybe I reduced it by half:
Now, the real question is why this is a problem. The whole design of the Kalman filter is to ignore high frequency transients in the accelerometer data, using it only as a low frequency drift correction for the gyro data. (As you can see, the gyro data is basically unaffected by the vibration.) And in fact, in my host based computations the filtered readout is basically fine. Near the lower right of the test displays, you'll see pitch and roll indicators; the yellow triangle is unfiltered accelerometer orientation, the yellow line is unzeroed gyro orientation, and the white indicator is the filtered result. You can see they both indicate (correctly) zero, even though the accelerometer is reading a significantly nonzero value for roll at that moment.
Anyway, after some debugging, I found a bug in the onboard code. (I was adding two floating point numbers with integer addition.) After fixing that, I got much more sensible results -- still varying a bit, but only by a degree or two (which is about the same as the host-based filter).
I'm not yet brave enough to actually ramp up the power to takeoff, but I powered it up to 30% or so (it takes 50% power to take off) and held it in my hand and moved it around. Lo and behold, I could feel the motors counteracting my motion. There's quite a lag -- I tip it to the side, and maybe a half second later it pushes back against me -- which seems like it would be a real problem for flight stability. Not sure if that's sensor reading or the time to spin up the motors or what. Maybe (hopefully?) the lag will be a lot less for small corrections. In any case I look forward to a long process of tuning the flight controller's feedback loops. (How to do that without crashing a zillion times? Even with my foam pads, I'm sure it's quite capable of inflicting serious damage on itself, not to mention me and my apartment.) Maybe some sort of strapdown test harness?
Anyway, that's good progress for one day I think.
The tomato plants are growing madly, they're like two feet tall now:
Anyway, after some debugging, I found a bug in the onboard code. (I was adding two floating point numbers with integer addition.) After fixing that, I got much more sensible results -- still varying a bit, but only by a degree or two (which is about the same as the host-based filter).
I'm not yet brave enough to actually ramp up the power to takeoff, but I powered it up to 30% or so (it takes 50% power to take off) and held it in my hand and moved it around. Lo and behold, I could feel the motors counteracting my motion. There's quite a lag -- I tip it to the side, and maybe a half second later it pushes back against me -- which seems like it would be a real problem for flight stability. Not sure if that's sensor reading or the time to spin up the motors or what. Maybe (hopefully?) the lag will be a lot less for small corrections. In any case I look forward to a long process of tuning the flight controller's feedback loops. (How to do that without crashing a zillion times? Even with my foam pads, I'm sure it's quite capable of inflicting serious damage on itself, not to mention me and my apartment.) Maybe some sort of strapdown test harness?
Anyway, that's good progress for one day I think.
The tomato plants are growing madly, they're like two feet tall now:
Yay for the motors counteracting your motion!
ReplyDeleteWow leaves growing into the light and burning.
Several inches overnight? Wow. My tomatoes are outside, and they don't grow that fast. For pruning, you're supposed to "nip all the suckers", which means removing the all the branches and leave only the main stem. Last year was my first year gardening, and I did not have the heart to prune anything. End result? Hugh tomato sprawl, some fruits touching the ground and rotting. This year I know better :)
ReplyDeleteFor testing, is there a good way to detect when the thing has crashed and shut off the motors? Since you presumably don't have motor speed readings, you'd probably have to do it when IMU data goes haywire in the wrong way. I bet you could avoid major data that way, although the spinning props will still have enough inertia to do some damage.
ReplyDeleteChiu-Ki: Well, these are hydroponic tomatoes under grow lights, so you're supposed to prune them in certain special ways...
ReplyDeleteSeth: I'll be watching it, and I can kill the motors with a single keypress before it hits the ground in most cases. But the crash itself will create a bunch of damage.