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 haven't looked though the code in a large amount of detail yet and I'm new to i2c programming so take this with a grain of salt. :) I believe that when the mag is completely disconnected the APM will still start properly, since the initialization will fail. Once it completes though, the Arduino considers it a member of the i2c bus so any sudden disconnections will cause the hang as it waits for the sensor to respond.
I'm a little concerned about making it fit on the ATmega1280, since it seems the code is already hitting the 124KB limit. Adding additional error handling will likely increase the size by a non-small amount, depending on how detailed it is. Ideally I'd like to dump something into the log when an i2c connection fails, so people can tell if something puked instead of trying to infer it from missing or suddenly incorrect sensor data.
Alt_Hold would be preferred, but it's possible for the barometer to fail as well, and if that goes the altitude code can only be supplied by the GPS or sonar. When I normally write programs I try to do it so that nothing is assumed to be connected all the time. :)
I guess it depends on how complicated we want to make it with possible cascading failure modes. Mag only: Alt_Hold. Baro only: RTL and try to hold alt above whatever the sonar range is. Mag and Baro are gone: Alt_Hold at sonar range.
Either that, or start the self-destruct sequence! :)
Updating to 2.0.54
Still same problem than in #52. If, after uploading with arduino, we "reset APM H/W to defaults" in APM, it blocks. Need to reinstall again. In one case I needed even to reinstal first 2.0.50, then 2.0.54.
Looks like a line was duplicated when it was fixed. Try to grab another copy, I've removed the extra erase code.
The logging may have changed in this update and won't be in sync with the mission planner just yet.
+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
We have a few limitations which could be overcome that would allow us to reach the next level of position hold.
One is a basic physics model of the copter, it's weight and thrust. The copter tends to achieve hold then get tipped by some wind and not recover until the GPS tells it what's up. But we know the copter just tipped. So a physics calculation or simulation would tell us the anticipated velocity and direction vector of the copter due to the disturbance. It would act like a dead reckoning system that eliminates the lag in the GPS.
Anyone want to help tackle that?
I want. I´m strong in mechanical (aeronautical engineer, EADS-AIRBUS company), not to much in S/W and H/W. I think the main question now is to define clearly the problem to solve.I can imagine it, but I´m also very new in copters and I need some initial push on that.
Arduino have only 16 Mhz cpu, the other system much more, and some (like MK) have two cpu, one for stabilisation inside FC (gyro/accel/baro) and another in the navigation system pcb (NC).
Another question is the quality of the must important sensor, just for example the three MEMS gyroscopes (ADXRS610) inside MK FC costs over 170$... yes, only the three gyros! :P
The point is there's a big difference in quality and costs of components, via software it's impossible the "virtualization of quality"... :-)
With only 16 MHz and this sensors ArduCopter fly very well "like a miracle", but IMHO the next step with same "code structure" and IMU compatibility is some like the board of Roberto Navoni:
Much power, more ram, another world at "low costs", with 100% compatibility with IMU OilPAN.
AR Drone Parrot
DJI Wookong M
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
I'm agree with you :)
MP32F1 and F4 are multilayer board. We adopt exactly the strategy that you told in your last post .
The MP32 use STM32F4 the best arm available on the market for understand the difference in power i doing a simple benchmark using nested cycle this is the results :
APM 2560 960 cycle in 5 s
MP32F1 4500 cycle in 5 s
MP32F4 18540 cycle in 5 s
on MP32F1 is yet available all DIY library and Arducopter32 re 2.0.49 , i'm waiting to port the new revision untill we understand where is the lockup bug.
The porting on MP32F4 is started in these weeks , the enviroment is ready for developer.