After gaining confidence in 3.0 (RC5) during the AVC in Boulder, I decided to try some longer flights. Golden gate park is one of my favorite places to fly and one of the few areas of San Francisco where the city isn't overrun by housing. So I decide to run a 3 mile cross-country flight from one end of the park to the other to perhaps be the first to do so completely autonomously (that I know of.) 

I picked out two fields at either end and used Google Earth to generate my waypoints by exporting a KML and editing the path in BBEdit (OSX text editor.) I choose this route because I wanted to ensure my altitudes were following the 54m incline from the coast to the landing zone and all of the hills (up to 70m) in between. I also went to the fields and measured the altitude error in Google which turned out to be about 20m in highest point and the trees which were 30m in some places. 

Next I realized I needed a chase car so I enlisted the help of Wolfgang Kandek, his son & Jeff Vyduna (flight 1) and Tad Whitaker & John Bertrand (flight 2). For safety we choose to fly around 8:00am Sunday morning when the roads were closed and very few people were in the park. We followed the copter along MLK and watched it via FPV and telemetry which easily stayed connected the entire flight. 

The first flight unfortunately had a motor wire failure and fell from the sky. The vibrations from probably 50 flights had work hardened one of the solder joint between the ESC and a motor wire. A better flight check would have caught the issue. Luckily It fell harmlessly in a bush and not in a tree or street. 

The second flight after minor repairs went off perfectly. The copter took off and stayed to about 50m above the ground the whole time. The mission was set to fly 13m/s or about 30mph. A 3s 3300mah NanoTech battery easily made the trip in under 8min including the takeoff and landing. I could have traveled at least a mile farther with the excess flight time.

The accuracy of the flight path is stunning and a testament to the new inertial system developed by Randy and the Arducopter team. Looking at the path in Google earth, I can see cm accuracy in XY. Amazing! Also the transition between waypoints has a nice flow. The Yaw transition however was not very good. It's quite sudden and jerky between waypoints. I am considering a patch to use acceleration and deceleration of Yaw to give a smoother feel for the GoPro camera.

Here is the full path:

The landing zone:

Smooth WP transitions:

The KML file:

Full%20Run.kml

And the video of the second run (sorry about the Fog!)

https://vimeo.com/70294783

I flew AC 3.0 (rc5) at Sparkfun which required me to rethink my vibration dampening strategy. In other words I had to go from no strategy to something very robust. If you want to fly 3.0 in any AP mode you'll need to consider at least some of these methods. Once upgraded, my copter was able to hold a 1 foot loiter box with the crappiest RCTimer props/motors they sell without issue.

Here was my shopping list:

http://www.rangevideo.com/accessories/vibration-mount.html

http://hobbyking.com/hobbyking/store/__8999__peel_n_stick_foam_tape_10x5inch_4mm_thick.html

http://hobbyking.com/hobbyking/store/__26457__Anti_Vibration_foam_Orange_Latex_190mm_x_140mm_x_6mm.html

http://store.3drobotics.com/products/m3-vibration-damper

I attached the latex foam to the vibration mount with super glue which worked nicely. Adding the dollar coins with super glue under the floating vibration mount also worked well.

Even with motors vibrating so much that they looked burry, it still held a great loiter. 

Jason

Image: 1st Run

AVC was great fun and even though I went for broke on the last run and lost my copter, it was well worth it. I learned a lot about copter navigation. The latest code includes all of the updates, which is being tested now by Jack Dunkle.

Run 1 went really well. In turn 1 you can see the copter overshot the waypoint. Crosstrack error pulled the copter back to the desired path and kept it from being blown into the building from the high winds. The sonar altitude hold was working really well. Later the wind would pick up and make the copter go higher than sonar, which made it susceptible to an altitude hold bug. More on that later...

Each waypoint was hit perfectly, even though the copter tended to go too fast (17mph) and overshoot. At Turn 4 the copter buzzed the crowd at about 6 feet. Thankfully everyone ducked. Then the copter went to position hold for 4 seconds to settle down before going to land. Unfortunately this area was really windy and the copter was blown towards a tree. I had to abort by popping the copter up by 50 feet. 

At that point I thought I would try and finish the mission by landing in Auto. Unfortunately, I had set the mission to reset on entering Auto. It began to re-fly the mission at about 100ft now. It hit turn 1, then a gust of wind grabbed it on the way to turn 2. That wind was 50MPH. 

I was able to recover the copter this time. But the next two runs were not so lucky.

Run 2 went bad quickly. The wind shifted and lifted the copter above sonar range almost immediately. The baro alt hold bug kept it from coming back down properly. The wind above the building was gusty and blew the copter to the front of the building. Then a loose battery fell out of the copter... Because the motors were now free spinning, it auto_rotated to an upright landing from > 100 ft. The landing gear - plastic heli skids were partially broken, but it was otherwise in perfect shape. I should've taken the hint and called it a day, but run three was my last chance to finish.

Run 3:

It looked identical to run 2, except the copter kept climbing and the high winds just swept it away.

Anyway, much learned and code updated. I am trying a rate limited version of waypoint navigation. The idea is that the copter will want to travel at a certain speed towards the waypoint. This enables it to fight high winds by flying steep angles. It will also make overruns more predictable. 

Once these new updates are tested, I'll open up the code to a public beta.

Jason

Some photos posted by Mark Grennen:

Love this one:

UPDATE:

I actually recovered the lost copter when I returned to Sparkfun this year to compete. It somehow found it's way back to me, thankfully.

The flight was doomed form the start. Once it cleared the buildings it was swept away by 50-60 mph winds. I clocked it with the GPS going up to 69mph at one point. Here's the recovered data log plotted in Google Earth.

This was very early software that was literally more bugs than good code. In fact, the morning of the race was the first time it ever flew autonomously. We've come a long way thanks to Tridge and Randy and others, not to mention the Flash SIM I built to develop the current flight management system. Looking back at this flight I'm amazed it actually worked at all.

If you've not flown the latest 2.7.3 you're in for a treat.

Jason

I've been wanting to build a balance bot for ages and I finally have to time to make one. ArduBalance leverages the existing code base of ArduCopter to produce a simple autonomous balancing robot. Features include:

• GPS, opt_flow, and dead-reckoning

• Ardupilot mission scripting

• Full RC control

• Heading hold

• Position hold

• Stabilization, RTL, AUTO, GUIDED, FBW modes

• Mavlink 1.0 support

• APM1 and APM2 support

I'm still in the very early stages of development (this video is literally the first RC controlled run), but most of the feature have been ported from ArduCopter already. This project is closed source for now until development settles down.

The current version is an inverted foam core T, but this will evolve to something much more interesting.

Jason

A while back Jose Julio built a simple state machine for doing copter flips. I integrated it into AC 2.x a long time ago but never flew it. Then, once I built the Flash simulator I could finally test it without doing too much damage or loosing my quad to a fly away.

The original code was quick and dirty which lead to a few issues, one of which was a tendency to turn the my quad into an air to ground missile. The new code which is in 2.7 added a few items:

• an emergency exit from the state machine (roll or pitch hard to exit)
• a rate controlled loop rather than a using momentum for the second half of the roll

The state machine takes control of the throttle, roll and pitch until the flip is complete. It breaks up the flip into 4 main steps

1. Gain altitude - up the throttle for 1 second
2. Roll hard until we go past 90°
3. Maintain 400°/s roll until we are 90° from level
4. Stabilize with a desired angle of 0° for a nice controlled return to level

The mode is enabled by setting the CH 7 option to Flip. Bringing CH 7 high while flying any mode will trigger the flip, but you must be armed and flying to get the flip code to trigger. You must return CH 7 low, then high again to reset the state machine and do another flip.

Jason

This is a quick update for the Arducopter SIM and 2.6.1 development:

There is quite a bit of development going on right now, but I thought I'd share what I'm working on. I'm using Flash to implement a simulator and test Arducopter code. What's on my site at jasonshort.com is on the current Trunk. 

What isn't there is a whole lot of other work including Tridge's DCM core updates and Andreas' APM_limits code which is a geo-fencing library. 

You'll notice the sim has been updated to work in 3D now, so you can fly full missions, Yaw and Loiter in 3D. An orange line now indicates nav_yaw which is the yaw hold angle. A black circle indicates the GPS positions and the red box is the next waypoint location.

A new crosstrack algorithm:

Based on our flights in high winds at the Copter Rodeo, I set out to improve our crosstrack error correction. We had previously been using Arduplanes' track correction which turns the plane into the error to correct it. Of course copters can fly sideways and don't need to give up forward momentum to track correctly. The new algorithm solves this and acts very similar to the loiter control. Crosstrack gain will be lowered to a default of .2 because of new approach.

GPS lead filter:

Another idea from the rodeo, the lead filter takes into account the velocity and acceleration of the copter and the latency of the GPS to guess where the copter really is, not just where it was 1 second ago. This helps Loiter somewhat, but where it really shines is the Waypoint and RTL navigation. When you hit the WP it acts immediately, and not 1 second later which helps reduce overshoot.

Altitude hedging:

Phillip Jones suggested prioritizing the altitude over navigation when fighting wind to prevent the quad from loosing altitude during a hard pitch. This keeps the quad from hitting the ground during WP flight. Anything greater than a 1m error begins to level out nav_pitch to gain altitude. Still a WIP and not on the trunk yet.

RTL:

RTL_altitude is now implemented. This will cause the copter to rise to the desired altitude in Loiter before heading home. The parameter rtl_approach_alt will change how the copter will land after RTL or a mission that doesn't end in a land command. Basically setting this param to 0 will cause a land, setting this to any other number will cause the copter to go to that altitude after RTLing. The param auto_land_timeout is used to trigger this altitude change. The RTL Approach altitude parameter is great for bringing the copter down without worrying about touching the ground.

Alternate Yaw control:

A new control method for Yaw goes back to the hybrid rate/stabilzie approach, but uses a timer to lock in the hold angle. This allows the rate controller to brake the Yaw and then set the new hold angle without much overshoot and dreaded snapback.

Better Yaw gains:

Testing the SIM with an out of alignment motor allowed me to test various I term settings. An iterm of .02 for BOTH Rate and Stabilize Yaw works best.

Discovered Yaw Bias issue:

While running missions in the sim I realized the copter would run off track while Yawing to the target. Turns out we change and update Yaw continuously, but the copter's nav_roll and nav_pitch is only updated 4x with GPS reads. This causes the copter to be pitching at at angle to the target instead of towards the target when Yawing. The nav_roll and nav_pitch are now updated at 50 hz instead of 4 which get's rid of most of the issues.

Self centering throttle:

This is very experimental, and probably won't be enabled by default. The throttle cruise value is calculated at all times, and the lower limit of throttle is raised to place that cruise value right at mid stick. 

Drag/velocity estimation:

Takes the desired velocity and outputs a pitch and roll that should match the drag of the copter. This lets the I-terms deal with just the wind and not the wind + drag combined. It also helps the track accuracy by about 30%.

Alt Hold:

"Angle boost" a more accurate algorithm in 2.6, but we found it didn't account for the inefficiency of the thrust pattern. A small correction has been added to account for this.

Throttle min and max 

Implemented the params for throttle min and max so you can change them from the MP.

What's new with the SIM:

Added new top view

Added 3D physics

Added the ability to run the SIM at up to 10x speed for running variations

Added a Score for integrating crosstrack error to use for gradient descent (machine learning)

Added a new joystick controller class that acts like a real radio, or allows user to adjust 1 axis only.

Added 2D wind

Added Yaw Gains

Added iteration # limit to stop the sim after N number of 100hz main loops.

What's next in the SIM:

Mission editor

If you are testing the trunk, please check the SIM and see if you can reproduce bugs. If not, please note that in bug reports.

Code is here:

http://code.google.com/p/ardusim/

Flash FLA project file available by request.

Jason

Video from WIP last week.

I just wanted to let everyone know I've pushed an update to the SIM. What's new:

Upped iteration limit so it will run indefinitely. 

Stand alone executables for Mac and Windows.

A new "lead" filter to remove GPS latency leading to improved accuracy in AUTO modes and loiter.(coming to main code soon.)

Inertia nav - you must up the rate_P gains by 3x to 4x to see a difference.

Added Sonar.

Lot's of under the hood enhancements.

Arducopter Sim still lives at http://www.jasonshort.com/

I built the AC SIm to do gain tuning and now AB testing of various control algorithms. I've made some significant strides in the control loops, so I though I would detail out how it was done.

There is very little code left over from AC 1 in the current code base. When I started AC 2, I used the v1 control loops and assumed they were good. (Everyone was very happy at the time with them.) I also had no real way to measure the performance of them.

A few months ago I started to get very suspicious that the old carryover code was causing a lot of the flight headaches I've been experiencing such as aggressive flight leading to a flip. Or slow, wobbly response in descents. Max was complaining that AC2 lacked "wings". That's not a lot to go on, but it is real feedback that something needed done.

I built the SIM specifically to tackle this type of problem and here is how it was used:

In the SIM a parameter was created called g.test. A checkbox toggles the value of this param and the boolean value is used to turn on or off chunks of code. This gives me a side-by-side comparison of the impact.

Suspect code:

Attitude.pde: get_stabilize_roll() and get_stabilize_pitch();

// limit the error we're feeding to the PID

target_angle            = constrain(target_angle, -2500, 2500);

This line limits the desired rates sent to the rate loop.  A before and after plot shows the performance gain when this line of code is disabled. The Initial state of the copter was roll left at 450° per second. The plot shows the roll angle going to -85°, then recover to 0. Removing that line improve the recovery time from 1.15s to .75s

Suspect code 2:

This is the quad suddenly rotating at 600°/s to the right.

I've increased the roll output limit  in rate_roll and you can see the recovery time to level has decreased  35% to .8 seconds to level from 1.24 seconds. The angle error significantly decreased as well.

 

Patch 3:

There is an iterm in the stabilization code that causes the copter to level out when the CG is off or a motor is out of balance. The problem is the iterm can drift around when flying because drag or a low CG can prevent a copter from holding an steep angle and cause us to be 1-2° off when going back to level. We only want this term to hold level, so I placed a limit on the iterm like this:

if(abs(ahrs.roll_sensor) < 500){

    angle_error  = constrain(angle_error, -500, 500);

    i_stab  = g.pi_stabilize_roll.get_i(angle_error, G_Dt);

}else{

    i_stab  = g.pi_stabilize_roll.get_integrator();

}

Here is the effect plotted on a copter that has a 3° lean to the right. The iterm ramps to 3°, but it moves a lot when flying around.

Here is the patched code:

Notice the iterm ramps up and doesn't really budge. That should really help in keeping the copter still in the air.

 

Patch 4:

Keeping the copter holding altitude while pitching hard was work OK, but not great. The copter tends to drift down. I got that piece of code from a description in Berkeley's STARMAC copter project. 

static int16_t get_angle_boost(int16_t value)

{

    float temp = cos_pitch_x * cos_roll_x;

    temp = 1.0 - constrain(temp, .5, 1.0);

    int16_t output = temp * value;

    return constrain(output, 0, 200);

}

I changed it to this:

static int16_t get_angle_boost()

{

    float temp = cos_pitch_x * cos_roll_x;

    temp = constrain(temp, .5, 1.0);

    return ((float)g.throttle_cruise / temp) - g.throttle_cruise;

}

This has the effect of maintaining perfect downward acceleration at all times. The reason this works is the throttle-cruise (say 500 out of 1000) is = to 9.81m/s/s of downward acceleration. We can use a linear mapping of throttle to acceleration to achieve the additional throttle necessary for the combined roll and pitch tilt.

Bonus 

The last example not is not a patch but a tuning example:

For a basic setup we've been using Rate_P of .14 and Rate_D of 0. Also a Rate dampener similar to the Wii project of .15 Many folks were OK with these gains, but the performance was meh in Max and Marco's experience.

Here is a copter at 45° returning to 0° with the current gains and no patches:

With Patches:

Notice the overshoot and the bell ringing. The frequency with the above with patches is lower and that's good.

Here is the comparison of the above, but with the optimum gains:

These gains are now the default gains:

rate_P of .18

rate_D of .004

stab_D of 0

Please try these gains in the simulator and raise and lower the rate_D term. I was pretty surprised to see how tied the Rate_P and Rate_D are to each other. They cannot be tuned independently. A rate_P of .18 and Rate_D of 0 will not fly well at all. It will fast wobble in the air quite a bit.

I hope this was interesting. The SIM is currently residing at www.jasonshort.com

Jason

I recently quit my job and have taken a few weeks to decompress. The first thing I did with my down-time was port Arducopter to Flash so I could do development and tuning in an environment that was more developer friendly, faster and fun. This app has real-time plotting of most system variables, almost all AC functions (except mavlink) and repeatable situations so you can tune your quad. 

It's a great tool for understanding the actual behavior of Arducopter. I know I've learned a lot. Each sensor is modeled to include noise and delay to ensure accurate behavior of the system. Under the hood, the SIM is running at full rate and all of the timers are stepped in a way that each flight is repeatable. Even the wind will repeat exactly with each run.

I'm also taking support donations to help offset my many many hours spent on this tool. I hope you like it and I hope it helps you fly safer and save a few props.

Arducopter Sim will live at http://www.jasonshort.com/ for now.

This is a simulation I'm working on to improve the Loiter control laws and discover optimal gains. I have identical code from Arducopter running in Flash as OO Javascript so I can ensure the behavior is the same as the real thing. I tested the MTEK GPS to find the actual latency and accuracy and then modeled it in code. This allows me to test PIDs and other coding ideas to see how the copter will behave in real life. The copter itself is a simple physics equation and should be fairly accurate. To better tune the SIM, I can compare AC Flash Logs from real flights side-by-side with the SIM flights which also output the same text based logs.

I've already found many areas for improvement in the Loiter code which i've just checked in to the GIT repository. 

Hopefully this tool will serve as a great PID introduction as well. I know I've learned a lot by comparing plots with small changes in the gains. 

Jason

DIY Drones Take on Silicon Valley

http://online.wsj.com/article/SB10001424052702303299604577326301981308414.html

This is the story I shot video footage for. Andreas Oesterer and Mark Harrison are featured.

And here is the full flight video:

2.0.50 is a work in progress, but this video highlights the Altitude hold progress in the latest code. 

Changes include a faster Baro filter to reduce latency and temperature induced noise. Alt hold control using the throttle has been upgraded to have a faster and proportional response. 

Acro mode has been enhanced and now has it's own duplicate set of Rate PI's for more flexibility.

I'll have this posted in the next two days to GIT and the mission planner.

Jason

This is a great talk showing off the technology around Google's self driving car. Heavy use of Slam and the fusion multiple databases including Google maps.

Sebastian Thrun is also teaching AI at Stanford online here: https://www.ai-class.com/

Lots of small tweaks and performance improvements. Here's how testing AP went in the Park:

If you compile with Arduino, you can now set CH7 to trigger some cool things like RTL, or In-Flight leveling. 

Check the GIT tree for details on the changes. Most are just nerdy code optimizations.

This release feels very close, if not the last beta. Thanks for all the testing,

Jason

I'm constantly loading and testing code and the power setup of the 2560 can be a bit of a pain. Mainly, the radio does not receive power because the Servo rails are only powered via a Lipo, which can be very dangerous. I never do anything but fly with a Lipo connected and I certainly don't connect one indoors. I'm just paranoid that way.

This hack will power the radio half of the servo rail with 5V from the APM's USB connection. The idea is to spilt the 5V rail into two halves. If you use an X-Acto knife you can easily cut the trace connecting both sides. I cut the ground rail in half as well, then used some solder to repair the bridge. Then I connected the 5v from the APM to the input side as indicated below. Now I can power the radio with the USB.

Just got back from testing the latest version. I'm having great luck with it.

Improved alt hold: Look for about twice the accuracy for altitude hold than the previous 2.0.40 preview. It's really good and the motors don't pulse as hard as they did before.

Loiter looks great and has the wind compensation turned on now by default. It wasn't enabled before.

RTL is running very smooth. Circle mode needs some work. Installing this will cause you to go through an initial setup process using the CLI. Be sure to setup your radio, level, enable the compass, set declination and enable sonar, etc.

Feedback is appreciated.

Note: This version is no longer compatible with the Mission Planner. Some internals have changed. I'll work with Michael Oborne to get it connected and updatable through the Planner.

Jason

AC2.0.40.zip

I've been away on vacation for the last week and a half, but I was able to port Arducopter to Flash and do some simulations. This has helped me rewrite the navigation control laws, simple mode, and Loiter to all use a streamlined set of control loops. This not only has saved code space, but the end result is a quad that flies like it's on rails. 

Loiter and WP navigation are now the same code and use a rate based solution from the GPS. The heading and ground speed values are parsed into X(long) and Y(lat) components. This gives me a far more accurate estimation of position than just using the Mediatek's lat and long outputs. The controller takes the position error, desired speed, and minimum speed and outputs pitch and roll commands. I've noticed a marked improvement in Loiter hold. Basically it's glued to one spot. I'll need to do more testing in windy conditions, so stay tuned.

Altitude hold uses the same controller design and manages the speed of altitude change. Landing and altitude changes are much more controlled and I've not seen the quad loose altitude on RTL like it did in the past.

The  Throttle, Roll/Pitch, and Yaw control loops have all be separated to give you the option of redefining any of the modes. In the zip file below, Alt hold has been redefined (in APM_Config,h) to use SIMPLE mode for Roll/Pitch. Loiter has been redefined to use Manual throttle. 

The Flash based simulator uses nearly identical code to Arducopter. Here's the work in progress of the sim:

The code itself is available for download here and is considered alpha to me. WP's are being tested tomorrow. Only RTL, SIMPLE, ALT HOLD have been tested so far. Crosstrack correction is currently disabled. Everything should work, but be careful. Anything could happen. I've only crashed 4 times today ;)

Jason

Updated:

latest code

This is a simulation I'm working on to improve the Altitude hold and change control laws. I have identical code from Arducopter running in Flash as OO Javascript so I can ensure the behavior is the same as the real thing. I sampled data from the barometer to introduce identical noise into each copter's solution. This allows me to test PID and other tricks side by side and see how the copter will behave. The copter itself is a simple physics equation and should be fairly accurate.

The Hover value is in your logs when you switch to Alt Hold. You should see it with the mode switch name. Mine was 495 which is the equivalent of 49.5% throttle. A lower value has a profound effect on the flight so play around with that.

The A copter is the current control solution. The B and C copters are Pi->Pi rate based solutions and are identical. You can adjust PID setting to pit the two against each other.

The scale on the left is meters. The Sonar is active and the mix is identical to the current AC2 solution.

This new code is in testing and will be available next week in 2.0.40b

Jason

UPDATE:

Please note that the initialization of Gyros was requested to move to the Arming function. This had the unintended consequence of making the Ground Station report erroneous attitude until the unit is armed at least once. This is changed already in the next version 2.0.39 which is still in development. Thanks.

This is a nice update and is recommended for everyone. I've gotten a half dozen flight in with it and have had good success. I'll be incorporating some of the ideas mentioned in the suggestions post over the next few versions. 

What's new:

I reworked the startup so it's much faster. Also, a feature a lot of folks wanted, calibrating the IMU at first Arming is in there. If you hand launch, please do your first arming of the motors on the ground.

I enabled a mode filter for sonar. Not too thoroughly tested performance wise, but it does work. (note, if you rely on the rangefinder class, you must rework your code to be compatible.)

RTL bugs are squashed and it's flying really well now.

Added a special filter in the PID for the derivative term to get rid of the alt hold and loiter issues from noisy sensors. 

Added a completely experimental mode called circle. It will by default spin the copter in a 10m circle from the point at which it was engaged. And it will Yaw towards that point at all times.

Yaw while navigating happens at quarter speed, which was problematic before.

Roll and Pitch Imax are higher 5° than before (.5°)

Logging seems to work now. Please erase the log after installing.

Everything else is mentioned on the SVN.

Just letting you all know that a new version is up. You must use the new version of Michael's Tool to do the setup. The older tool won't work with this version. CLI usage through the Arduino serial window will always work.

Many bugs are squashed. PID reports correctly now for D terms. 

The new rate based nav is on by default, but please be careful with it. Keep that hand on the Mode switch! 

Frames are a compile time option in the AP_Config.h file. (or use the GUI tool)

Frame orientation (X or + ) is done with a CLI based setup menu. (or use the GUI tool)

Basic motor LEDs are enabled.

Logging should be better but let's try and narrow down on the Bad Logs bug.

Jason