As bad as optical flow is at absolute position, it's hovering for around 90 seconds at 0.5m before slipping off the floor pattern. Above 1m, it slips off after 1 minute. At 1.5m, it slips off after 30 seconds. Most of the slippage seems attributable to fixed point math errors. The Maxbotix falls apart at 1.5m over posterboard.

Foaming the IMU & applying some fixed point integral magic made the attitude real stable. It's unbelievable how stable that thing became, comparable to the Blade MCX.

If scaling pixels to distance based on altitude must be done in fixed point, it's another area which would be best done with a lookup table instead of getting the angle, getting the tangent & multiplying by the altitude. Horizontal distance also needs a lot more precision than 1/256 meters. There are many navigation routines where fixed point dictates combining many steps in high level lookup tables instead of using discrete trig functions.

Stability is still comparable to the 20 second hover in the px4flow demo video. Time for some waypoints.

Optical flow Syma X1 (1 min 21 sec)

There it is. What made it stable enough was discarding the accelerometer & letting the gyros free roll except for heading. There's a real problem in the fixed point blending code. For now, a large integral with just the right gain keeps up with the drift, as always.


The problem went back to optical flow slippage. It's not good enough to fly to a waypoint. There's not enough computing power to track a single object.

The motors get flaming hot in 1 minute, so there's not a problem with the gyros drifting after 2 minutes.

The entire available floor space in the apartment was finally painted. It seems to provide a very easy surface for optical flow. Noted the angular motion needs to be very accurately eliminated from optical flow or it won't work, at all.

Then there was a reversion of the altitude algorithm to a rate feedback. Altitude with the indoor vehicles has always been the easiest direction, even at 10Hz.

Wifi continues to interfere with sonar, with an evolution of wire arrangements in progress. Twisting the wires & having them at the same level as the sonar improves it.

The motors overheat after 2 minutes of flying.

This leads to the IMU drift being too high. Usually, it crashes right away. Sometimes, it hovers for a while & drifts into a wall. The problem is the IMU drifting until the controls are saturated. Optical flow seems to very accurately track the position, but you can see the controls saturating just to keep it level.

Foaming the IMU didn't improve it. 5 deg of drift in 25 seconds is too high. The Ladybird uses the same gyros with less drift.

The 1st dead brushed motor happened. It manifested itself as a propeller that wouldn't turn without a lot of resistance, despite having no hair clog. The brushes must have disintegrated, leaving high friction copper. None of the other 3 motors have disintegrated, however. Those things don't last long.

Time to paint some more of the floor. Painter's drop cloth doesn't work because it's only 3' wide. A tarp would be ideal if it was black or white. The apartment is only big enough to paint a small area at a time.

Intermediate memory bootloaders (16 min 29 sec)

Mike had a useful nugget on the intermediate memory bootloader. The bootloader hasn't gotten much attention between all the other issues, but an easier way to update firmware would go a long way. The problem is there's no dominant communication method. Wifi interferes with too many sensors. USB is only used on the ground stations. The flight protocol would take 100 seconds.

Don't remember any intermediate memory bootloaders before 2009. The dominant embedded system was the camera. It was a 1 step process where the mane program flashed itself while telling you not to turn the power off. Only when smartphones appeared did the 2 step concept of downloading to scratch memory & rebooting to flash it become the normal routine. Requiring users to reboot got a bad reputation from Windows, but now they've gotten used to it.


Optical flow odometry is pure hell. Technologies are born & die over real short timescales. You can tell when particular technologies peaked by the dates on the goog searches. For brushless gimbals, all the pages are in the last 4 months, so it's the current big thing. For optical flow odometry, the pages concentrate near 2005, then it sporadically bubbles up after 2009.

Optical flow odometry seems to come & go as key improvements in microprocessors & cameras appear, people take up the issue again & drop it. It has a real problem navigating outside the 1 specific altitude it's tuned for.

Helicommand will always be the product that got it on the radar. Those were everywhere in 2007, but after the uBlox 5 came out, everyone switched to GPS.

The growing list of things to either build or buy, deferred indefinitely by the almighty dollar:

outdoor copter
brushless, direct drive gimbal
indoor dogfight game
monocopter FPV
blade MCX FPV
tethered copter

The game was always about getting aerial video, but the mane turnoff was always the lousy results unless you had a big, heavy copter & expensive, heavy gimbal. There was a time when a 450 size copter was considered too small for stable video. Guys used to preach about the small stick movements, calm weather, & flight stabilization it took to get results that still didn't compare to full size copters.

JAZZ DDG + Alex Mos + octocopter jazz8 (7 min 1 sec)

The brushless gimbal changes everything & the desire is back. Model copters can finally surpass full size copters in stability. Every aerial video made is going to look like a professional studio made it. It's not just going to change the look of amateur movies, but the way all professional movies look.


It's amazing how bad even the best servo gimbal footage now looks.

Aerial Showreel 2012 (3 min 33 sec)

...Continue Reading

Remember the disastrous PT785-S pan/tilt mount? It was too slow & too inaccurate to be any use in position sensing, but it's been made obsolete in the last 4 months by the rise of cheap, fast, accurate, direct drive, brushless gimbals.

Brushless gimbals came out of nowhere & are going to replace all servo gimbals in no time. All the goog results are coming from the last 4 months. You know it's a disruptive technology when it goes from nowhere to everywhere in 4 months. It's going to have a lot of people now using gimbal stabilization who previously were satisfied with hard mounting, it's going to make model copters a lot more ubiquitous in professional production, & it's going to make these steadicam quality shots the baseline quality for aerial video.

Servo gimbals always had a slight wobble that wasn't in full size copter footage, but that's now gone. Brushless gimbals produce a leap in video stability in a much smaller package. They were around for a long time, in the form of the DJI Zenmuse, but very expensive. The key development was a crazy Russian guy named Alex Moskalenko figuring out cheap hobby motors could be rewound to make the perfect high torque, low cogging stepper motors a camera mount needed.

This is a big leap towards making pan/tilt mounts small enough to put in phones, finally bringing steadicam stability to the masses. It's basically the 1st device which successfully replaces all the mechanics & tuning in a steadicam with...Continue Reading

Maxbotix vs wifi (8 min 17 sec)

Long & boring video documenting interference between wifi & the Maxbotix MB1043, the world's most temperamental sensor. Some orientations do better than others. At least any wifi problems aren't due to lack of power. The Maxbotix & wifi wouldn't be very useful on any smaller vehicle.

A totally random orientation of wire & dongle was required. Wire orientation, wire insulation, dongle orientation, dongle distance all determined whether the Maxbotix died. Any slight movement of the wire breaks it.

The automatic takeoff & altitude hold were extremely accurate. The 10Hz update rate wasn't as problematic as feared.

It's back again to the hardest part, the horizontal position.

So the Maxbotix actually took off & after bouncing off the floor & ceiling a few times, held the altitude at 0.5m, when it worked. It couldn't do 1m. The problem is it's jammed by wifi. Unlike the USB host jamming I2C when wifi was on, this was a real RF interference problem. No voltage ripple appeared when wifi was on.

The RC filter made no difference, but it did work when a probe was connected to it & ground. Disconnect the probe from either 3.3V or ground & jamming resumed. It didn't matter if the probe was connected to the oscilloscope. The probe must have shifted the resonant frequency of the susceptible Maxbotix part or injected an out of phase waveform. Throwing in a low ESR 10uF didn't work.

Connecting the wifi to an umbilical cable & moving it away worked. Maxbotix worked best when wifi was right next to the motors & completely died when wifi got 1/2 way from a motor. With wifi yet another problem for the Maxbotix, it continues to be a real turd. But to be sure, no-one else in the world ever put a Maxbotix on a wifi aircraft.

After this problem, all the other systems are known to be working with wifi, but there are some huge problems making wifi unviable in a product. The ground station has to be running before associating the access point, because of the inability of the USB host to transmit without 1st receiving.

So the parallax weighs 9g & the Maxbotix weighs 4.3g without the RC filter. It's heading back towards not another STM32 ground station but a raspberry pi routing wifi to 900Mhz. Not the most effecient or cost effective solution but it's the easiest to use.

As with everything Bezos, his discovery of an F-1 engine from Apollo 11 was held in deep secrecy. In 2012, he only briefly mentioned he found an engine, but didn't reveal any photos or the location. Only today, 1 year after the discovery & raising enough money to raise an engine did he release some obliquely angled photos of the engine.


The gubment & the voters did not have the money or the desire to recover the engine. Only the power of your amazon.com purchases & the imagination of 1 man could get it done.


The generation which launched the engines believed it was the beginning of a new era of interplanetary exploration, discarding the engines forever, on the ocean floor. Only after the hindsight that human exploration beyond Earth orbit was over for good, did the next generation finally revisit an engine to recover it.


It was of course the huge demand for oil exploration that improved the underwater robot technology & sonar enough to discover & recover the engine. It would have been a lot harder & probably required a government budget, 14 years ago.


The engine was 1/2 a mile deeper than Titanic, it's parts broken off & strewn around the ocean floor.



The engine thrust chamber as seen on the sea floor, where it has rested ever since producing 1.5 million lbs of thrust for 150 seconds to push Niel Armstrong 42 miles off the ground & a speed of 6000 mph. The 356 braze welded tubes of the nozzle wall would...Continue Reading

After years of being outsold by Parallax sensors in the AR Drone, the Maxbotix finally saw widespread use in Arducopter. It's ironic for the exclusive sensor of Sparkfun to not have made it into a product 1st, since Sparkfun owns the maker market. The only reason Arducopter uses Maxbotix is the branding with Sparkfun. They certainly don't care about the size.

It's only here because it's the lightest. If it has too many problems, it'll be replaced by a Parallax, but the PX4Flow should really be used.

So basically, after 6 years, the Maxbotix still has to be powered up facing away from the ground or it returns bogus values. This continues to be the greatest scourge of sonar navigation. The Parallax sensor in the AR Drone initializes properly with no clearance.

It still needs an external RC filter to filter the power supply. You'd think they would have found a way to store the calibration data on the flash or make a bigger board with integrated power filter to generate the best readings.

They treat the tiny form factor of 6 years like a religion, which makes sense, since they're in Minnesota. Religion is everything in Minnesota. The jesus & cross symbols of Minnesota fame are on all their boards.

The Maxbotix still requires a manual trigger to range at its maximum rate of 10Hz, but it repeats the same value if triggered at less than 25Hz. It needs to be triggered at 50Hz to output 10Hz of unique data.

On an 8 bit PIC, the interrupt vector is a table of assembly language jumps. On ARM, the interrupt vector is a table of bare addresses. This fact is overlooked by many programmers when moving from PIC to ARM, in the race to copy example files over to bring up the ARM as fast as possible.

Jumping to the interrupt vector actually works, sometimes, leading you to put up with random crashes for an entire year before finally viewing the interrupt table you hurriedly copied a year ago in a hex editor.

The assembly language interrupt vector for ARM GCC looks like random noise, but a hex editor reveals it's just the addresses of the interrupt handlers. On reset, the ARM jumps to the address stored at 0x08000004, the reset function. It's not actually an interrupt, but it's stored in the table.


Using optical flow to dampen horizontal movement was very discouraging. It oscillated for a while, seemed to sometimes delay the onset of the inevitable, but always eventually flew away. The time has come to calculate bearings & distances on the ARM.

The code is definitely a monument of fixed point functions which probably run faster than floating point. Bearings & distances are where most people give up on fixed point & start banging away on the compiler problems to make floating point work. The pythagorean therum is where fixed point falls apart. The numbers are too big to handle in fixed point. Output from the PX4/pixhawk compiler works until it hits the network initialization, then it crashes.

Tablet flying the Syma (0 min 0 sec)

Another round of wifi problems revealed it took 3 MIC5205's & 1500uF of capacitors to keep wifi going with the attitude feedback loop on. Getting it to run on a 3.7V battery, with random voltage dropouts from motors trying to stabilize attitude, takes seriously low dropout voltage.

The MIC5353 would do a better job. That has 160mV dropout voltage at 500mA. Parallel MIC5205's have 350mV dropout voltage at 450mA.

Otherwise, flying it manually with the tablet is reasonably easy, compared to Marcy 1. Marcy 1 had no attitude hold, while this Syma X1 has not just wifi but attitude hold. Attitude feedback has to be right up against where it starts oscillating to get useful responsiveness. Enough motion throws it into an underdamped oscillation & crash. When the connection glitches out & reconnects, it goes into an underdamped oscillation & crashes.

Gyro priority has to be much higher than accelerometers, for the roll & pitch, while being much lower for the heading. The gyros can't be lowpassed at all, with the UART delaying the IMU. Not using a quaternion hasn't been a problem.

The horizontal speed during takeoff is too high for optical flow. That's going to take some resolution adjustment. The PX4flow demo video used vicon during takeoff & trimmed out before switching to optical flow.

There's no question they could throw 1 missile up & land it somewhere. They have enough money to build exactly 1 nuke & launch exactly 1 missile every certain number of years. There's a certain chance their government won't collapse, Kim Jong Un's people won't sabotage the missile & won't ignore him. It would have a 1 in 3 chance of hitting land, a 1 in 20 chance of hitting some territory in US.


Given enough time, there's a chance N. Korea is going to eventually hit something & kill someone in US. Maybe they'll get 5 million people in a city. Maybe they'll just get the last person in northern Idaho.


The debate has not been whether N. Korea can do it, but whether they'll ever come up with a reason to do it. So far, there hasn't been any logic to it, in terms of western ideas. They don't have to subsidize Fannie Mae, medicare, social security, or student loans. They don't have to pay individual mandate penalties. They're not banned from using cell phones while driving, owning guns, or hiring prostitutes.

North Korea sounds like it has nothing to gain & everything to lose, to the western mind, but what about a totally irrational mind? We don't have a concept of such a thing so we don't worry about someone doing something just to do it. There has to be a logical reason behind it, to us.

In a world where logic doesn't exist & missile launches are only a matter of the random firings of neurons, they're mathematically certain....Continue Reading

So there was yet another difference between the STM32F405 & STM32F407, making the adapter board non functional. USB on the STM32F405 had an unknown change, making it die. It would be either a huge amount of debugging or designing yet another board using the STM32F407. Either way, it would now be just as hard as implementing an I2C breakout board to scan the IMU.

So the I2C breakout board worked perfectly. 367khz I2C achieved with no timeouts. 1100hz gyro, 125hz mag readings. No wifi problems & no extra ground station board. It needed a 400khz UART to transfer the readings fast enough.

There's at least 0.5ms of extra delay to get the readings from the I2C breakout board to the mane processor. The I2C interface itself has at least 0.4ms of delay to get the voltage from the gyro. In total, it could take 1ms for a motion to be detected. Such is the sacrifice of reading out an IMU on I2C. The delays from movement to digital reading are what make stability.

The I2C chip ideally needs to be on a new mane board, but only if there's enough time.

The adapter board came in at 4.5g. The new flight computer board with 900Mhz instead of Wifi, the required star routing, the required capacitance, & no sonar came in at 8.3g. The bare sonar module is 5g. So flying the adapter board would not be ideal.

A new round of radio debugging begins. If the IMU was done on a separate micro, like the AR Drone does it, there would be more latency, it would be heavier, but it would probably be the same amount of work.

The 1st flight test showed a 1000Hz IMU with 2000Hz PWM was extremely stable. The IMU was lowpass filtered at 1/4 bandwidth. There's no vibration problem with this indoor quad. Unfortunately, the rate of I2C crashes was too high for any useful flying.

It was 1 year since the embedded Wifi stack was implemented, at great difficulty. There was a lot of nostalgia for the time when it was being implemented.

You always long for a past time, no matter how difficult it was, being 1 year younger, having 1 more year to go. As impractical as it was for wireless video, it sure was neat to see it stream video for the 1st time. No-one else ever did anything nearly as ambitious with the TCM8230 & STM32F4.

The I2C crashes weren't known until after wifi was running. Then came the discovery that hardware I2C didn't work when wifi was on.

1 year later, it was routinely transmitting 2.5 megabits when the optical flow was in debug mode. You still can't buy a radio module with that bandwidth.

It was finally discovered that pulling up USB+ with a resistor was enough to crash I2C. It didn't matter if all the USB interrupts were disabled. There is a silicon bug which makes USB host interfere with I2C above a certain frequency. Maybe it's a conflict in the AHB bus.

Being a 1 off aircraft with only 1 mission, there's no point in banging on wifi anymore. A breakout board for I2C would be too heavy & take too long to design. The roving networks modules would be too heavy.

Will the investment in wifi ever be recovered? A ground station bridge between wifi & 900Mhz is now proposed, as big a rewrite as any other idea. The only reason it wouldn't be a standalone wifi module on the aircraft is weight, but it would save a battery & be sexier if it was airborne. Converting between a ground station & aircraft module is just a matter of soldering 1 wire. It needs just enough reliability to start & stop the motor.

Avoided starting the motor tests because it was going to be a disaster. You design the power distribution under the most optimistic, weight saving assumptions, then rework until it works. Sure enough, nothing worked when the motors started.

The motor ground & Vcc couldn't power anything besides the motors. The ARM Vcaps needed to be grounded as close to the battery leads as possible, not just the ARM Vss. Wifi was hopeless anywhere on the 4.2V bus. It needed the 3.3V regulators & caps.

The general idea seems to be all the grounds & regulators need to tap the battery leads at the same distance from the battery, as close to the battery as possible. The motor busses don't have the conductivity for the given weight hoped for. Back EMF sends 7V spikes into battery +.

There's a lot more margin if the motors are slowly ramped than if they're suddenly from 0 to full power. Nailing the 0 to full power test is the Murphy's law requirement. Powering it off the bench supply doesn't work. It needs a short lead battery.

In other news, a ground station on a laptop showed much better wifi performance than the Transformer Prime, so this particular tablet is a problem & not definitely the design.

The reworked mess came in at 13.9g. Still lighter than the PX4flow's 17.6g.

So the optimum pattern seems to be random splotches of paint with dry brushing in a grid. Too much brushing makes it too smooth. A few gallons of toner would be nice. A laser printer could get the optimum fractal pattern perfect.

For all the energy going into making robots navigate human environments, there's no pondering of the idea of making human environments navigable for robots. Floors with optical flow patterns would be a lot easier than LIDAR.

Anyways, wifi won itself a reprieve. Changing it to channel 3 cleared it up & it went back to the smooth video it had before. It seems a new neighbor jammed channel 8 & the software was still pretty good. Without a frequency hopping algorithm, this is part of the game.

Without interference, the RF dropped back to 100mA. There's a lot of adaptation & buffering going on in the RF module, making it hard to debug. UDP is believed to be buffered with ACK packets, in the wireless layer.

900Mhz would fix I2C & have no interference, but require a ground station. It's a close call between the 2 methods

Optical flow odometry begins. The key for anything to work is aligning the motion vectors to world frame. As long as the motion is fast enough, it's pretty decent.

The best patterns seemed to be any kind of dry brushed paint, over 50% white. Straight lines of featureless tape were the worst. It seems to rely on texture of the paint up close, while painted patterns far away. The only way to get a pattern big enough to fill the flying area with enough reflection for sonar is paint on a plastic drop cloth.

The worst patterns require a higher minimum motion. The best patterns cause the least minimum motion to be detected. The pattern affects the outcome more than the frame rate or resolution.

Also, the PX4flow uses a histogram of the motion vectors. Found better results from a straight average of the motion vectors.