A few more days of banging on I2C revealed 802.11 was still jamming it. The RF shielding in the AR Drone should have been enough evidence that 802.11 interferes with CPUs. There was some improvement by filtering the power supply. It was most stable on a separate power supply, but it still glitched. Bending it at certain angles improved it.

The RF consumed 0.25A. The ARM consumed 0.17A. The occasional 1 second glitches might have been acceptable, but the permanent crashes weren't.

This embedded wifi implementation of 1 year sucks, overall. It's either gotten worse in the last year or the Transformer Prime is just awful. The rear facing camera on the transformer also stopped working in no time. That may have been a software bug in an upgrade. It was the most aesthetically pleasing tablet, even more than any ipad, but it had lots of problems which the less visually appealing Transformer Infinity improved.

Sadly, it seems tablets are going the way of film. Phones & laptops are returning to dominance. Steve may have had future plans which would have made tablets continue to dominate, but there wasn't any other creative force after he died.

There's always going back to 900Mhz with a ground station relay.

So it's harder to detect movement in the camera's X axis because adjacent X pixels have less contrast, yet movement has to stay very slow to prevent saturating both axes. An eternity of tweeking produces better & better speed ranges, angular rate decoupling.

Anyways, probing around the AR Drone's downward camera revealed a data line of some kind running at 60fps, 240 distinct rows per frame, 320 pixels per row. 320x240 is indeed what it's recording over wifi & it's not a USB cam.

With the STM32F4, the best is 96x96 at 68fps. More tweeking may increase the search radius while decreasing the size or framerate, yet this changes the gyro decoupling parameters.

Profiling the optical flow, there are enough unused clockcycles to theoretically process 400fps with the current algorithm. The highest the current camera can do is 320x240 at 100fps, because that's the highest clockspeed PWM can generate. 640x480 maxes out at 68fps, because the GPIO's can't handle data any faster. It's pretty noisy at 100fps.

A lot of contemplation revealed a test harness for optical flow. There are a lot of variables for desired altitude, focal length, gyro calibration, frame rate, image size. Gyro calibration removes some but not all of the angular motion. It requires a lot of movement to detect anything. If the resolution is too high, the amount of movement can exceed the motion vector range. If the resolution is too low, it can miss a lot of movement.

There are enough clockcycles to scan a much bigger frame. At least it's not catching up to the PX4Flow anymore.

AR Drone test 2 (3 min 42 sec)

The AR Drone's downward camera is 320x240, 18x the area currently scanned by Marcy 2 but probably doable at 30fps. The AR Drone scans the entire field of view at 60fps. In manual horizontal mode, it completely disables the autopilot, giving complete cyclic control until the button is released.

The Goog couldn't find any examples of vectored thumb inline assembly, so it was a matter of trial & error. The STM32F4 programming manual, inline assembler cookbook, & STM32 Discovery firmware are your biggest allies in this part of the adventure.

It turns out there are no NEON instructions in thumb mode. Thumb mode has yet another set of vectored instructions with no special name. The one you want is USADA8. There are no macros inside the inline assembly. You need to write a preprocessor or suffer. For the 1st time ever, it's the inline absolute difference of an 8x8 macroblock:

...Continue Reading

Then comes the point when you realize the RTL8192 doesn't need a voltage regulator. It can run directly off the battery, if it's a 1S aircraft. It could use just 2 MIC5205's.

Weight: 11.2g

Much lighter than the PX4flow's 17.5g + 2nd board.

Sure enough, implementing what the PX4flow already did is a lot of work & makes you wonder if the time for a rewrite couldn't be used for something else. Doing only single pixel accuracy in scalar C gets only 64fps & reduces the IMU from 1200Hz to 170Hz.

The PX4flow source code would be quite valuable. There aren't many NEON examples anywhere, either.

So the weight of the final airframe is unknown, besides definitely heavier. Shrouded propellers, foam or plastic filling will be in attendance. If the PX4Flow ended up unflyable on the final airframe, there wouldn't be enough time then to make a scratch built flow system.

Then, the PX4flow was too big to fit without longer landing gear. It was harder to fly. That was motivation to move ahead with a scratch built flow system, but keep the PX4flow around as a last resort.

There are ways to get more thrust out of something smaller than the Syma X1. You can have 6 or 8 smaller propellers, 3 propellers on top & 3 propellers on the bottom of a cylinder, a bigger battery, ducted fans, all in a smaller horizontal space.

Nothing can be mounted until the optical flow method is selected. Using lessons learned from the PX4flow, the flight computer moves ahead with a 64x64 window with variable focal length at 68fps. The complete computer needs 300mA to stream preview video from the camera to the ground station while doing the AHRS & PWM. 3 MIC5205's seem to handle it.