The ETH video demonstrating a new algorithm to save a quadcopter after a single motor or prop failure didn’t reveal the algorithm. It did get me thinking about the quadcopter dynamics after a motor or prop failure.  My analysis starts with the model above, and the equations in “Quadrotor Dynamics and Control” by Randal W. Beard, Brigham Young University, February 19, 2008, available at

http://image.ednchina.com/GROUP/uploadfile/201304/20130429210226589.pdf

The PDF attachment to this blog post shows why spinning up the body axis yaw rate after a motor or prop failure helps with quadcopter controllability, and points to potential new control laws that use controlled body axis yaw rate to allow cross-coupling between pitch and roll control.  My next step is to try to work out a specific, simple motor or prop loss recovery algorithm. I haven't taken it that far yet, but there are a lot of sharp, creative and inventive people in this community. If it looks like this is on the right track, let's see what we can do with it.

I wrote up the analysis in Word 2010 and its useful equation editor. I then discovered that it's not easy to copy and paste those results into my blog! I looked at converting everything over to JPEGs to paste it up as images, but the resolutions on some of the equations suffered. The best way to share the results is  to convert it to a PDF document, the attached file.  I look forward to your peer review - maybe I made a mistake or overlooked something.

Blog%20Quad%20John%20Malley%20%20February%209%202014%20Post%20on%20Spinning%20Quads.pdf

John

Planetary Resources launched a Kickstarter project to fund a first-of-its-kind public "Hubble Space Telescope."

http://www.kickstarter.com/projects/1458134548/arkyd-a-space-telescope-for-everyone-0

From their project site, "The proceeds from this campaign will go to several different areas: 1) To actually launch the satellite into space. 2) To support the spacecraft over its lifetime — including manpower to facilitate the photos, "selfies", monitoring the spacecraft and training the staff at the chosen science center that will take over control. 3) To create an easy-to-use Control Interface that will allow ANYONE to access and control the satellite. 4) To fund the creation of an incredible, interactive educational experience that can be used by schools anywhere, to enable students to experience space in a way that's never been possible."

A public space telescope shares analogous challenges with Unmanned Aircraft Systems - command and control issues, communications issues (including security), mission planning for user sessions, data collection and ground processing, user interface issues - and introduces possible new issues with solutions applicable to down-to-Earth UAS projects, such as error-free methods for control and data collection handoff between user teams, and distributed sessions management with the same vehicle but from different sites (different users controlling the scope from different sites, via the Internet, one at a time or maybe even in parallel?) 

  There may be opportunities for the DIY Drones community to apply its hands-on experience and lessons learned to a public space telescope operated over the Internet.

The Skagit River bridge collapse on Interstate 5 in Washington State, USA, got me thinking about using the Arducopter for large, inaccessible infrastructure inspections. I drove my family across this bridge many times so I took its unanticipated collapse harder than most who heard the news in far away places. Granted, metal fatigue or corrosion didn't directly lead to the collapse. Current data (witnesses and surveillance camera footage) point to repeated collisions between a large truck-ferried load and the overhead bridge structure as the truck passed through that section of bridge. But the bridge dates from the 1950s and didn't include redundant load-bearing paths. It's classified as a  "fracture critical" bridge. There are more "fracture critical" bridges in the USA and we don't necessarily know their structural health in detail.

The quadcopter platform appears well suited for bridge inspections from beneath or above the bridge deck. I figure it needs to stay in line of sight of an operator's RC controller, needs to provide video on-screen display so the operator sees what the drone sees, and some level of "standoff protection" to keep the quad from striking the bridge structure. The bridge is more dangerous to the quad than the quad is to the bridge. Maybe ultrasonic ranging for structure following or standoff might do the trick. The quadcopter must keep its distance from the structure while under control of the operator, though. I lean toward a "hard envelop limiter" in the control law or control mode software so the quad won't hit the inspected item no matter what the operator commands ( or a variable limiter that requires a lot of operator override to get the quad closer, that's more in keeping with my Boeing bias.)

The quad blades may require a perimeter shield round the blades to keep them from contacting bridge structure, too. Just in case a wind gust shove the "airbot" inspector too close to the structure.

Protecting the quadcopter from inadvertent structure contact is an interesting problem in itself. It seem tractable on the surface. The greater challenge is remote sensing of the structure. What kind of sensors can a quad carry near to a structure to probe its integrity? Is it limited to passive sensing (optical) or active sensing (induction from a distance, or via a probe, to measure structure response, or sampling (wow, take a flake), or ultrasound? We can learn a lot by dumping some energy into the structure and measuring its response, in addition to watching it in parts of the visual spectrum.

Remote sensing satellites solved a lot of these problems. They may offer direct of indirect advice on the sensor approach.  Satellite sensors can measure  the reflected light spectrum from soils, plants, rocks, for example. Making sense of the spectra requires "ground truth" measurements. The spectra need to be calibrate to soil or plant conditions and mineral types.

But paint can mask rust. And fatigue cracks may not show at the structure surface. If this is the case, then energy needs to be directed into the structure, from the quad, and it's effects need to be measured, by the quad. The wikipedia entry on non-destructive metal testing lists some interesting methods that could (in theory) be adapted to a quad - such as magnetic particle testing, liquid penetrate testing, and methods that require some form of physical contact during the measurement, like eddy current testing, ultrasound testing.

Physical contact testing would be a challenge in that the quad need to station keep, not hit the structure, and simultaneously extend one or more devices to make contact with the structure during the test. Is that a great controls problem or what?  And more - the quad measurement device needs energy (battery) and that's weight. The quad itself needs energy from a battery to fly for a while - 10 minutes or so. This may be the biggest challenge to quad copters that actively probe structures. The energy need to fly and actively probe the structure must be provided by batteries. It may be a difficult optimization to allow a reasonable inspection and reasonable mission time.

Passive structure observation seems like a shoe-in with a quad and one or more cameras, with respect to passively probing the structure and mission time. A quad can take close-up video and pictures of structures illuminated from beyond the quad by the operator. That can address the battery issue - if the operator can use a different device to illuminate the structure with ultraviolet or infrared or laser, and the quad can measure the reflected result, then the "active probe" is not on the quad, doesn't need to be lifted and doesn't need to be powered by the quad. 

But the kinds of light we can shine on the subject may not illuminate all possible defects we want to detect.

Overall an interesting set of engineering problems, when we think about using a quad copter to inspect structures...

Summary: Takeoff from a foam pad on top of dry grass/lumpy lawn alleviated instabilities experienced when taking off from the dry grass/lumpy lawn.  No gain changes made to the 3DR ArduCopter code, using the "factory" settings for Stabilizer and Acrobatic modes.

Details

Started basic flight testing of a ready-to-fly 3DR ArduCopter-B with APM 2.0, in cross-configuration, under R/C control at first (and a ground station with XBee or 3DR radio telemetry with an EEE PC laptop as the ground station to follow in the near future.) The drone's designation is PeeDee 2.

(PeeDee 1 is another story, an earlier ready-to-fly arducopter from Udrones that's now sitting in the metaphorical hanger. The APM board does not command all four motors, the multiplexer chip appears to be failed and in need of replacement. PeeDee 1 is scavenged for parts as needed.)

Installed a 7 channel Futuba R617FS receiver. It's hard to secure under the cap of the stack-up plates above the APM 2.0 module because of the connectors to the APM 2.0 inputs connect normal/perpendicular to the receiver. Cramming it all under the topmost stack-up plate bends and stresses the connectors - an invitation to future trouble.  The receiver is therefore stuck and held in-place between the topmost stack plates with double-stick tape, and with receiver antennae routed out of the stack ninety degrees to each other to help hold the receiver in place.  May move to velcro to hold the receiver to the stack plate in the near future. (The receiver is visible in the photo.)

PeeDee 2 ground testing took a couple of calendar days. Used the Arducopter Wiki as the ground test plan:

1. Calibrated radio channels with LIPO disconnected.

2. Automatic ESC calibration

3. Motor direction and connections check with CLI mode and Motor command. Watched the paper labels on the motors to gauge the direction of motor rotation.
4. Re-leveled sensors and adjusted magnetic declination before Sensor checking. Used the Configuration page in APM Mission Planner 1.2.10 with mavlink 1.0.

5. Sensor checking - used APM Mission Planner 1.2.10 with mavlink 1.0, watched Flight Data page graphics update when PeeDee 2 pitched, rolled and yawed by hand. Also, lateral, vertical and longitudinal displacements, looked at the raw data on the screen. All ok. (did re-level PeeDee 2 using the Configuration page before sensor checking.)

6. Finally, attached the props, careful to check prop type with motor location in the cross configuration.

Initial ground test on dry grass (Seattle area rain free for 40+ days.) After GPS lock indication (blue light on top), ran engines up to point where PeeDee 2 started to lift off, but not lifting off, then throttle back down. Props stayed on. Did this several times to look for any vibrations of unusual activity. Ran engines up, and close to takeoff point, pitched the drone up and down, one pair of legs in contact with ground while other pair lifted (front/back). The rolled the drone left and right, one pair of legs making contact with ground while other pair lifted (left/right). Looked ok to try a takeoff, but winds picked up to 5 mph with gusts up to 8 mph. Waited for gusts to die down before every takeoff attempt.
Takeoffs in stabilizer mode immediately rolled to one or the other side with the drone crashing bottom up. One prop broke. Replaced the broken prop. Again, on the next takeoff, PeeDee 2 immediately rolled over and crashed. A prop popped off, put it back on. Tried one more time to take off. The prop that previously popped off now broke apart into three pieces on engine run-up. Didn't see the crack in it when putting it back on. (Lesson learned - now check all props for cracks, and check props for tightness, after every landing.)

Local hobby store carries 10 by 4.7 props, secured new props and replaced all four. Followed the troubleshooting guidance in the wiki,

"Arducopter tilts/flips over or wobbles crazily when I try to take off."

Discovered a configuration error - had the drone set to plus configuration when it's in the cross-configuration. Fixed the configuration on the Configuration page on Mission Planner with mavlink connection to PeeDee 2.

Repeated the ground test plan - run engines up to liftoff, check pitch, roll, and it all passed. Prepared to take off in acrobatic mode. On every takeoff in acrobatic mode, one or two of the drone's legs appeared to get stuck in the grass and the drone tumbled over. Tried several takeoffs in Stabilizer mode, and again, one or two legs appeared to get stuck in the grass, and the drone would flip or tumble.

Went to a local fabric store and bought a 0.5 meter by 0.5 meter by 2 cm thick piece of foam pad. Put the pad on top of the grass, and Pee Dee 2 on top of the foam pad.

Presto! PeeDee 2 took off reasonably well off the foam pad, every time, in acrobatic or stabilizer mode. When lifting off in acrobatic mode, switched as soon as possible to stabilizer mode. Finally settled on takeoff in stabilizer mode, off the foam launch pad. It's very stable in pitch, roll as it takes off that way.

The throttle response is interesting, though. It takes "extra" throttle to leap up off the foam launch pad, but once above the pad, throttle needs to be reduced in order to keep below two meters above the pad. Otherwise, the throttle required to "break free" from the launch pad is enough to send the drone up a good two meters quickly (a pop up.) This looks like a ground effect interaction with the foam pad.

Takeoff from the foam pad rather than from dry grass on lumpy lawns did alleviate the instabilities at takeoff. No gain changes made, PeeDee 2 is using the "factory" settings for stabilizer and acrobatic modes.