So after 30 years, Wold's closed. Only went there for robot parts back when we did ground based robots. Looks like runaway rent inflation claimed its next victim. Now there don't seem 2 B any hobby shops in the tri valley area. In our runaway real estate market, it's cheaper to trade empty buildings than it is to open stores, so miles of buildings are being left empty and virtually nothing can be bought locally.

In other news, isolated a problem where a nose down pitch is appearing as a right roll on the accelerometers. It's appearing at the analog level. Looks like electrical crosstalk. The 3 accelerometers are fixed in their plastic case.

No, the accelerometers are showing good isolation and there really is a starboard roll, but it's not being subtracted from the world acceleration properly. Maybe it's the gains. No amount of tweeking can get the accelerometer to detect 0 acceleration for all orientations. The accelerometer gain seems 2 B nonlinear.

The Micromag3 continues to fail on startup. It seems to benefit from a lot of rapid power cycles before booting up.

Well one more run of PID loop hacking has made it clear: velocity sensing isn't accurate enough. The thing that got attitude hold working was accurate tilt sensing and accurate servo control. The PID constants didn't really affect much.

Now the thing that's going 2 get position hold working is accurate velocity sensing. Things are pointing to the mechanical alignment and the calibration. Without improvement in each, different acceleration directions blend into each other, she ends up endlessly chasing a fictitous motion like a dog chasing its tail, or an American chasing housing inflation.

Worst case: a static test with ground based camcorder pointing directly up to Vicacopter to detect position. This would isolate navigation errors as the problem but require that XBee for faster communication.

Mathematical alignment of IMU. Not likely to work since alignment can't be precise.

Mechanical alignment of IMU. More likely to work. Increases weight & vibration.

Better IMU calibration. She's assuming no acceleration or tilt at the moment the autopilot is engaged and using that signal as 0 acceleration + neutral tilt, but it sux. Can fix calibration in the dumpy apartment with the accelerometer perfectly upright and test with that. Can install a bubble indicator to keep the accelerometer upright when landed. Can generate center values from a flight recording and do table top tests with that. There's also interactive calibration in the field where the user orients the copter until the computer detects maximum deflections of all the accelerometers.

Static tests with just the accelerometer to see if anything is inherently wrong with it.

The motion tracking is as good as modern computers can get it. Decided to skip rotation tracking, since it would be no more accurate than it is now. The Goo tube quality is horrible. Tomorrow the master will be on http://www.vimeo.com/user226413/videos.

8/28/07 lunar eclipse (0 min 38 sec)

Stayed up all morning on Tuesday and filmed the eclipse. 910 12 bit frames were created. Unfortunately, motion tracking & color timing the frames is going 2 take several days. A single motion tracked render takes 4 hours on the fastest of today's computers. Automated motion tracking doesn't work because the brightness changes. The advantage is much higher color range than 8 bit frames. We have stills of key phases.

Looks like the ADIS16355 is a significant price cut compared to previous 6 degree of freedom IMU's. Not as cheap as strapping together IDG300's and ADXL330's, but better. With the embedded processor, they're clearly shooting for a drop-in inertial navigation system in the near future, yielding a single black box that outputs attitude & velocity, and making our last 8 months of work obsolete.

So the objective is to calculate rough velocity purely from accelerometer readings and use GPS only for position, but this produces really lousy results. The reason we're getting such bad acceleration results is the accelerometers, gyros, and airframe are not aligned exactly. Tilt, velocity, sideways and forward movement are cross talking.

The options are to build a perfectly aligned IMU or mathematically rotate the raw sensor output based on known defects. Initial results with the mathematical correction don't look good. Just can't measure the manufacturing errors precisely enough.

Tests with purely inertial velocity data seem promising. Velocity sensing is fast enough for her to start oscillating instead of banking and flying away. Velocity is being blended with 0 to keep it from escaping but the plots show long periods of sustained velocity are still being detected.

Unfortunately velocity seems to get reversed at certain points, mainly when it's small. It's either the tilt coupling with the acceleration data or crosstalk between different sensors.

Attempts to bring back the Kalman filter aren't going so well either. Seems a few unknown changes to the quaternion primitives broke the Kalman filter. The Kalman filter is being revived in the theory that all flight control can be performed on the ground. An XBee system would send sensor data to the ground, where a laptop could process it faster than any embedded CPU and send back servo commands. This loses the coveted return home in the event of communication failure feature but buys more time while waiting for faster CPU's.

After banging on position hold for a while, it seems GPS data is simply not accurate enough to hold a copter's position. When GPS data is converted to the velocity that Vicacopter needs, the error is amplified like housing inflation.

There are DGPS systems. DGPS correction data is applied to the satellite telemetry, not the position result. This data is only available on $500 beacon receivers and it can't be extracted from NMEA data. There are DGPS beacons on the internet if U have an internet connection, but they aren't as accurate in Rain Ramon. Even the best DGPS may not be accurate enough.

The alternative is to try to go by inertial navigation alone. Now scenes from today's PBS shoot. Though intended as a documentary on UAV's, what they got was mostly traditional RC flying with cameras on the airframes. The closest they got to autonomous flying involved attitude hold on both Vicacopter and a fixed wing....Continue Reading

So Vicacopter held attitude for 2 minutes with only manual throttle. Looks like Vicacopter had a serious issue with the MEMS drift and that issue is mostly solved.

Now she doesn't do very well when she first takes off. Since the center points are calibrated on the tilted ground, the level attitude when flying initially reads nonzero angles. The drift detection eventually centers the 0 angles on the true level attitude when flying, which causes single autopilot sessions to drift until the true level attitude is sensed.

The best solution is to not center the MEMS until she's flying, maybe speeding up the center point adjustment when not in autopilot. Then in autopilot mode, assume she started in the level attitude and slow down the center point adjustment. Even gravity must be adjusted constantly.

This algorithm produced our best position hold so far. She couldn't hold position, but it took longer for her to lose control. Now video of autonomous attitude + position.

Autonomous hover testing (2 min 12 sec)

The video is shown twice, once panned for Goo Tube and again scaled down to show context. There was a lot of throttle trimming after enabling autopilot, to keep her from hitting the ground, but no trimming during the video. Position hold is actually worse than attitude hold alone.

The landing is of course, manual. Everything else is under autopilot control.

So with only 1 hour of flying left before the TV shoot, most of what can be done for position hold has been done.

While going back to using accelerometer data directly in position hold, decided it would B good 2 eliminate the drift in the MEMS. They were drifting by 1m/s/s of acceleration and 8 deg/sec of rotation in a 3 minute time period. The drift couldn't be eliminated by using GPS data. Only lowpass filtering the raw acceleration values over very long periods seemed to work and this was only possible by using doubles.

Either way, accelerometer data for position hold still had no effect. So we're going to focus on attitude hold and apply the very least amount of feedback for position hold. Plots of attitude hold show what looks like stable attitude to the human eye is really pretty bad.

When lowpass filtering the accelerometers, a strange thing happened. The lower the bandwidth, the longer it takes the accel derived orientation to catch up to the gyro derived orientation. A plot of acceleration vs bandwidth showed no significant phase delay. Still working on that one.

So every day, it takes around 30 minutes to boot up GPS indoors after being powered down for 22 hours. After its internal capacitor is recharged and it's recalibrated, power cycling is very fast.

Tried the following algorithms:

specific limits for proportion, integration, and derivative feedback.

Less horizontal feedback when throttle feedback is higher.

Feedback based on a predicted future position. So far just adding current velocity to position. It's the same effect as adding derivative feedback.

None of them seemed 2 have any effect. Tried pure attitude hold again and she actually held position better than with position hold. Tried holding position the way the computer would, by slowly trimming the tabs, and couldn't do it.

Looks like the inertial navigation is just not fast enough to achieve position hold. The Kalman might be faster, but it would have to run at 200Hz to defeat aliasing. The 600Mhz Gumstix is unlikely to achieve more than 90Hz because it still has no floating point.

Only the old PC104 single board computers have enough flops to do the job. That what Neural Robotics uses. They weigh 8oz and cost $340. Imagine having to go back in time to get a better product. That's U. Know. Where.

So a number of different algorithms have been tried, with not much difference between the results.

Synthetic acceleration calculation for position -> no difference

Reduced limits on target tilt feedback -> definite improvement but limited to no wind.

Subtracting position acceleration from attitude calculation -> slight difference in attitude calculation but this calculation seems too heavily weighted on gyro data to see an effect.

New PID loop coupling servos to position -> slight improvement in position hold. This gave the first flight where she actually damped a position oscillation and held position in a slight amount of wind. It wasn't reproducible of course. Coupling servos to position seems 2 give a needed increase on response speed.

Based on attitude graphs, she seems 2 do a lousy job holding specific tilt. Directly commanding servos instead of adjusting target tilt bypasses the noisy tilt stage and seems to improve short term responses.

Still left to try:

specific limits for proportion, integration, and derivative feedback.

Parabolic and tanh instead of linear feedback.

Less horizontal feedback when throttle feedback is higher.

More yaw feedback when sideways velocity is higher.

Feedback for a certain time, then return to default tilt for a certain time to measure the result.

Feedback based on a predicted future position. The prediction is based on current tilt, velocity, acceleration, and either memorized effects of those parameters or a physics system.

The 600Mhz Gumstix seems 2 have a significant price cut from where it started several months ago. Previously in the $300 range, now at $170, it's a likely replacement for Vicacopter's 200Mhz. The 200Mhz board is unchanged and even has a smaller flash than it did last year.

Any use of the Kalman probably requires a faster CPU. Reducing the time steps in the Kalman updates is the only definitive way to smooth out the GPS and compass updates.

Another strategy is to manually feed acceleration results from GPS back into the acceration calculation that is used for attitude, to cancel out translation acceleration. We already cancel out gravity based on attitude when calculating the translation acceleration.

Now some views from Mission Peak. It's not a very exciting location because the only view is Silicon Valley....Continue Reading

In keeping with her failure rate of 1 part every 3 hours of flying, the Castle failed this time. At $108, it's the most expensive part to fail. Fortunately only the BEC failed, as expected. It was a matter of plugging in, immediately bursting into smoke and sparking. Lacking any heat sink, it was a only matter of time before that BEC failed.

Fortunately the Castle has a separate BEC to power itself and it has a heat sink. With the servos powered off the avionics board, she flies once again.

Meanwhile, further testing of the acceleration directly from world frame accelerometer values was another dead end. This reading was too correlated to tilt immediately following tilting motions. It seemed to settle very quickly and provide good world acceleration values afterwards, but the tilt correlation was too much and it didn't have GPS correcting it.

The next step is to fake acceleration from the velocity. Though still dependent on those world acceleration values, the velocity integral contains GPS feedback.

After that, may knock on the Kalman's door again. Increased knowledge about smoothing GPS readings may bring it back.
The best altitude hold is still from the Kalman. Other upgrades to the Kalman: lowpass filtering before updating the IMU. Independant bandwidth for accelerometers and gyros. Switch between Kalman filter and algebraic navigation. Sensor calibration during initialization.

So discovered inside autopilot.sourceforge.net there really was a flight controller for position hold and not just for attitude hold. It was one of the many flight controllers in the source code. They used a single PID step for attitude and a single PID step for position. No acceleration feedback or extra feedback lines from position -> servo offset.

After playing with that and getting no position hold at all, concluded the velocity readings are simply not fast enough to keep up with environmental changes. All feedback constants either didn't resist wind at all or caused exponential oscillation. It might take really really fast, accurate sensors to do the job, way beyond Invensense & Analog Devices.

Now we've kept the autopilot.sourceforge.net structure but added the acceleration terms. The position PID equation is now P + I + D + D2. Pure acceleration feedback (D2) seemed 2 give the best result but by then we were at the end of our 45 minute laptop battery.

So the neural network fans swear by neural networks and the PID fans swear by PID loops. The problem with neural networks is to take advantage of the neural network features, U need a simulator to teach them. They run an evolutionary algorithm simulating a mission over and over again. The simulator doesn't reflect the real vehicle, so they have 2 B further tweeked by hand.

With a very complicated nest of PID loops U can achieve the same result as a neural network, but in a more human readable form. Maybe tanh can be used instead of CLAMP to achieve some non linearity. Maybe Vicacopter's flight control can B written as a neural network of PID nodes.

Another alternative is using differential equations of many terms to combine some of the 3 term PID loops. PID loops could B combined in a single differential equation like c1*(Position Error Integral) + c2 *(Position Error) + c3 * (Velocity Error Integral) + c4 * (Velocity Error) + c5 * (Acceleration) = Feedback. Some inputs come from directly the INS and some come from a PID loop for target velocity.

After a 48 hour break, strong winds have returned to Rain Ramon. Adding the position error integral to the feedback for velocity error seemed to improve her resistance to wind. She entered a pitch oscillation which drifted downwind instead of a complete loss of control.

Also, the derivatives are physical data straight from the sensors, so they need 2 B subtracted from the feedback result instead of added like they were. That got us exponential oscillation instead of loss of control like before.

Next, couldn't reproduce the control losses when facing south and one PID configuration file uploaded from a great distance came out corrupted.

Finally, after a hard dead battery landing the Micromag3 failed again. Power cycling it didn't work. It only worked after returning to dumpy apartment and rebooting it. Seems 2 need a long time to rest. Don't think writing it in Java would improve matters.

So had another night with no wind of any kind. Increased the accelerometer weight to 1% from 0.5% and the attitude hold seemed to drift maybe 0.5% less.

Back in the position hold department, recall from 5/11/07 that we had altitude hold staying within 2 meters. Found the exact same constants from altitude hold are giving the best results with position hold. The algorithm is position error -> target velocity. Velocity error -> target tilt. Target tilt -> cyclic offset.

All this is requiring her to be extremely finely trimmed. There's almost no feedback.

Unfortunately, position hold is deviating by 50m. Either some improvement in the PID constants is needed or an adaptive PID loop is required. We see adaptive PID loops in other autopilot projects and that's the only evidence that they may be required.

Exactly what adaptation is needed is a mystery. Maybe the tilt should automatically be biased based on time away from target position, but the position error integral should already be doing this. Already know that feedback needs to depend on velocity, not position, from the altitude tests, but maybe the velocity feedback should be in addition to a position feedback result.

Next, she can only hold position facing North. Facing South she loses control. Definitely need to review the INS for that one, but it's not a showstopper.

The Kalman could have improved the INS results slightly, but not having to deal with sudden filter explosions has been even more beneficial.

Still with no autonomous position hold, it's time to get back to characterizing anomalies. The attitude hold tended to stop working after several attitude hold maneuvers in a single campaign. It also didn't work at all in wind. Increased the limits on the cyclic feedback and attitude hold seemed to return. Unfortunately there was no wind by that time.

To test attitude hold, we yank the cyclic to the point where she stops tilting because the autopilot is fighting. Then release the cyclic to verify she returns to the starting attitude. For the most part, it works, but repeated yanking in the same direction and the starting attitude seems to drift. The same thing happens with yaw, and more obviously.

Maybe the gyros are drifting too much and requiring more accelerometer weight. Not sure why the drift didn't show up in INS plots. Maybe didn't do enough repeated tilt in the same direction, maybe the drift was too slight, or maybe the drift was only diffused over very long time periods but during a single autopilot run was significant.

Maybe the feedback is getting just within range of the starting attitude and giving up. It could be falling below some minimum servo deflection, below which the feedback has no effect.

After some long hard transform programming and constant calibration, the position from accelerometer results is now being blended with GPS results to give faster response.

The secret is first convert acceleration in copter frame to acceleration in world frame, based on the attitude. Then remove gravity from the vertical axis. Then integrate acceleration to velocity and integrate velocity to position. It takes liberal use of discrete cosine matrices to convert between copter and world frame.

With so many integration steps, pure accelerometer derived position is completely worthess. With blended GPS results, the results were actually pretty good. The main interest with the accelerometers is the velocity measurements.

Well OK. 1Hz GPS updates aren't fast enough 2 fly a copter. With large feedback deflections, she would oscillate exponentially before hitting a very large movement that caused uncontrollable yaw followed by loss of orientation. With small feedback, she would get overtaken by the wind. It would probably work if there was no wind.

After a brief period, Rain Ramon is back to strong west wind at night. So we're back to accelerometer derived position. Dividing the accelerometer by the discrete cosine matrix of the attitude measurement should give acceleration in world frame. That would only work for brief periods, because acceleration over time becomes the attitude measurement and that points acceleration straight down.

Then it's the same trick as the attitude measurement. Blend a fraction of GPS position with accelerometer derived position 200 times a second. Only this time GPS changes once a second. Probably can get some blended velocity, but forget about blended acceleration.

Unfortunately, this isn't the most efficient algorithm. A perfect inertial navigation system feeds everything back into everything else. Accelerometer derived attitude into gyro derived attitude into accelerometer derived position back into accelerometer derived attitude.

That's probably what the Kalman did but it was too unstable, a condition of garbage being fed back instead of being thrown out.

Vicacopter finally achieved autonomous orientation hold. She can't stay in the same location but she can hold the same tilt and heading autonomously. Took a long time and a lot of money to get this far, but it was much cheaper than any commercial solution. Vicacopter can hold orientation regardless of nearby hills and doesn't require calibration before each campaign. The next step is autonomous location hold, which should B just as hard.

For location hold, we have only 1Hz updates from GPS. There may be extra data in the accelerometers to squeeze out, but it's unlikely. Would B ecstatic if She just stayed out of the trees and within sight.

Main requirements for orientation hold:

Fully functional servo PWM. No jitter or stalling.

Doubles for the inertial navigation stores.

Quaternion attitude measurement.

Integrated gyro + weighted accel data + magnetometer.

No Kalman filter. The Kalman was too unstable, used too many clockcycles, and had too many failure points.

Vicacopter does 200 IMU iterations and 30 feedback iterations/sec.

We can finally say the IDG300, ADXL330, and Micromag3 are good enough to hold orientation.

The only value in the autopilot.sourceforge.net source code was the conversion from magnetometer to heading.

The process ended up integrating the gyros into a world quaternion, inverting 2 get the copter quaternion, and converting to Eulers for the autopilot. The integral used a variation of quaternion rotation that excluded the conjugate multiplication. Could not get useful feedback with a quaternion difference. Only converting to Euler angles worked. Thanks 2 the flybar & the PG-03 yaw gyro, only the proportional terms are needed in the PID loops.