Developer

Arducopter 2.0.50

Arducopter 50 is our first fully Software in the Loop tested version. Special thanks to Tridge for developing the test suite!

 

Here is a quick video of the testing in action:

 

 

You can see the copter takes off, flies a simple square in manual and records the square with CH7 toggles at each corner. It then loiters and switches to AUTO to fly the recored WPs.

Once that's done it lands and loads a mission via mavlink. The mission is intended to test all commands including conditional commands and the jump command. The last two commands are RTL and land.

 

What else else is new:

More aggressive Alt hold control - You can now achieve rapid ascents & descents in alt hold. The throttle acts like a large dead zone with the upper and lower 20% being a proportional control. Adjusting the throttle resets the new target altitude.

 

Added the ability to log arbitrary data for better debugging.

 

Recording WP in normal flight with Channel 7. This is a great way to get WPs recorded in the field. Just toggle ch7 High for 1 sec and it will save the WP to memory building a WP list on the fly. Switching to AUTO mode will fly the WPs. Rebooting will allow you to start over on a new mission.

 

Added separate Acro PIs for people to tune Acro mode.

 

Z dampening - Alt hold now has an optional Z accelerometer dampening system. You need to compile it yourself to test. I'm eager to hear user's feedback on this so we can make it on by default. You can enable it in APM_Config.h by changing the '0' to a '1' like this "#define ACCEL_ALT_HOLD 1"

 

Y6 now has top and bottom missing ratio enabled. It's 1.0 for the top by default, but many users set it to 0.9.

Crosstrack correction is now enabled for WP navigation. Thanks to the SIL, we could test this properly. This makes the copter hold a very tight line to the next WP. The default gain is 4.0.

 

RTL now defaults to return at the current altitude.

 

Improved Circle mode performance.

 

Changed the Mission scripting execution order to be more intuitive. Conditional commands now execute after navigation commands are complete, not just loaded.

Various mission scripting bug fixes.

 

Removed some tests in the CLI for memory savings to fit the 1280.

 

Added precautionary safety preventing the user from entering flight modes that require GPS lock. If home has not been set you will get a stabilize mode instead of Loiter, or Auto, etc.

 

There were also many small bug fixes and code cleanups performed - too many to list.

 

If no one has any major issues, I'm going to call this the final stable release!

 

What's next in version 2.1 (target release early January):

- complete Mavlink 1.0 upgrade, ensure better Mission planner support.

- exploration of learning algorithms for auto-tuning.

- sensor/register level software simulation for testing more code.

- expanded test suite with more scripted scenarios

- secret cool stuff regarding the DCM

- ideas?

 

If you run into any issues, please post them to the issues list.

Jason

 

 

 

 

 

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • Dear Jason

    I am still thankful to you for writing code for us. Although I tested 2.0.50 on my two arducopter boards and on alt-hold they just started to shoot upside. But I still think you are doing good effort.

     

    Regards

  • I appreciate the effort of Jason and Team.

    My question is how DJI is so precise with baro. I flew it today with camera. Every thing changed due to unbalanced camera weight but even then there was no need to change the PID.

    Specially atl hold and position hold was rock solid

     

    Why do we need these expensive noisy sonars

  • Wow, I didn't realize you guys had that much trouble even with Stabilize?  On a Trad. Heli, at least my big flybarred heli, it's super stable in Stabilize mode.  A child could fly it.  My only issue so far has been, I believe, this I2C bus problem.

     

    Well, I also had problems with Alt_Hold, but I still have work to do on the physical coddling necessary of the baro and sonar.  ie: sonar heat, foam and filter, and baro foam.

     

    I wonder if one reason, besides the mechanical gyro effect of the big rotor disk, is that the main vibrations are at a low speed, about 30hz, compared to your props spinning at about 400hz.

     

    How does the stability of the Ardu-quad compare to something cheap and simple like a KK-quad?

  • Look at this log, this is taken in very windy condision!! Noise insulating solved the problem, and the bonus is a rock solid hexa. Although Loiter and alt hold work in strong winds. Looking forward to the weather gets better. The spiks are when the copter is on the ground. I moved the gps up and to a alu plate. Insulated with aluminum tape between each section, and moved apm to top section from pdb. Twisted all cabels possible, gps, telemetry, motor, etc. Put telemetry modul under gps alu plate.Flight log attached

    3692309888?profile=original3692309901?profile=original

    2011-11-30 03-07 12.log

    https://storage.ning.com/topology/rest/1.0/file/get/3692310076?profile=original
  • I couldnt upload the 2.0.54 code, i have waited 15 minutes

    i cant even upload the 51, i did succeed with it before.

    strange

    I got 
    avrdude: stk500_2_ReceiveMessage(): timeout

    3692310098?profile=original

    I can load only form the planner,  Why is that?

  • I couldnt upload the 2.0.54 code, i have waited 15 minutes

    i cant even upload the 51, i did succeed with it before.

    strange

  • What about the Z dampening, is it works on 54?

    because on 51 version it climbed without stopping 

     

  • I think we should first fix

    1. ACRO

    2. Stabilize with very good throttle control as easy as AR Drone

    3. Loiter

    4. remaining

  • Flown:

    AR Drone Parrot

    DJI Wookong M

    Arducopter 2.50

    If I just compare the performance of the flight in stabilize mode of APM with the other two It needs a lot of practice before someone may control the copter. I am using Jdrones standard frame for ardu. Where as DJI wookong and Ardu are flying excellently. I know the other two are not at all feature rich as Ardu is. Its been a great job done so far by the developers but I think as others are saying its useless to go ahead before making the basic features rock solid.

     

    So far the PCB is concerned a two layered PCB as ardu is has so many minor issues which may be a reason on some accumulative errors in the over all flight performance. Shifting to a more precisely designed four layered board with full ground plane and may be separate planes for analog signals for better ADC performance will improve the noise issues.

     

    As Jason said I think the basic physics model should be upgraded first

  • +1 For stable branch as well. A great deal of effort continues to be put in by Jason and team and I for one am greatly appreciative,  However, last weekend I was out with my arducopter 0.50 and my Mikrokopter, and a friend had the new DJI on a hex. I spent over an hour of conituous pid tuning, and still could not get the ardu to fly anywhere near my MK. Then I saw my friends DJI do a rock stable position/altitude hold then he turned off his transmitter and the thing flew back and auto landed perfectly.

    I have 3 ardumega setups (I lost a fourth in a runaway plane) so I am not giving up on this, but we need a stable firmware that flies well, and can alt hold and position hold well. Unless ardu can do that, then there is no real point in my mind of adding more features. The other thing I wonder is maybe the sensor hardware is just not good enough to achieve what MK and DJI are able to accomplish?

    Sorry for sounding negative - I do want to see my ardu be on par with MK

    Al 

     

This reply was deleted.

Activity