Jack Crossfire's blog View Details
Posted by Jack Crossfire | Mar 25, 2013 @ 01:25 AM | 6,468 Views
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.
Posted by Jack Crossfire | Mar 24, 2013 @ 04:20 AM | 6,102 Views
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
Posted by Jack Crossfire | Mar 23, 2013 @ 05:40 AM | 7,381 Views
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
Posted by Jack Crossfire | Mar 23, 2013 @ 03:11 AM | 6,779 Views
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.
Posted by Jack Crossfire | Mar 22, 2013 @ 04:53 AM | 7,165 Views
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.
Posted by Jack Crossfire | Mar 21, 2013 @ 03:52 AM | 7,429 Views
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
Posted by Jack Crossfire | Mar 20, 2013 @ 03:26 AM | 6,722 Views
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.
Posted by Jack Crossfire | Mar 19, 2013 @ 05:04 AM | 6,622 Views
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.
Posted by Jack Crossfire | Mar 18, 2013 @ 02:15 AM | 6,727 Views
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.
Posted by Jack Crossfire | Mar 16, 2013 @ 10:47 PM | 6,496 Views
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
Posted by Jack Crossfire | Mar 16, 2013 @ 01:26 AM | 6,918 Views
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.
Posted by Jack Crossfire | Mar 14, 2013 @ 12:28 AM | 6,131 Views
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.
Posted by Jack Crossfire | Mar 13, 2013 @ 02:20 AM | 6,146 Views
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.
Posted by Jack Crossfire | Mar 11, 2013 @ 07:18 PM | 6,298 Views
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.
Posted by Jack Crossfire | Mar 10, 2013 @ 03:45 AM | 5,994 Views
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
Posted by Jack Crossfire | Mar 09, 2013 @ 02:40 AM | 5,268 Views
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.


Posted by Jack Crossfire | Mar 08, 2013 @ 05:14 AM | 4,955 Views
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.
Posted by Jack Crossfire | Mar 05, 2013 @ 04:18 AM | 5,470 Views
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.
Posted by Jack Crossfire | Mar 04, 2013 @ 04:27 AM | 5,033 Views
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.
Posted by Jack Crossfire | Mar 03, 2013 @ 02:13 AM | 5,934 Views
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:

#define ABSDIFF(frame1, frame2) \
({ \
	int result = 0; \
	asm volatile( \
		"mov %[result], #0\n"           /* accumulator */ \
		"ldr r4, [%[src], #0]\n"        /* read data from address + offset*/ \
		"ldr r5, [%[dst], #0]\n" \
		"usada8 %[result], r4, r5, %[result]\n"      /* difference */ \
		"ldr r4, [%[src], #4]\n"        /* read data from address + offset */ \
		"ldr r5, [%[dst], #4]\n" \
		"usada8 %[result], r4, r5, %[result]\n"      /* difference */ \
		"ldr r4, [%[src], #(64 * 1)]\n"        /* read data from address + offset*/ \
		"ldr r5, [%[dst], #(64 * 1)]\n" \
		"usada8 %[result], r4, r5, %[result]\n"      /* difference */ \
		"ldr r4, [%[src], #(64 * 1 + 4)]\n"        /* read data from address + offset */ \
...Continue Reading