Jack Crossfire's blog View Details
Posted by Jack Crossfire | Mar 23, 2013 @ 05:40 AM | 7,255 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,667 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,052 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,307 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,613 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,516 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,620 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,387 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,804 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,023 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,036 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,192 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,889 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,159 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,883 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,400 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 | 4,961 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,856 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
Posted by Jack Crossfire | Mar 02, 2013 @ 02:55 AM | 4,887 Views
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.
Posted by Jack Crossfire | Mar 01, 2013 @ 02:48 AM | 5,185 Views
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.