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.
Thank you, I will try. I see from 0.53 not a Beta anymore.
Jason, were the logs helpful to find out why Loiter is not engaging?
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.
I am also voting for a stabilization of the code. It seems to me that new features and fixes are applied all the time, so it is never possible to get on the wagon with a tested and stable version.
I would suggest that a Git branch be created that would only contain bugfixes now, which would be merged into the bleading edge trunk where new development occurs. But I guess maintaining such a "stabilizing branch" might not be that much fun :) Jason what is your opinion on this?
As I suggested in another post a "stabilizing branch" in GIT might be fruitful, so that we get this version stable before adding new features?
(But then I guess most of us will also want to be on the bleeding edge too, enjoying new fancy features), however it will be good to have a stable version too!
Jason, It have problem. I'm test 2.0.54. When I will change ALT_HOLD is some fast drag up and down. after have problem it, I will check Logs data. Sonar don't work. But 2.0.53 not problem.
Good idea :)
Thanks for the supportive comment!
It was a setback yesterday, but I guess I will just have to hang in there, and get the broken parts.
I agree with you Geir, but we must not stop the new thinking, just find a new way to manage the development of it.
Of course, but having a dedicated stabilizing branch for prerelease software is a normal procedure in the sw industry. New thinking will then occur on the trunk with latest and greatest.
Of course some effort has then to be given to maintaining two branches, but it should be fairly easy to merge from one to the other. The 1.0 branch will then ONLY get bugfixes, while the 1.1 branch (trunk) will be bleeding edge and new thinking!
I vote for that,
I even think it will be more attractive from a business point of view as well, as it will attract Mikrokopter like customers with PnP copters.
I admit feeling scary about latest code bugs reports and its crashes.
While the being of the bleeding edge is the best thing of this community.
100% approved dear Geir! :-))
First check the stability of the old code, and mark it with the lable "stable version" (bug free), then add new feature or improvement but only for some beta tester (and for this i'm here with my "big octo", if you want) or for all but "warned about some probable bug" because is ßeta.
And now the question is: what's the latest stable "flyable" version? 2.0.49? 2.0.54?
Is not only a question of money, but first of security.
And i remember to all: use a separate BEC for APM, and connect servos to one esc's bec. ESC.
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.