So the next best thing to a Kalman filter is a least squares approximation of all IMU results. Instead of averaging 99 gyro steps + 1 accel result, you feed 99 gyro steps and 1 accelerometer result to the least squares equation and it spits out the best estimate of the true current state.

BTW, Gumstix showed the 600Mhz board in stock for the first time since it went on sale a year ago.

> light rain...rain....rain...very
> wet pattern from Thursday through Sunday
> with progressively wetter systems...
> hazardous weather outlook...

Have new techniques to waterproof Vicacopter using painter's drop cloth.

Video AHRS tests gave 2 conclusions:

Need more clockcycles to run a 14 state Kalman filter or need a better AHRS algorithm to use the existing clockcycles.

Need a better camera to get higher framerates.

Suspect the 14 state Kalman filter worked better than the 7 state because it accumulated history in the velocity stores. Another idea is to predict future drift from historic data.

One other thing. Amazon's touch pad finally died so a new laptop is back on the budget.

Now a word from our sponsor.

When Earth is not enough. (0 min 50 sec)

Simulated another flight recording with HUD, video, & moving map. The idea is to find any evidence of GPS lag. Looks like the Aiptek does 8fps in HQ mode and 4.25 in low quality mode. The AHRS is still pretty awful. This was the uBlox, dynamic model 6, 1Hz.

HUD + video + moving map (0 min 58 sec)

Finally have a way to plot flight recordings on a moving map. The uBlox autopilot tests are replayed. This was dynamic model 6, 4Hz. Underdamped oscillation clearly visible. Can't verify the GPS accuracy although it seems to lag too much for 4Hz to be useful. Time is compressed 3x.

Autopilot test on moving map (0 min 39 sec)

And this was dynamic model 5, 1Hz. Time is compressed 5x.

Autopilot test 2 on moving map (0 min 47 sec)

...Continue Reading

2 Pedestrian - same as 3 Automotive

5 Airborn(e) <1g acceleration - increased delay

The answer is no. The dynamic model settings didn't do much except maybe add delay. The goal with the uBlox was to increase wind resistance but everything besides DGPS is still gravy. So we fought the uBlox for 1 month. 4Hz wasn't really there without DGPS. Don't want to devote that huge amount of space and weight to something which doesn't make much difference.

Well the video overlay HUD showed a serious influence of acceleration on AHRS and it leads back to better GPS to take it out.

On the first sunny XMas in many years, finally got HUD overlays from the flight recordings. With every flight parameter + video stored on flash, we can simulate a ground station in the dumpy apartment.

It's a painstaking process, rendering the HUD & synchronizing it to the video. Just needs a few hours to capture the OpenGL output over AGP. Times like these make U wish U just wrote it in C using software graphics + YUV overlay. Overlaying on video this way is very fast. May never draw 3D graphics or run this in Windows.

HUD & video for XMas (1 min 39 sec)

Can finally see how bad the AHRS is.

Going through each uBlox model 1 battery at a time.

1 Stationary - no velocity readings
3 Automotive - noisy data
6 Airborne with <2g Acceleration - longer delay

* 1 Stationary
* 2 Pedestrian
* 3 Automotive
* 4 Sea
* 5 Airborne with <1g Acceleration
* 6 Airborne with <2g Acceleration
* 7 Airborne with <4g Acceleration

It defaulted to "Automotive", so now we put it on "Airborne with <2g Acceleration". The logic seems to be more lowpass filtering the higher U go. Suspect the most sensitive model is "stationary" and the least sensitive model is "Airborne with <4g Acceleration".

Either way, high wind & rain will keep away meaningful tests for the rest of the year.

Got some good news. The bogus climb rates from the uBlox were actually a bug in the simulator. It was reading heading as climb rate, hence the range of -3.14 - 3.14. Also, the uBlox is randomly ignoring configuration lines, so it often generates garbage NMEA sentences. Climb rate is now in the meaningful range, if not actually useful.

XBee is paying off in this wind. Had 1 save which wouldn't have been possible on 72Mhz.

Well, got our first autonomous video from the Aiptek. Besides tons of manual altitude nudges, it actually maintained horizontal control in 5mph wind. The uBlox definitely has less delay.

Got 100 lousy seconds of video. Only hand stabilized 35 seconds for the viewers at home. The rolling shutter was in attendance.

Aiptek video in auto hover (0 min 36 sec)

Need a tiny camera with a real fast, manual shutter speed + full frame shutter. Next year's cameras R going to be 20% more expensive than last year's.

Well, if U plot acceleration vs. attitude U don't get any correlation. The secret is still locked up in the neural network.

After more test flights in cyclic -> attitude mode, it looks like 4Hz without DGPS doesn't buy much. Attitude hold is also sensitive to wind. If 4Hz doesn't come through, we're dropping a few grams and going back to the EM406.

Cyclic -> attitude mode with hard coded angles is so stable it's tempting to just live on that. Can fly through trees in ways no IR stabilizer ever dreamed of.

The search for GPS noise continues. Put the antenna out from under the blades to measure blade interference. Put her on the ground and cycled the throttle from 0 to light on the skids to measure vibration effects. Got no obvious interference.

One thing is 4 sure. There are no blogs discussing DGPS experiences. Maybe Web 3.0. Have 1 more scenario with 4Hz before it's time to think about DGPS.

The latest batteries are now down to 13min of flying. The first batch was retired when it hit 8 minutes of flying. https://www.rcgroups.com/forums/atta...mentid=1389849 As recently as https://www.rcgroups.com/forums/showthread.php?t=750660 the current batch was doing 20 min.

Have an F35 engine. Pratt 'n Whitney didn't release hi res versions of the most recent test firing although they have an older test firing.

Lowpassing the GPS readings revealed a neat thing. Feeding the lowpassed velocity into the neural network gives back roughly the unfiltered velocity. So we have 25% bandwidth climb rate directly controlling throttle and 100% bandwidth ground speed + the neural network controlling cyclic.

So with the lowpassed climb rate, got better horizontal results but no altitude hold.

To that end, we're now pushing for another step down in neural network load. This should lead to a hard coded networks for attitude -> acceleration and acceleration -> attitude. Then, a realtime calculation of neutral attitude should be possible by feeding in current acceleration.

Well, had enough pullback in the rain to resume test flights. Time to run the Rotomotion PID controller + uBlox scenario. This controller applies position error, integrated position error, and absolute velocity directly to attitude. As with the EM406, it was not even close to the Vicacopter PID controller. Suspect it could be tuned, but the Vicacopter PID controller would always be more stable.

The Vicacopter controller applies position error to target velocity. Then it applies velocity error to attitude.

This time the climb rate was out of control in the same spot it seemed stable on 12/16. It looks like altitude is the first to go back to 1Hz. Whether or not accuracy is to blame, there's a simple matter of throttle not being fast enough to keep up with GPS updates without causing yaw. Sudden yaw throws off horizontal control. That leaves only $133 of the uBlox's $200 tag intact.

The uBlox seems to be an EB85 of another kind. More and more it seems anything above 1Hz is going to require DGPS to give reasonable accuracy. The pros all use >1Hz GPS but they also use DGPS.

Stepped up the XBee telemetry rate yet again by reducing accuracy. The test video is still from the lousy pencam. Obviously the pencam is a bit tilted and we have a few radio dropouts.

Video overlay HUD #2 (1 min 15 sec)

So after the sessions with straight PID feedback & GPS devestated AHRS, put the neural network back in the loop. With the neural network providing only a 1/4sec prediction and the increased cyclic gain, got good hovers pointing North. Pointing anywhere else was impossible.

The increased cyclic gain was the key to higher GPS speeds. The feedback rate & the GPS update rate have to resonate like a tuning fork. Of particular note, 4Hz climb rate on the uBlox is coming out pretty worthless. Climb rate probably has to be stepped down to 1Hz. Climb rate didn't have a problem on 12/15, making the different parts of the test range suspect.

Unfortunately lost the Gumstix flash again. It would not boot.

Well, we have simulations with and without GPS assisted attitude calculations. The trick with this is GPS is delayed & prone to glitches. U have to dilute the GPS corrections over many output samples and delay the accelerometer readings.

The accelerometer reading corrected with GPS is blended with the gyro readings. We do not apply GPS corrections directly to gyros.

The corrected acceleration never hits magnitude 9.81 like it's supposed to.

The GPS corrections gave more accurate but seriously delayed gyro results. Finding the less inputs U put into the attitude, the faster and less accurate the result. The more inputs U put in, the slower and more accurate the result.

Should reduce blade pitch one of these days. Raised it to lift HD cameras, but it made wind very hard for even humans.

Wishlist:

30" monitor: $1400
900Mhz video set: $200
Laptop: $600
Laptop video capture: $150
HD cam: $660

Have over $100 invested in worthless SD cards. The Canon A450 seems the most practical way to recover that investment with less crash risk. Still having post budget stress syndrome from the Canon TX1 crash. With official inflation at 4.3%, it's easer to blow cash & crash cameras.

According to NOAA, we're done flying until 2008.

Have enough useless equipment to build a semi autonomous ground rover.

1 Functional 72Mhz radio set.
1 Partially functional 72Mhz set.
2 1Hz GPS modules
2.4Ghz video set
2 standard 360' servos
2 standard 180' servos

Not sure how useful it would be. There's not much to see from ground level.

All the systems developed since Nov 30 finally got their flight test.

That is:
2 way XBee communication
software UART
ground station HUD
file upload over XBee
GPS supercap
new starboard LED strand

No issues with anything even though the 4Hz GPS could not hover itself for very long. The neural network is gone. Put the cyclic gains way up again, so it can actually respond at 4Hz, and didn't have any problems. We think 4Hz GPS has what it takes.

The XBee with HUD is a dream to fly. No more guessing about battery level & radio quality. Climb rate & acceleration would be nice, but we don't have time when flying to see anything but the tick marks. Faster update rates would be huge. The laptop still goes 35 minutes with full time OpenGL. File upload from the HUD would be nice.

The HUD revealed very fast GPS measurements from the uBlox. Also, it showed the algebraic AHRS is not just broken, it is completely broken. It can't recover from coordinated turns or any sudden acceleration at all.

We need to be taking more GPS acceleration out of the AHRS. This step is a hack. U need current attitude to subtract GPS acceleration from the current attitude.

HUD + stored video

Video overlay HUD for vicacopter (1 min 8 sec)

HUD alone

HUD without overlay (1 min 2 sec)

...Continue Reading

Well, this is what U get when the HUD is getting full navigation data from XBee telemetry. There is no live video. This was stacked on some archive photos. The navigation data was from sitting in the dumpy apartment.

The XBee latency problem is a real buster. If few people are trading Spektrum DX7's for XBees, now U know why. The command to set the packet timeout is either unreliable or it has a minimum timeout of 3 characters. If U set it for a 1 character timeout, sometimes it works. If U give it the default packet timeout the latency goes away every time but U lose a lot of bandwidth.

Now page 2

The award for the ground station GUI goes to Java OpenGL. Java has many 3D standards. Most of the 3D standards peaked years ago and went on life support when Sun focused on J2EE.

Java OpenGL seems to have the most current activity on the internet, but if U want a big corporate job programming flight simulators, Java3D is actually more valuable. A peculiar move for corporations, or is it?

A HUD overlaid on video would be nice. Our first video capture board was $80 in 1999. How much does video capture on a laptop set U back now? $150 and U have to rip the firmware from a Windows installation. With that, the best route is no live video and HUD playback on recorded video in the dumpy apartment. Virtual economy U might say.

Optimization round 3 got 2620bits/sec uploads to copter thanks to compression. Firmware replacement only takes 3 minutes. AHRS readings came in at 4Hz thanks to 5 responses being sent for every request. File downloads from copter only reached 2200 bits/sec using the same trick + compression.

The horrible downloading performance only makes sense in terms of our horribly inefficient Java algorithm, but this story has been beaten as far as possible. It's so cold, we don't predict much file transferring in the field.

The main problem is still a 1/4 second delay sending flight controls. Sometimes it hits exactly when the control is sent and sometimes it delays.

Wholesale inflation hit 38% annual rate in November, a new world record. Guess the 20% rise in LiPo prices wasn't just maxamps.

In the second optimization run, file transfers from ground to copter were all the way up to 1900 bits/sec. A complete firmware upload takes 6 min. From copter to ground it's 826 bits/sec. Full navigation data is still 2Hz. If U just do attitude it's 6Hz. Copter to ground just isn't optimized because there's less value in it. But it's so cold, flying isn't very attractive either.

Well the Sanyo HD2 went from $500 to $660 in the last month. Guess we won't be resuming HD video for a long long time. The Canon itself dropped to $400, but it's only worth $300.