Friday, April 9, 2010

Helicopter update

Looked around some more; I think the E-flite Blade CP Pro 2 is the one I want. I saw an older model (CP+) at D&J Hobby, and it looks pretty good. I'd originally thought a fixed-pitch heli would be better, but it looks like there aren't any good ones on the market.
It's got a 6-channel receiver that feeds into a motor speed controller (for the main motor and the tail motor), which has an integrated gyro (which might be okay; I'll just account for it when closing the control loops). But it's not one of those integrated receiver/motor controllers, so that's good. Brushed motor, so no tach signal, but that shouldn't be too hard to add. It's got electronically mixed CCPM, which is good, and better yet, the transmitter can be switched out of that mode (into unmixed elevator/aileron/collective signals).
I'll have to decide, though, whether to go for the one at the hobby shop or to try to get a CP Pro 2. Will have to call around to see who has that in stock. I hope it'll be okay with the weight I plan to add. I guess one advantage to a modular gyro is that I can remove it to save weight.

Talked to Prof. Rock about the project. He thinks the helicopter dynamics won't be too bad, but sensing will be difficult. First, there is the issue with accelerometer drift when trying to get a good attitude reading. We'll see how that goes. I'm curious, too, about how the magnemometer pans out.
Next there is the issue of velocity sensing. Ideally, the user is dealing with a velocity command. He thinks it'd be pretty interesting to run optical flow on a simple webcam. Checked Sparkfun, and it looks like it'd be doable in terms of price and size. Will need good attitude and altitude information to decouple pitch/roll from x/y translation, though. Hey, maybe with good attitude and perceived x/y translation, I can get altitude... And as an added bonus, it becomes an aerial photography platform.
Finally is the issue of the ideal user interface. Can we get by without velocity sensing? My argument is that humans have trouble dealing with 1/s2 plants (i.e., issuing a force command) because the system is underdamped, so we just need damping. Or, recasting the human interface question in a different light, what if we take the human to be a simple proportional controller? The user has a desired position, and he issues a command based on the error he sees. If it's a velocity command, that's great, because it's a first order system. If it's an acceleration command, then with insufficient damping and human time delay, it'll be unstable. But we should be able to deal with that, right? What I like about this approach is that it takes advantage of the human's sensors and puts that into the loop.
Oh, one final thing that I thought would be cool: if the magnemometer works well for heading, then we could interpret all cyclic commands in a fixed (w.r.t. yaw) reference frame, thereby freeing the user from orientation considerations...

No comments:

Post a Comment