Oh well, it was worth a try…

Sensor vs Reality

Phoebe thinks she’s drifting left according to the sensor data shown in the graph, but in real life, I watched her drift right towards the house in compensation for what she perceived as leftward drift. All I can do about that is 0g offset calibration, and all previous attempts have failed. It’s not just Phoebe who can see a brick wall heading her way.

3 thoughts on “Oh well, it was worth a try…”

1. what sensor is this? gyro/accel? and how do you get reality?

this may not be directly related to your sensor vs. reality graph, but just an observation about drift. you have 3 PIDs slapped around the three body velocities and only one PID around the yaw angle. I know you’ve done some conversions to get body velocities, but wouldn’t it make more sense to slap PIDs about the pitch and roll angles too instead of the body velocities, since:

(1) pitch and roll angle are relatively easier to estimate accurately (complimentary and possibly kalman filtering with just IMU) versus body velocities (generally estimated with pitot-static probes etc. )
(2) these two angles are essentially primary effects, while velocities are secondary effects, i.e. these two angles are direct causes of your drift, so a roll and/or pitch not equal to zero cause(s) a direct increase in body velocities, but the converse may not necessarily be true (you can hold your angles and increase thrust and still increase velocities, but not angles). so if you get your angles to go to zero, the vehicle is in hover, and any drift is really just an altitude hold problem (provided you have good angle estimates).
(3) you could still have roll and pitch rates go to zero and your angles are still not zero. imagine your Chloe or Phoebe gets perturbed from hover and begins to roll (roll and roll rate non-zero, also interchangeable with pitch or both together), your rate PID drives the rate to zero, but she’s still at a slight 10 degree angle to horizontal, you could technically still hold that angle, and your rates and velocity PIDs try to drive the system to go back to hover, but you’re still not directly driving roll angle back to zero, so she crashes before she can hover back again…

• Wind is why I’m doing it my way. I’m aiming to get stable hover in a breeze which could create horizontal motion without angular tilt. The velocity PIDs spot this lateral motion, and change the rotation PID targets until the motion stops, with Phoebe at the correct angle to counteract the breeze. It might be possible (with accurate modelling) to know the desired angle to fight the breeze, but that’s much harder than using the nested PIDs to rotate Phoebe until her lateral velocity error goes to zero.

I’ve had stable angle driven PIDs working a while back with a complementary filter to merge accelerometer and gyro angles, but my aim was to get true motion processing working simply to prove it’s possible.

FYI this is with MPU9250 accelerometer + gyro.

• You might want to check out today’s post showing that motion processing can work with the nested velocity and rotation rate PIDs.

This site uses Akismet to reduce spam. Learn how your comment data is processed.