From the Mavic:
From my iPhone:
The only mysterious behaviour was the unexpected drift after the end of deliberate yaw; it’s not the RC nor me; best guess, the sensors are seeing the yaw as lateral drift somehow.
P.S Zoe is now retired as she’s done all she can within the constraint of her CPU speed. She’ll be back if and when a faster Pi0W is announced.
P.P.S. Penelope is boxed up also, partly because there’s nothing she can do that Hermione hasn’t done already, and partly because Garmin are still faffing around launching their new LiDAR. If that appears, there is some value in bringing her back to life, both because she’s a (faster) B3+ and she’s running Stretch – up to now, everyone is stuck on Jessie from February 2017 – the last point I2C worked with the Garmin.
P.P.P.S. The title is from the film “Arrival” which is very good if that’s the sort of film you like!
This isn’t as bad as it looks! The take-off is automatic to a safe altitude which unfortunately took Zoe out of frame; once the auto takeoff completed, I rc’d her back into frame, and then did what I described in the video.
Causes of the problems?
- primarily, the nut-behind-the-wheel – I need a lot more person-practise!
- secondly, Zoe is at her performance limit hence her instability.
- third and finally, once she left the high-colour-contrast mat, she didn’t stand a chance!
What this does show is the code is good, and I next plan to do the same outdoors with Hermione once the wind drops and the temperature rises.
Neither Zoe nor furniture were damage in this video!
Here’s what’s shown here:
- Until the RC and piDrone connect, the piDrone does nothing; this is not on the graph.
- When the piDrone sends a message to RC saying it’s ready, the flight control starts
- Initially, it does nothing until the RC messages the piDrone a special command to take-off; the take off is automatic, the joysticks has not control this once striggered.
- Once the 3s automated takeoff completes (about 16 – 19 seconds in the graph), the RC has full control again, and you can see me tweaking the real joystick actions up to the 46 second point.
- At that point, another special message from the RC to piDrone sets it to descend; again once descending, the joysticks has no influence until landed.
- In this case, I didn’t use the RC to trigger the take-off again; instead I then got the RC to trigger a stop to the flight at about 60s.
Next is to try it live, ideally on Zoe as the smallest, lighted, and strongest…
Realized overnight that the code changes I made yesterday won’t help wind-drift, but they are exactly what’s needed for horizontal speed control.
Lets look at two models
- The horizontal speed control moves Phoebe forward because she’s been told to by a user input (autonomous or RC). The force generating the earth horizontal movement comes about because Phoebe tilts, thus redirecting some of the vertical force from the propellers to the earth horizontal plane: faz * sin(θ) and vertically: faz * cos(θ). Feed these values into the horizontal and vertical speed PIDs as the feedback input results in a target value for θ fed into the absolute angles PID, which reduces as Phoebe accelerates up to the desired speed.
- The model for wind is more complex; first we need to measure the acceleration applied by the wind; at a tilt, the measure of the wind force comes from both the X and Z accelerometers (assuming for the moment only a head or tail wind). The feedback input to the horizontal acceleration PID is √(fax2 + (faz * cos(θ))2) (with some allowance for head or tail wind from somewhere). The output then feeds the absolute angle PID to counteract this wind drift acceleration. This angle will be constant as it is redirecting propeller force to counteract the wind acceleration force.
And here lies my problem:
- The user controlled horizontal speed PID output supplies the absolute angle PID target with an ever changing value as the desired speed is obtained.
- The anti-drift force PID output supplies a fixed absolute angle PID target to counteract the wind acceleration force
Leading to the question of how to merge these 2 PID outputs into a single target for the absolute angle PID, and do I really have to add a new wind-drift acceleration PID, or can I just take the measured wind force and convert the value into a desired angle, much like what happens with the output from the horizontal speed PID?
And that’s enough design thought to spoil my testing for today.
is, as always, on hold pending reasonable weather: dry with a light breeze. If I’ve got things right in this set of articles , then many things become possible:
Phoebe will be able to takeoff from a non-horizontal surface – the X & Y axis speed PIDs will stop her from drifting due to the slope she took off from – this turns out to be a bit of an oversimplification – the flights MUST still start on horizontal ground to ensure the angles used from the integrated gyro’s are accurate when translating accelerometer sensor outputs for Phoebe’s dimension to the earth’s. I think I’m going to need a 3D compass to sort this out. Luckily the rest below remains valid…
- She won’t drift in a hover – she’ll stay vertically above her take-off ponit
- That means winter testing can move to the garage knowing Phoebe won’t smash herself into a brick wall at high speed
- That’ll let me continue to improve the take-off and landing code to be more sensor driven and less hardcoded
- Last, but definitely not least, I’ll be able to add a remote control; the addition of the horizontal speed PIDs means commands from the RC such as move forward at 1 meter per second can be used directly as a horizontal speed PID “target” – most of the code for the RC is already in place in my development code, but is commented out.
It also means I can start considering things like adding GPS, both for mapping where she’s been, and also retracing her steps if the RC connection gets lost or battery level gets low.