So after yet another loss of radio contact and yet another crash, the throttle tapering algorithm may not be the best failure mode. She just sat on the ground, thrashing for several minutes, destroying the IMU, hurling a Z link, grinding a spur gear. Going back to throttle cutoff. Suspect the placement of the cube batteries is degrading radio contact.

File uploads on 72Mhz worked perfectly, however. Very fast and easy to change PID constants until the laptop battery dies.

The writing is on the wall for XBee-Pro. No-one has ever used an XBee-Pro for flying and documented the reliability. Would need to implement a UART in software.

Got file uploads over 72Mhz working. The nominal bitrate is 400 bits/sec. The longer the file, the lower the bitrate. The maximum file size is only 520 bytes. The entire file must be stored in the transmitter SRAM. The pilot needs to run a utility to stock the transmitter SRAM with packets. The transmitter rebroadcasts the packets over and over while Vicacopter reassembles them into a file. Vicacopter's status LED freezes a solid green when a complete file has been received. When the pilot kills the utility, the transmitter returns to flight control data.

Through gzip compression, sending a 1000 byte file. The bitrate with compression is 3kbit. Forget about firmware replacement with this. It's only uploading PID constants. Longer files could be supported, but it would be extremely complicated and slower.

Unfortunately, it's the end of configuration by dumb terminals until the XBee upgrade.

5) Waiting for Americans to lose weight
4) Waiting for NASA to go back to the moon
3) Trying to defeat terrorists
2) Saving dollars
1) Implementing a radio return path using a TV transmitter

So the TV transmitter return path worked in the dumpy apartment, but never in the field after the first mission. Seemed to depend on the ground loop in the dumpy apartment.

After that, tried autonomous cyclic again. For something that's being done for $70, it's pretty hard to get cyclic to stay level.

Finally, lost radio contact during a high speed forward movement. Crashed into the nose. That was the end of 2 way radio over TV transmitter. The TV transmitter interfered with 72Mhz reception before and it probably happened again today.

Still can't justify the XBee if cyclic automation isn't proven, but it will be in attendance if we ever use the TV transmitter again. Meanwhile, can set PID constants using 1 way radio. It involves sending a file by 72Mhz and signaling completion by LED. It's more pilot intensive, requires a laptop, doesn't have the future that 2 way radio had, but can upgrade any part of the avionics by replacing files.

Suppose 2 way data communication using 72Mhz systems is interesting because the range is better than any 802.11 and it's a completely self reliant connection. No service plan. No router.

Just can't think of anything that could use 3kbit/sec, 72Mhz transmitters interfere with all surrounding electronics, and better results can be achieved with optics.

Seems the XBee-Pro had a price cut. It was over $45 last month. Now it's $32, bringing the total system to $70. Contrary to many assumptions, the XBee-Pro uses spread spectrum, it only transmits when necessary, so it's 12 channels aren't as prone to filling up as the wireless TV cameras. It's really only worth $20, but because dollars are losing value precipitously, the price is $32.

The question is, is it worth spending month after month on custom 2 way radio? Originally wanted 2 prove Vicacopter could hover before investing any money in stuff only required for development. Still don't know how well the XBee handles the orientation changes of a copter. The price of 2.4Ghz for those 6 months was prohibitively high, we got stuff in the air sooner than it would have taken for 2.4Ghz to become affordable. Custom 2 way radio is still cheaper to mass produce.

Data communication by TV transmitter is proving pretty awful. The one video showing internet responsiveness was a coincidence. Most of the time it doesn't get TV transmitter data. So another day goes by with no progress, only radio debugging.

So equipment problems have continued to stop progress. The laptop is dying. It probably has 1 month left before replacement. It was a top of the line $2500 model in 2005. It lasted no longer than a $1000 model. This time, the power connector broke loose. The posts were too carbonized to reattach it and we don't have the high temperature solder station that origionally attached it. It was the first laptop which never had a hard drive failure.

Since the power connector started failing, the battery has gotten overly discharged, so the battery is damaged. Combined with the endless repairs, it's cheaper to get a new, bottom of the line model for $500 than to get a new battery.

Though advertized as 2.4Ghz, it could only run at 1.8Ghz. The 2.4Ghz mode required a special power supply and extra cooling.

Also, 2 way wireless communication stopped working. Now we're going 2 try insulated cable. It's going 2 B heavy and complicated.

2 way wireless communication worked in the field on the first try. It was much faster than rebooting, swapping cables, recompiling, and uploading but equivalent in the amount of gear.

First wireless PID calibration operations. (1 min 15 sec)

Here we have the HD video of before and after a round of the yaw feedback adjustment. With the 75Hz servo PWM, 0 derivative seems to improve matters. It still has problems, like not knowing the shortest path and not having integral limits. Need to re-enable the magnetometer to get absolute yaw.

That mission also tested lighting reinforcement for video. Not much improvement besides seeing the tail rotor....Continue Reading

First flight for the Canon TX1 (4 min 3 sec)

So after 5 hours of preparation, finally got the first daylight HD in. What really stands out is the Canon's high shutter speed. Blades appear to spin backward. The copter is always sharp.

At high shutter speeds the 1/2.5" CCD's all bloom when shooting white objects in front of dark backgrounds. The solution is to use low shutter speeds and stop down, but the Canon doesn't have manual shutter speed for video. It uses the highest shutter speed possible.

The Sanyo HD2 has manual shutter speed, so it wouldn't have this problem.

For the Canon's first coverage, had upgraded PWM code and a new 3.3Ah battery. Got 15 min before wind became impossible to take off in without flipping over. The ESC wouldn't work with the PWM at 60Hz. Needed 75Hz.

Notice the yaw oscillation. The PID loop must be recalibrated for the new PWM period.

So after 3 weeks of debugging assembly language, the 2 way wireless interface supports packet spanning. Now up to 256 bytes can be sent for each cycling of the 72Mhz transmitter. Did packet spanning improve the interface? Hell yeah. Instead of getting a single line of a menu every second, it's now almost instantaneous.

The 2 way algorithm tries to more intelligently cycle the 72Mhz transmitter, resulting in responsiveness which resembles web page loading. When a fragmented packet is detected, it's supposed to keep the 72Mhz off until the entire packet is received. This of course, depends on if data needs to be sent and our assembly language skills.

Also in this update, PID text entry is working. It's just enough of an interface 2 B useful, but without a remote echo, it can't be very functional. So all your user input is sent up the 72Mhz band and all your menus are sent down the 2.4Ghz band.

2 way wireless with packet spanning (0 min 45 sec)

Now we get 2 debug the upgraded servo PWM code. Also in this issue, have For All Mankind on the hard drive and noticed how incredibly sharp the Apollo footage was compared to modern video. They let the S-II stage separation play until the Earth appeared in the interstage ring and it was way beyond the modern SRB separation video.

The color and sharpness of the Apollo footage made it feel like it was the real deal and everything since has been pretending.

Decided 2 hit Vimeo and The You with the same video and found they both use variable bitrate.

Vimeo: 464x352 750kbit 250MB limit per week several hours to upload
Youtube: 320x240 820kbit 100MB limit per video faster upload

Forget about The Goog video. Vimeo seems to do a better job compressing, but The You is a brand and in Goo. Know. Where., branding is everything.

Vimeo Test (2 min 25 sec)

Youtube test (2 min 26 sec)

...Continue Reading

So the next mission is going 2 B a PWM upgrade test. The servos have been driven at 152Hz. That may be causing a lot of jitter and unrepeatable positions. Decreasing the servo frequency to the 60Hz range should give us a lot more accuracy, but it's not easy in assembly language. The PIC timers are shared with functions that require wrap around at 152Hz, so U need extra steps to delay longer than 6ms delays.

The effect of the servo upgrade is unknown, but what is known is the mission after that is the first PID tuning in the field. Any wireless PID tuning needs a bandwidth upgrade. There isn't enough battery power to wait for the previously described, transmitter cycling algorithm. Sending multiple packets in a single transmitter cycle is the only way. It's yet another upgrade that would be easy in C but is going to take several weeks in assembly.

Finally, the next step with the PDA is now seen as running the MAX3389 without capacitors since the problem seems 2 B the capacitors. Maybe it'll pass through the 3.3V signals without amplification but still provide ESD protection.

Dog show outside the dumpy apartment 2day, so guess what. The Canon passed 60,000 exposures....Continue Reading

Well back to full cyclic tests. In test after test, the same thing happens that happened to the Kalman filter. Drifting pitch over time followed by uncontrolled acceleration. Maintaining heading causes some improvement. At least this INS doesn't explode randomly. Really need video to characterize the drift, but with those high velocities there's no way to keep the camera on it.

In a copter, heading determines pitch. Pitch up 45', turn 180', and the INS still thinks it's pitched up 45'. Bicycle wheel syndrome, U might say. So you have to either recalculate pitch for every heading or fix the heading manually as we've been doing. Don't intend to mount a 4th gyro on Vicacopter for heading hold.

Like U already know, stopped using the Kalman filter because it was too unstable and it obfuscated many of the details. Now we have a straight blend of gyro integrals with accelerometer euler angles with very precise control of the blending. 0.995 of every gyro step is added to 0.005 of every accel step, the smallest possible number needed to defeat drift. Also, the gyros need 2 B scaled very accurately, so the integral precisely matches the accel results over short periods of time.

Long feared the IDG300 wouldn't be sensitive enough to detect rotation. The IDG300's are sampled at 195Hz and their 0-3.3V output is converted to a -32767 - 32767 number. This needs 2 B scaled by 1/200000 to get an accurate angle integral in radians. So at least for large deflections, they're sensitive enough.

That gives very smooth tilt results and seems to hold most of the offset during sideways acceleration. Also fixed the latest throttle issue and the tail gyro eliminator is working again. The PIC experienced 320 bytes of random flash corruption somehow. Reflashed it and it worked again. Now we're back to PID calibration over 2 way radio.

So making the receiever not touch the ESC resolved the communication problems. Bitrates are now in the 3kbit range because 2 bytes per packet were added for user data. Longer packets with no FEC mean more data is lost with each error.

A throggle bug persists, where after shutting down the motor by powering down the transmitter, the motor spins up when the transmitter is powered up again, regardless of stick position.

In today's flight, the software tail stabilizer unintentionally used absolute yaw instead of rate, not a good situation. Jack Crossfire is such a good pilot that he managed to overcome the sudden losses of yaw control and make it look like it was working. Yet another of many glitches plaging these return to flight missions.

So in the first video assist flight, there was no correlation between accelerometer output and pitch. Managed to get correlation between video & pitch integral but had no mechanism synchronize the video with the flight recording. This video was hand keyframed.

Video assist (0 min 7 sec)

So plagued by communication problems, managed to get 1 test flight out of Vicacopter. The mission was the first to correlate inertial data with video of actual position. Communication was so horrible, the flight wasn't accurate enough to get very good data.

The analog sensors are now putting out 193Hz. One of the strategies during the 2 way radio escapade was to speed up the analog conversion for demodulation. Though unsuccessful at demodulation, the improved analog conversion remained. Unfortunately, all the processing for the 2.4Ghz modulation may be destroying flight control communication.

The cropped HD picture managed to bring out Vicacopter pretty well on Utube. Pitching movement is clearly visible. Although not visible in the cropped version, translation movement forwards and backwards is also visible. Since this flight was plagued by communication problems, could not get any controlled pitching movements in frame.

Night flight (0 min 58 sec)

On July 4, for the first time in 7 years, Jack Crossfire made some piano movies with the Canon TX1. Spent 2 hours making piano movies with Canon #2 at Russian Heroine II's sister's mansion. Picked only the pieces he could have practiced and recorded in 2 hours so there's not much.

Chopin Prelude 15 (6 min 6 sec)

Chopin Prelude 13 (4 min 14 sec)

...Continue Reading

So the replacement MAX3389 had no effect on the PDA. With the new MAX3389 it couldn't even receieve data. Options are to buy a commercial serial port for it ($40) or get a more portable laptop ($600).

Moving forward with the old laptop, finally got 2 way wireless working. Phase shift keying, 4 bit flow control, CRC checking, and transmitter power cycling are all working.

The ground station first enters 2 way mode when the user enters an i. To flush the serial buffers, it takes a bunch of i's. Vicacopter is programmed not to enter 2 way mode unless the throttle is off and once in 2 way mode, to fix throttle at 0. Need 2 test that. Vicacopter sends a private code to exit 2 way mode. The user must exit 2 way mode before the throttle is reenabled and transmitter cycling is disabled.

Cycling the 72Mhz transmitter every 1/2 second to defeat interference works. It's super slow but usable. Only 1 packet can travel in a single cycle. The algorithm could be improved to combine multiple packets in a single cycle, but this may be replaced by a proper 2.4Ghz modem.

Have the video of 2 way wireless working for the first time.

2 way wireless (1 min 6 sec)

Vicacopter's menu system of course, is another phase.

Once again, we used the resolution of the Canon TX1 to do software closeups. With fireworks, the result was a great improvement over full frame scaling.

More fireworks 4 U (2 min 26 sec)

So the MAX233 didn't work either. It appears 2 B neither DC offset nor oscillation but random interference from the 75Mhz transmitter. Manually switching off the 75Mhz transmitter to receive and manually switching it on to transmit is the only thing that seems to work around the problem.

The problem is we have to look at the Vicacopter console 2 know when it's time to switch on and the transmitter needs a moment to warm up. Since the protocol requires a confirmation packet from the 75Mhz for every 12 bytes, this would be horribly slow.

The solution is to not require confirmation packets. Maybe send a single menu spanning multiple packets over and over. The packets would have ID's to display each completed menu only once and counters to reassemble the fragments in order.

The transmitter would only turn on for a predefined amount of time when the user entered data. Another switch would keep it on permanently. Really need to quantify the maximum transmitter power cycle rate.

So gave up on the handheld serial console for a while. Maxim actually has a free replacement part for the Palm, but it won't arrive for some time. Meanwhile, it's back to the laptop.

The biggest problem with 2 way communication is now 75Mhz RF interference with the output of the 2.4Ghz receiver. The output appears DC biased. Tried many strategies to defeat it.

Our favorite was a low voltage differential output from 2 op amps and that only worked marginally with the 75Mhz antenna retracted. It didn't work at all with the antenna extended.

Suspect it isn't DC bias but 75Mhz oscillation, but can't see it without an oscilloscope. Really need shielded cables and shielded circuits for everything. Another possibility is using MAX233's to send RS232 levels. Maybe analog low pass filtering, but we don't do analog low pass filtering in this dumpy apartment.

Also, with the 75Mhz transmitter powering custom transmitter modulation and the 2.4Ghz receiver, it dies within minutes. Just not enough power in the NiCads.

Should work on inertial sensing again. Thinking about just doing AHRS in the Kalman and position using pure GPS.