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
If you run into any issues, please post them to the issues list.
I was about to write the same suggestion as Geir. The code is moving extremely fast (great job to all by the way) but for every update we see the perverbial 5 fixes and 2 new bugs. Some of them pretty onerous and costly.
Is there a release available that provides the following reliable functions:
ALTHOLD via Sonar and Baro
WAYPOINTS (at least 4)
RTL (without auto landing)
This would allow more reliable flight testing and PID adjustments without the costly loss of airframes.
Jason I have an idea of a speed limiter when copteret is landing. When you are flying high and will put it down, it is difficult to calculate the speed down. I think that way, when you pull the throtel stick towards you for about 45% set a speed limit to the pre-set speed (5 km / h) to prevent it falling to fast. When the stickis Pulled Further towards you it falls faster until motor stops in the bottom as usual. I think a dead zone from 45-30%. This is just a thought that occurred to me since there is little stress to come down from great heights.
There already is something like that. it's #define MINIMUM_THROTTLE 130 in the code (config.h). This means that the motors will always spin at 13% throttle, even if you only give 5% throttle. Only with throttle completely down will the motors stop. So when descending from great heights, just set MINIMUM_THROTTLE high enough and make sure you don't completely shut down throttle. You could even use a bit of throttle uptrim on your tx while flying, so you never can shut down motors in flight. Ofcourse then you also won't be able to quickly shut down motors to limit damage in a crash or if the copter flies towards people. So consider safety too.
Is there anyone who has tried this feature? I think I have to try " Minimum_throttle" like you suggest, u4eake, but it means that the % throttle have to be adjusted according to how much payload every time it changes. This throttle value should probably be set at a point where the copter takes a slowly descend, and with throttle completely down the motors stops. It's important that the engines are able to be switched off in case of emergency. It would maybe easier with a speed limiter controlled by apm, using baro and sonar sensor, but I don't know how much job this project will create?
Couldn't you just use ALT_HOLD and keep throttle in the low region to achieve a constant descending speed? I don't know yet how the ALT_HOLD works since .49 but I think this could be an interestnig option
Is it true that anything past .52 requires 2650? Says 'too big' when I compile for 1280
After a fine tuning of the PIDs, I have got successful flights of the quadcopter set on ALT_HOLD and/or LOITER mode with the firmware Arducopter v2.0.51.
Below my flying PIDs setup:
I'm going to try your PID. Do you know why I can not get Loiter to change while flying? It only works if I'm holding the copter. I posted my log files back on page 22 but things are going FAST here :) Ever since upgrading to .50 (which is what I'm still on) I just can't get it to change while flying. Strange problem!
I have found my mistake during my 1st tests flights. During the tests of the ALT_HOLD mode, due to the strong burst up/downward (in no wind conditions), I have too much focused on the Altitude Hold PID (P,I) and completly forgotten that the altitude is driven by the Throttle... So, without changing the initial PID setup of the altitude and after a fine tuning of the THROTTLE PID the quadcopter fly very well with about an accuracy of +/- 1 meter (even less) in ALT_HOLD mode (baro only).
in attachment, you will find my working parameters.
+1 for maintaining a stable branch. I'm always hesitant to upgrade. And many of the new features I'm nervous to test anyway so I don't even use them. Yet going back to an earlier version is not always a solution because it will have problems also. So you have choice of old problems or new unfound ones :)
@Rz_Ten (we're out of reply space on page 18...) Thanks for all the detail. I'll have to resolder everything any since the wires were torn from the Mag board. I do find it curious that I can still run my APM system on the bench with the mag completely detached?
I don't think I'll find a bad solder joint, well, I know that I won't at the Mag because for sure those are soldered well since the joints were strong enought to tear the wire. I'll check the pins at the APM. And of course, I had to cut and splice the wiring harness to extend it so that's another culprit. But I'm not planning on reusing that harness anyway.
I wonder if there's some way this is Xbee related in my case? I'll be using shielded cable this time. Maybe I should try to filter the power supply as well, same way we are doing with the sonar.
I think the system will have to kick out into Alt_Hold. Better idea than just stabilize. Hopefully the pilot will be able to regain control and land it where it is. If it's a long way off while running a mission, big problem. Hopefully the mag doesn't turn out to be "unreliable" due to Xbee interference or something.