Zoe can’t be flown…
I took her out this morning, controlled by the accelerometer and gyro, but with the LiDAR and Camera running in parallel passively so I could do a comparison. But she could hardly drag herself off the ground. However, in her world, she thought she way climbing throughout:
The props span up to hover speed for the first 0.1s, then she ‘climbed’ for 3 seconds and then “hovered” after 3 seconds. By 5 seconds she was on the ground with the props spinning at the minimum setting.
Throughout (orange line) she thought she was climbing, which is why she struggled to take off.
If you look at the IMU temperature plot, as she starts to climb, it seems the propeller wind cools off the IMU, and that’s shifting the scale of the accelerometer significantly. The problem is caused because a snapshot of gravity is taken before takeoff, and then is used throughout the flight to extract net acceleration. That works fine when the temperature is in the teens, but it’s about 5°C today outdoors.
I’ve seen this in the past, and tried lots to do it either by calibrating the accelerometer against temperature – all I got from that was a beer fridge in the office – and using a butterworth low-pass filter to extract gravity dynamically during the flight – I can’t remember how well this worked but I assume “not well enough” since I dropped it from the code a while back.
What she really needs is a wind-proof jacket or scarf to shield her from the draft from the props. I might try a duct tape wrap. Alternatively, I could just bring her indoors into the temperature range where the accelerometer doesn’t drift; I’m just a little nervous as I’ve just popped into the lounge, and the scars on the ceiling are quite revealing of past exploits! Finally, I could take Hermione and her salad bowl lid to see if that helps.
…and I have a speculative cause for Chloe’s LEDDAR loss of modbus communication. Spoiler: there’s a video at the end.
It always happened after a step change in the flight plan, either to-takeoff or hover; are these causing power spike(s) which cause a LEDDAR reboot? So I looked at the stats. Acceleration was very spiky throughout, looking like the 13″ wide, 5.5 pitch (1355 or 13/5.5) props were actually over-compensating, over-and under-shooting for each motion processing – see graph, and count the peaks and troughs – about 100 per second as expected; pretty good confirmation of the speculation.
Clearly PID tuning was needed, unless…perhaps Chloe was still tuned for the expensive T-motor 12/4.0 props. A quick swap and flight later, and the noise was down in the stats, and more importantly, the LEDDAR communications wasn’t lost.
And the consistent drift to the left? I woke up wondering what the flight plan said, and sure enough, she was supposed to drift left. Oops, pilot error!
Chloe + LEDDAR from Andy Baker on Vimeo.
I’ve retired Phoebe in order to move her HoG onto Chloe, her bigger, beefier sister in preparation for the arrival of the 2D 360° Scanse KickStart LiDAR at the end of the year. I know that’s very premature but on the other hand PPPPPPP*.
There are some benefits before the end of the year: Chloe has longer, taller arms, which means I can fit the battery between her top and bottom plates, and move the HoG onto the top-plate, and eventually also the LiDAR. That keeps the topside lower profile to protect the LiDAR and the weight distribution safe. Also because Chloe uses more powerful motors and props, I expect she’ll have no problem managing her new LiDAR cargo. I’ve put together a LID (LiDAR Installation Disk) to protect Chloe’s HoG short term and (as the name suggests) support the LiDAR eventually.
As always, this transition turned out to be a right PITA: the IMU died in transit – it just was invisible to i2cdetect – a spare Zero IMU PCB worked fine though so I’ve had to replace the IMU on the HoG – a right faff of desoldering the old and resoldering the new; In addition the old ESCs weren’t behaving well either, I think due to being opto and needing 5V which my last PCB gave it but which the newer one didn’t, so new ESCs, and lots of soldering.
I took her for a flight this morning which was disappointing to say the least
- constant left drift like Phoebe, yet with different sensors.
- without LEDDAR, Chloe continues to rise during the hover phase; with LEDDAR, she climbs to the correct hover height, but shortly after the transit to hover, modbus communication fail, and Chloe drops from the sky as a protective measure.
I don’t understand any of these yet, so I have some serious sleeping to do to provide me one of my Eureka moments.
*Prior Preparation and Planning Prevents Piss Poor Performance
I flew Phoebe earlier with LEDDAR working well. She repeatedly drifted left, and self-corrected as can be seen in the graph below. You can see her repeatedly drifting and stopping. This is the expected behaviour due to the top level PID controlling velocity not distance: drift is stopped, but not reversed. On that basis, I’ve updated the code on GitHub.
To get her back to where she took off from, I need another set of ‘pseudo-PIDs’ to recognise and correct the distance drifted. I’m going to keep this as simple as possible:
- I’ll continue to use my velocity flight plan – integrating this over time will provide the ‘target’ for the distance PIDs in the earth reference frame
- I’ll integrate the velocity (rotated back to earth frame) over time to get the distance PID ‘input’ – although this is double integration of the accelerometer, it should be good enough short-term based upon the close match between the graph and the flight I watched.
- critically, I’ll be using fixed velocity output from the distance ‘pseudo PID’, rotated back to the quad-frame as the inputs to the existing velocity PIDs – the input and target of the distance ‘pseudo PID’ only provide the direction, but not speed of the correction.
This should be a relatively simple change which will have a visible effect on killing hover drift, or allowing intentional horizontal movement in the flight plan.
After that, I’ll add the compass for yaw control so Phoebe is always facing the way she’s going, but that’s for another day.
A different point of view from Andy Baker on Vimeo.
Zoe is pointing towards me. Vertical drift is good – you can tell because she’s at ground level when the flight completes. But leftwards drift (her point of view) is terrible. Why? Here’s my best guess and explanation why it’s unfixable as it stands.
It’s all to do with offset errors and integration to velocity. Imagine the perfect world with Zoe hovering above the ground; her X and Y accelerometers read zero and her Z accelerometer reads 1g.
But the world isn’t perfect and all three readings will be ever so slightly out by a fixed offset. For the Z-axis at start of data we measure gravity including the offset error; during flight takeoff acceleration, we measure the acceleration including the offset error. Subtract the two (remove gravity from total acceleration) and integrate and the offset errors cancel each other out – no vertical drift.
But it’s not the same with X and Y; there is no gravity to be subtracted, so their’s no cancellation of the X and Y offset errors as they are integrated for the horizontal velocity, and that means drift.
I’ve looked at X and Y axes offset measurement per-flight, and I might play some more with the concept, but fundamentally, the horizontal drift is unfixable and must be compensated for with other sensors. More on these later when I have progress to report on my laser altitude and drift tracker.
Zoe did her stuff at the Cotswold Jam reasonably well, but she consistently drifted to starboard (right), even when I was safety testing her outside before hand at a much lower temperature.
The previous day, I’d also safety tested her indoors and she drift consistently backwards are about the same speed.
The setup and software for the two days was the same, except I’d removed the props for transit to the jam.
Could the difference in drift direction simply be the props? Had I rebuilt her at the jam with one diagonal pair of the props swapped compared to previously? That could account for the 90° change of drift. Certainly the change in drift does point heavily at the props. The props are plastic and they bend easily and permanently. So I now have some sturdy CF props on the way which I hope will limit the drift in time for my work engineering conference at the end of the week.
What have I been up to?
- Phoebe’s HoG PCB is now out for manufacturing – hopefully this will fix the I2C problems and allow me to progress with adding the magnetometer (orientation), URF (height) and camera (motion) sensors into the mix. The new PCBs are due to arrive on or before 29th.
- Zoe’s undergone a minor rebuild of her frame to lift her CoG nearer to prop height to reduce the swinging in an otherwise stable flight – her main battery now resides on the top plate, and her power bank underneath. I could improve this further by getting rid of the power bank completely, but that will require a new PCB to incorporate the regulator.
Other than that, I’m flying Zoe indoors daily tuning her PIDs ready for her upcoming performances. She still drifts, and because she’s now using the IMU FIFO code, I’m back to considering sensor drift due to temperature. She performs best in the freezing cold with the large difference between cold ambient and her IMU operating temperature. However I won’t be investigating this further within the timeframe of the performances.
Yet more indoor testing, indirectly GERMS related, more aimed at investigating drift against the accelerometer dlpf setting.
Speculatively, the net is that
- alpf of 3 or less (>= 41Hz) means there is no vertical drift, but there is horizontal drift because real X- and Y-axis noise is not being filtered out and the motion processing thinks there’s X- / Y-axis acceleration when there isn’t.*
- alpf of 4 or higher (<= 20Hz) gives no horizontal drift, but there is vertical drift because real Z-axis acceleration is being filtered out as noise meaning the motion processing thinks there’s less acceleration than there is.*
Again speculative, I think X- and Y- axis noise was due to unbalanced props leading to asymmetric noise which when integrated leads to non-zero drift velocity: if one of the props has slight damage, this will generate the assymeteric noise very well.
My props do have nicks and muck on them, so I cleaned them up, and tried alpf 3 again, but the drift still remained – to some extent expected as the cleaned props still had nicks in them. So out came a set of unflown props. Balanced as best I can, I tried again at alpf 3. Some vertical drift had appeared unexpectedly, so I tried alpf 2, and it was perfect. So that’s what I’ll be sticking with.
The only down side of this is that the noise getting through at alpf 2 means my germs idea in its basic form is a no go. It’s shelved for the moment as it’s no longer necessary for my short flights, and instead, I’ll see how far I can extend the complementary filter to see how long a zero drift flight can be achieved.
*To be more precise, it the integration of the acceleration (i.e. the velocites) that are wrong. The Z-axis velocity is greater than zero in reality but zero according to the motion processing due to the acceleration that had been filtered out. In contrast, the X- and Y- velocities are zero according to motion processing, but drifting in reality as the dlpf is letting through asymmetric noise.
not in the way I’d expected…
Scrot screen capture
- using the finest level of data error checking, the numbers are huge – 36 errors during warm-up rising to 50 after the flight – some of these may actually not be a problem because Phoebe was stationary throughout; an error is spotted when the sensors partially read as 0xFFFF starting from the Z gyro, but for the Z-gyro, 0xFFFF = -1 = 0.008°/s
- the yaw angle read prior to takeoff is ridiculous – Phoebe doesn’t move throughout this flight, yet yaw says she span clockwise by 70° during the warm-up period!
- The IMU core temperature only varied by 0.02°C between boot-up and the end of the flight – this is a good thing and again suggests any temperature drift during a flight is due to breeze
The second is the only real problem as it will skew the initial angle calculations made during warm up; it also add this during flight but there isn’t the corresponding yaw it should introduce. I have to assume the yaw PID is doing its job well?.
Anyway, putting the protecting code back in place lead to this.
Scrot screen capture
All’s looking a lot happier here.
The whole point of this is to try to compensate in software for the temperature drift during warm-up time, and afterwards when the props start spinning and the breeze cools the IMU back down; this was my speculation for why indoor flights don’t drift, but outdoor flights do. I think it worked but it was hard to just: comparing flights with and without boot-up prediction, the predictive code did seem to drift less, but both flights failed to reach their intended altitude, and the flights were both killed after a few seconds to stop Phoebe tripping over her toes. I’ll try later on in the day once the ambient temperature has risen about 10°C.
P.S. I don’t think there is a way to fix the height changes in different ambient temperatures – I think only an altimeter can sort that.
I flew Phoebe a few times yesterday (with blu-tack), and she consistently drifted several meters during a 10s flight – worse than ever.
This morning I brought her indoors just to confirm this massive deterioration in flight stability was temperature related. Sure enough, indoors she just hovered perfectly:
Checking the temperature from Andy Baker on Vimeo.