- Am afraid to get it too far off the ground, so it's kinda like a hovercraft right now, scooting around on the ping-pong ball landing gear. Am trying to get a hang for the cyclic controls, but I my response is phase-lagged.
- It does seem to be a bit easier to control when it gets off the ground more. Maybe then the attitude change would be more pronounced (right now the landing gear constrains it), and then it'd be more responsive.
- I think I've got a better feel for the transfer function.
- In theory (i.e. according to my book), cyclic input tilts the rotor disk, generating a pitch/roll moment, which is 1/s2 to pitch/roll angle. The combination of disk angle and body angle vectors the rotor thrust, producing a lateral component to the downdraft, which is 1/(s+a) to velocity, which is in turn 1/s to position.
- In practice, the extended landing gear is tripping me up: I'm not getting any pitch/roll, so I have 1/s2 from control (disk angle) to position, but the gain is really low. And then when I get slightly off the ground, the pitch/roll dynamics come back into play, which makes it 1/s4 from control to position, and my heavy-handed control turns into an obscene body angle.
- So maybe an SAS (Stability Augmentation System) that turns the cyclic command input into a desired body angle would be useful. Then letting go of the stick would return the helicopter to level.
- The heading-hold gyro works really well.
- I may want to retain direct control of the throttle (i.e. not give it to the SAS). Due to the CCPM, though, a cyclic-control SAS will also have to control the collective, but that should just be a kinematic thing.
As for the ARHS, have had some issues.
- Gyro integration wasn't working so great with combined motions, so I looked into the calibration and have some minor adjustments there.
- Was displeased with the quantization error on the accelerometer, so I decided to sample at a higher rate with a digital lowpass.
- Can't do it with their I2C library because the send/receive code is all blocking, and getting the acc data requires 0.81 ms (9 bytes at 9 bits/byte at 100kHz SCL). So if we sample the acc at 200 Hz and the magnetometer at 50 Hz, that's 4 ms out of the 20ms we have per cycle.
- Wrote a non-blocking I2C library (with a pretty clever instruction queueing system). Took 5 hours, then accidentally deleted it. Completely gone. That sucked. Don't do that.
- Read about quaternions. They're pretty elegant, so I'm thinking I will switch the AHRS from being DCM-based to quaternion-based. Have started deriving the matrices/functions that I need for an EKF.
- Does my 8-bit AVR at 8 MHz system clock have the computing power to run an EKF?
- Will I need to write optimized matrix multiplication code?
- Will I need to convert all the math to fixed-point?
No comments:
Post a Comment