HobbyKing.com New Products Flash Sale
Jack Crossfire's blog
Archive for April, 2008
Posted by Jack Crossfire | Apr 29, 2008 @ 03:17 AM | 4,953 Views
Discovered the idler pulley can be removed. Without it, we supposedly have less vibration & energy loss. Mainly, it's one less gift from Align & the less Align gifts the better. $10 of landing gear & 1 less idler pulley later, she's flying again.

Operator directed flight (0 min 20 sec)


That was 9 min of playing around with operator directed autopilot, forward flight, & turns. Results in wind will be much worse, of course.
Posted by Jack Crossfire | Apr 27, 2008 @ 11:00 PM | 7,157 Views
So had a descent anomaly followed by a hard roll at 5ft, all under autopilot. Nothing survived that crash, not even bacteria. Observed a hard roll to port. The IMU sensed a hard roll to starboard.

G forces dropped during the descent anomaly. When G force crossed from + to -, the accelerometer result flipped 180' in a 0.04 second period, causing the blended result to show a sudden roll starboard.

How do you sanity check the accelerometer? You can't check total magnitude.

Now the stabilized footage from our last daylight mission.

Stabilized hovers (0 min 45 sec)

Posted by Jack Crossfire | Apr 27, 2008 @ 02:45 AM | 4,871 Views
Managed to get off the ground & land safely with the camera & Russian Heroine on the scene. She did autonomous hovering briefly. Unfortunately high wind seems to have killed off opportunities beyond that. More notably, the IMU seemed to get lost & couldn't return to the neutral attitude after a certain point.

All the autonomous hovers were too high to see the pilot. The only photos with pilot & Russian Heroine were manually obtained.

Finally, one of the XCite batteries was never charged, so we got only 1 flight.

One observation is that she can probably handle straight line wind but the kind of wind in this location reverses direction constantly....Continue Reading
Posted by Jack Crossfire | Apr 25, 2008 @ 05:34 AM | 6,900 Views
Well, U can look at falling prices for carrier phase GPS and say all this neural network hacking could be eliminated with money & replaced with a bulletproof system.

https://www.navtechgps.com/Shop/equi...0-4002-000.asp

That $300 board needs another $300 to do 10Hz. Last year, the Novatel was doing 20Hz for $1000. Electronics drop 1/2 their price every 2 years. We're probably 2 years away from anything coming close to replacing the neural network & only if we still care about it. 4 years away from it being economical for after-tax pilots. The neural network is going to be around for a long time.

Now IMU's R rapidly becoming ubiquitous. They'll start using 324 pixel mouse cameras to add position hold to indoor dual rotors because that's the easiest money.

What happened to VicaGlider, you wonder. Well, it became less & less a reuse of spare parts & more & more a second parallel money pit of replacement parts. The lack of open space was another killer. The T-Rex hasn't had the endless downtime waiting for parts that the Corona had. Finally, there's the day job.

The 622Mhz computer now has 177 min of flying & 133 min of autopilot, a ratio we'd expect. It hasn't reset in flight like the last one did. Suspect replacement of the power connector fixed that.

The FIR neural network started working as expected. Altitude seems a bit more stable.
Posted by Jack Crossfire | Apr 24, 2008 @ 06:54 AM | 4,899 Views
Somewhere in the testing since 11/07 the navigation went from a FIR neural network to current inputs only. The FIR method is quite hard to verify, reduces training to 4275 evolutions/sec but used to give slightly better results than current inputs only.

Gave up on plotting graphs of velocity prediction runs. Attitude hold has gotten good enough that it always defeats the predicted velocity before it happens. The only way to compare these things is to fly.

Sadly, haven't gotten the FIR implementation to work in our Rain Ramon visits. Got some more words painted using the tried & true algorithm. Vimeo has 8 hours to go on processing that one.

Well, 4/22/08 came & went & no EOS 5D Mark II appeared. Haven't used the 100mm lens much so here R some shots.
Posted by Jack Crossfire | Apr 21, 2008 @ 01:45 AM | 4,965 Views
Had exactly 1 day off since Heroine Cam arrived. Once a company begins 6 day work weeks, getting back to 5 day work weeks is a matter of either getting into a low profile project or quitting. Once acquired, the taste for winning more contracts by leveraging employee personal time rarely gets sour.

Path through 35mm (0 min 40 sec)


Flight projection through the 35mm sensor followed by projection in Google Earth....Continue Reading
Posted by Jack Crossfire | Apr 19, 2008 @ 03:04 AM | 4,912 Views
Decided to finally try a washout filter instead of a neural network. Recommended by none other than Major League Baseball himself.

The washout filter was much looser than the neural network in stable air. Maybe it could be tuned, but we're after major improvement & clearly that isn't washing out.

Got better focusing by focusing on the tail boom & setting the flash to stop down -1. It's beginning to look like an extremely narrow depth of field, very small pixels, combined with a lack of the focusing assist range we had on the 20D. The IR assist just doesn't cut it & there's no way back to flash assist. It's clearly focusing in front of the object.

Would now agree the 5D sensor is slightly less noisy at ISO 1600 than the 20D sensor.

Finally hovered out a battery. The flight time with a brand new 4.1Ah battery in ground effect is 16 min.

The day job is requiring work on weekends. It's one of those jobs where it's more tradition than necessity. We have probably only 10 hours in Rain Ramon per week now.
Posted by Jack Crossfire | Apr 18, 2008 @ 03:54 AM | 4,874 Views
Clearly the swashplate neural network has nicely decoupled the 3 swashplate axes since the long coveted single module for navigation made no difference. We're looking for significant improvements here, but all the designs seem to have milked the last bit of information out of 1 Hz GPS.

There's a slight chance adding MEMS acceleration to the 3 module network improved its altitude hold. More evolutions to grind than the 1 module network.

Would be nice if the software could automatically throttle the evolutions to hit an exact CPU load. It's the times it gets it wrong that we're worried about.

1 module, 30 sec history
----------------------------
current GPS acceleration
commanded tilt
|
\/
predicted GPS acceleration

same as 3 modules




3 module, 30 sec history
----------------------------
current GPS acceleration
current MEMS acceleration
commanded tilt
|
\/
predicted GPS acceleration

Same as without MEMS.
Significant oscillation during training.
Possibly better altitude hold.





3 module, 60 sec history
----------------------------
current GPS acceleration
commanded tilt
|
\/
predicted GPS acceleration

Same as 30 sec.
Longer training time.

So much for that....Continue Reading
Posted by Jack Crossfire | Apr 17, 2008 @ 01:05 PM | 5,082 Views
Got lucky with the crash damage. Only $25 & 5 hours of repairs. Remarkably, the main shaft didn't bend. Got the computer running again. The tiny hirose connector was predicted to break in it's first opportunity, & it did. Now we know where to pad the computer.

Got the serial port reading SiRF binary, 9600 baud, & low latency, thanks to Canadia. U need to set c_cc[VMIN] to 1 & c_cc[VTIME] to 1. Now we know the binary protocol gives much more accurate readings than NMEA.

Discovered if U have multiple BEC's, only connect 1 of the ground lines. Reversing the polarity of the computer tap causes a short circuit between +12V from the ground & +6V from the BEC. That's what melted a wire http://www.rcgroups.com/forums/showthread.php?t=812551 before. Now the remaining unmelted RCE-BL35X wires are 6V & PWM. The computer's diode protects the +12V line but not the ground.

The answer is yes, using SiRF binary protocol gives much more accurate readings than NMEA. Got good results using the 3 module network. The 1 module network was disappointing. Still have more combinations to try before declaring the 622Mhz a waste of money.

Web 2.0 is getting back to full power after a few months of mass layoffs, & lots of middle managers R getting promoted. The bigger the manager, the smaller the car. Spending almost all day in traffic. Monster accidents shut down the freeway all morning. More accidents stopped traffic all night. Only getting...Continue Reading
Posted by Jack Crossfire | Apr 16, 2008 @ 03:38 AM | 5,272 Views
After the Jesus camera arrived, wanted to get some autonomous flight photographed at any cost. Reverted the neural network to the 200Mhz configuration. Reverted GPS to NMEA, but managed to get it up to 9600 baud. Autonomous hover locked in again.

NMEA works because the linefeeds flush the buffer. Clearly the non canonical mode is broken on ttyS1.

She was losing altitude erratically but a small turn was stable. In our excitement, hit engine kill instead of autopilot kill. Attempt to restart followed by crash followed by computer crash followed by thrash followed by PIC shutdown.

The Corona would have been a matter of straightening aluminum. The T-Rex is offline until May for probably $50. Computer boots but no longer detects console input.

The flash had plenty of power, but the EOS 5D simply couldn't focus sharply. Worked around it by stopping down....Continue Reading
Posted by Jack Crossfire | Apr 14, 2008 @ 02:50 AM | 5,419 Views
So ttyS0 on the Verdex has a strong pullup resistor for its input. Contrary to many a Google link praising voltage dividers for 5V sources, the solution here is a diode pointing towards the 5V source. ttyS1 & ttyS2 have no pullup resistors. Those need voltage dividers.

With all the tty's getting 3.3V input, ttyS1 began working. Once again, spent a day banging on a CR/LF to LF issue. IGNCR was the offending bit.

Consistently dropping 1-2 bytes right before the end of the packet, diode on the ground line making no difference, requests to resend give the same erroneous packet all point to those translation bits.

Anything over 4800 baud doesn't go through ttyS1 at all anymore. Looks like that 2.8V GPS output level. It's minor enough to not justify banging on it, but keep it in mind before U Gumstix fans punch up Add to Cart.

There are many compiler options to get faster math & more neural network evolutions. Unfortunately, the other half of the autopilot is the inertial navigation. That requires very compliant trig & floating point.

As for the new power connector, it didn't change anything. Too many other boards use 0.1" pin spacing for power to use anything but an adaptor with 0.1" pin spacing on VicaCopter.

Strong winds during the next 7 days will keep us focused on The Jesus Cam instead of flying.

We have 2 movies of Mars weather from MRO.

Mars weather satellite 2 (0 min 23 sec)


Mars weather satellite (0 min 24 sec)


The annoying rotating globe from http://www.msss.com/ is held on a single longitude & time compressed on Cinelerra. Time compositing fills in gaps in telemetry.

Now the average speed of a UPS truck, assuming it drives in 12 hour shifts:

April 13, 2008 11:30:00 AM SAN PABLO CA US Arrival Scan
April 10, 2008 10:00:00 AM HODGKINS IL US Departure Scan

1827 miles / 12 hours / 3 shifts = 51mph
Posted by Jack Crossfire | Apr 12, 2008 @ 06:37 AM | 5,031 Views
After banging on it for a day, found the BTUART received data from itself & received data from a PC. The PC could receive data from GPS & from the BTUART, but the BTUART couldn't receive data from GPS. The Verdex UARTS have a slightly higher switching voltage than they did on the Basix. The EM406 UART only goes to 2.8V.

The workaround is to raise GPS ground using diodes until the switching voltage is high enough. This gets 50% of the data through. Need a comparator.

In rough tests, the PXA270 622Mhz does 4x more neural network iterations than the PXA255 200Mhz using the old 3 module network. Not the 20x that http://docwiki.gumstix.org/Benchmarks led us to believe. Below 2500 iterations/sec, the CPU usage is 1%. Between 2500 & 10,000 iterations/sec, the CPU usage jumps 25% for every 2500 iterations/sec.

What seems 2 B happening is once the back propagation errors get below a certain point, the FPU starts grinding away very slowly. Observed it before with very long reverb tails.

With a 1 module network specificially written for the PXA270, the limit is 3000 iterations/sec.

Can't compare the new network since the PXA255 was destroyed.
Posted by Jack Crossfire | Apr 11, 2008 @ 12:36 PM | 5,181 Views
More Gumstix workarounds

Just make the /usr/share/sources directory instead of adding a group or changing permissions.

source gumstix-oe/extras/profile instead of adding it to bashrc.

unset LFLAGS

When libc complains about trying to run ./configure after already being configured, comment out those tests in the configure scripts.

When bit baker complains about trying to install libraries which have already been installed, erase the previously installed libraries.

When bit baker complains about compiling as root, comment all the lines in the sanity.conf file.

Code:
Dependancy error:          Google search:
-----------------------------------------
sqlite3                    sqlite
pysqlite2                  pysqlite
Locale::gettext            Locale::gettext
help2man                   help2man
The odometer was lost with the last Gumstix. It was around 17 hours. Most of that was autonomous, giving us at least 10 hours of pure autopilot. Need to add a line for autopilot time.


The firmware runs on the new computer. Sending to GPS works. Receiving from GPS doesn't work. Gumstix remapped the serial ports & yet more software magic is required to get receive to work.

So obviously no flying for yet another week.
Posted by Jack Crossfire | Apr 10, 2008 @ 03:23 AM | 4,849 Views
Well, the $190 beast arrived, but building the SDK is now a several commute affair instead of a few hours. In the mean time,


Code:
root@gumstix-custom-verdex:~$ df                                                
Filesystem           1k-blocks      Used Available Use% Mounted on              
/dev/mtdblock1           31488     10324     21164  33% /                       
/dev/mtdblock1           31488     10324     21164  33% /dev/.static/dev        
tmpfs                     2048        24      2024   1% /dev                    
tmpfs                    63952        56     63896   0% /var/volatile           
tmpfs                    63952         0     63952   0% /media/ram  
            
root@gumstix-custom-verdex:~$ free           
              total         used         free       shared      buffers         
  Mem:       127908        15456       112452            0            0         
 Swap:            0            0            0                                   
Total:       127908        15456       112452   
                                
root@gumstix-custom-verdex:~$ cat /proc/cpuinfo                                 
Processor       : XScale-PXA270 rev 7 (v5l)                                     
BogoMIPS        : 622.59                                                        
Features        : swp half thumb fastmult edsp iwmmxt                           
CPU implementer : 0x69
...Continue Reading
Posted by Jack Crossfire | Apr 09, 2008 @ 02:52 AM | 5,162 Views
New tail boom, new drive belt, new main shaft, new main blades, new main gear, new tail rotor shaft, & IMU realignment later, finally finished the mecha. Only computer installation, neural network profiling, blade tracking, gear lubrication & we'll be out of things to do without flying.
Posted by Jack Crossfire | Apr 08, 2008 @ 04:04 AM | 4,574 Views
April:
Power plug: 7.04
Crash repairs: 47.36
Gumstix: 190.31
----------------------
$244.71 so far



March:
Batteries: 146.97
Blades: 17.35
More blades, servo: 109.73
Screws: 9.62
Sonar: 28.25
--------------------
$311.92

Was hoping the flying costs would go down as we moved away from the T-Rex build. Saturday's crash was only $47.36 so far, cheap by T-Rex standards. The killer was the Gumstix incident. When accidents like that happen, U just eat the cost quietly.
Posted by Jack Crossfire | Apr 07, 2008 @ 02:14 AM | 4,540 Views
Payloads:
Alkaline batteries: 60g
3.3Ah: 260g


BEC power rig: 20g
4.1Ah: 324g

Well, built a camera power rig & got the 4.1Ah battery payload down to only 0.85oz over the weight of a 3.3Ah battery payload + alkaline batteries. Have no tests in flight conditions until the new computer arrives.

Found another anomaly in the navigation neural network. It was feeding current GPS in and using the same current GPS as output for training. With a well tuned autopilot, U can't tell if the neural network is accurately predicting velocity without flying because the predicted velocity feeds back into the future velocity.
Posted by Jack Crossfire | Apr 06, 2008 @ 02:52 AM | 4,333 Views
Well, tried to photograph love making with Russian Heroine from VicaCopter on autopilot. Had a tail rotor failure straight away. 1 tail boom destroyed. Next, began the rework to power the camera off the Castle BEC. Accidentally plugged the camera shutter into +14V. Fried the Gumstix & the PIC.

The good news is we'll upgrade to a 600Mhz computer & have a more generic neural network for navigation.

Now the last notes on turning.

Well, the way turning works is U have a copter equilibrium tilt which produces 0 acceleration in an environment of no wind. That one is hard coded & relative to the IMU. U have a world equilibrium tilt which produces 0 acceleration in the current wind & it's relative to the world. That one is constantly updated by converting copter equilibrium to world frame & subtracting it from the current velocity feedback tilt in world frame.

The world equilibrium is translated to copter frame & added to the copter equilibrium to get the target for attitude hold. This way the force we exert against the wind always stays relative to the wind as the heading changes.

The problem is wind hitting the tail rotor & fuselage from different angles changes the world equilibrium. The hard coded copter equilibrium changes based on payload. It really is a kludge we avoided for a long time.

Interpolated Timelapse montage (4 min 55 sec)


A compilation of our still photo movies during hovering. This uses interpolated motion & it really is the pinnacle of stabilization.