This is a work in progress. I've tried to address some fine tuning and performance issues.
Denny R. had made a comment about the inertia of bigger props causing issues. I've added a low pass filter to smooth the positive acceleration of the props to see if we can get at this issue. It may require tuning up Rate_P for a few folks, but I saw little issue in multiple flights.
Crosstrack had a small math error that decreased the resolution of it. I've fixed that and upped the default gains to get better tracking.
Made WP hit radius 1 by default. even 3m is too much for quads. (If you pass a WP you will move on to the next)
The Loiter method is tuned a little better by default, and now uses GPS offsets when flying less than 1.5m/s. Code experimentation will continue on this front. Thanks to Emile and afernan for their help!
A fix in the Z Accel startup was added to get an averaged result.
Added the ability to enter Loiter with Optflow enabled. - still a work in progress, not for everyday use just yet.
This alpha is on GIT now and is for user's who want to test code. As always, you need to use the "relaxpatch" version of Arduino you can find in the downloads section.
Update: We've found and patched some small type bugs in the latest and updated some GPS drivers in the Library. Be sure to pull the latest code and check http://apm.tridgell.net/ for the status of each build run against the SIL sim server.
I pushed a version on to GIT that addresses a number of issues.
- the low speed GPS XY calculations were incorrect and have been fixed
- Nav_Rate I term has been removed in loiter control - it's too easy to get two iterms working out of phase
- A second derivative has been added to Roll and Pitch. I found it removed wobbles nicely - Can be adjusted in the planner as STAB_D with a default of .25 (just enough)
- Smoothing has been applied to the motor commands in a way that really quiets down the alt hold pulsing without much effect on latency
- Yaw now has a dynamic constraint and I've upped the yaw gain.
- The motors output now have an LP filter on them so that the accelerate just a tad slower than the deceleration. This is a test to see if it helps big Octo's and Hexa's
- The Rate_I term is now zero'd for first five seconds after takeoff to keep balance.
- Loiter gains are lightened up a bit
- Nav_Rate_P is lower to remove back and forth sped related hunting in loiter
- Compass is enabled by default
- New I2C Library now included which should solve I2C related lockouts
- optflow is still a work in progress.
This update is based on flights today in a very windy environment.
It occurred to me that we're handling the WP nav I terms incorrectly and I reworked the WP navigation to share the same I terms from the Loiter. Even though they use different error input, etc, they turn out to both deal with wind in the same way. I have not Flown WPs with this new code, but heavily tested it in the sim and It's really rocking in hard wind. Transitions from Loiter flight and Nav flight are very smooth. Please let me know if you have luck.
This is a quick patch based on a bad crash Marco had. My theory was an I term that built up during wind that needed to be reset, but wasn't. It's a corner case but It bit Marco pretty bad. Please re-pull if you have R4 running to go to R5. And please, please be careful. This is alpha code not for general testing, but for development. Don't fly it on anything you would feel bad about crashing.
Update R7:Added an auto-land timer for RTL. If you don't change modes for 20s after the copter arrives at home, it will begin to auto-land. If you have failsafe and no GPS, you will immediately begin auto-landing.
Minor tweaks and cleanup
Made climb rate controller for landing universal for all altitude changes
Updated Loiter controller - Works great in the sim, thanks Afernan.
The 2.1 code supports both APM1 and APM2. But the different boards require different PID settings, and we have not yet released Mission Planner configuration files with those settings for APM2.
Yes, I have just tested in flight the latest version of AC v2.1.1... Unfortunatelly I agree with Marco and Phil... its seems more unstable (LOITER and ALT_HOLD) than the v2.0.56 or the v2.1 + AF02 mod... Be careful, experienced pilots are required here...
Merry Christmas to All,
I guess that you´ve tested with the corrections of the GIT code you´ve mentioned already, mainly this one in navigation.pde:
x_GPS_speed = (last_longitude - g_gps->longitude) /dTnav; // /dTnav instead *dTnav
y_GPS_speed = (last_latitude - g_gps->latitude) /dTnav;
Is that the case?. If so, I think there could be a problem with that formula (even if it is formally correct). The number obtained could be very big due to divide for a very small number (dTnav). I´ve experienced that flying "with" and "without" /dTnav (by error) and "without" is good (no divergences) and the oposite. So, ???
Tomorrow I´ll flight it (with care..)
I'm looking at the units now, We may ave a rounding error.
i see that randy change from 4hz to 10hz ... that's good :) who developed the GPS Driver ? And custom firmware on MTK for us ?
What about the WAS - SBAS correction ? I don't understand if is enable and if the status change on gps if the gps use the correction.
Normally in other GPS for example the status change if we have in 2D - 3D or DIfferential correction or Satellite GPS Correction.
I check that in MTK16 driver there are only 3 status :
1 Fix 2D
2 Fix 3D.
FIX 3D with Differential correction active is not define
FIX 3D with Satellite differential correction is not define
I ask this also in dev list but i don't see reply to my questions .
The people that customize the firmware for us have more info about it ?
last_longitude and last_latitude are defined as ints and g_gps->longitude etc. are longs.
The speed calcs will promote the ints to longs for the subtractions, so that should be OK provided the new and last coordinates are reasonable.
As far as I can tell ints are 16-bit in avr gcc, and longs are 32-bit. So,
last_longitude = g_gps->longitude;
last_latutude = g_gps->latitude;
are going to chop the top 16 bits off the lat and long, making the speed calcs incorrect.
dTnav has a value of around 0.1, so multiplying instead of dividing will reduce the speeds by a factor of 100 which is going to confuse the speed control loop, causing it to request more acceleration than should be required.
I think the truncation of the lats and longs also could be a problem, depend on your location.
Does this seem reasonable?
Yep, that was the issue, I'm testing the fix now as well as a few minor tweaks
I think Mike Smith did the GPS drivers. I'm not up on the decisions behind the details.
Arduino is terrible for these!!
If I turn on compiler errors via I get hundred of lines of errors due to Arduino's preprocessor. I can't sort through them all. I really wish it was better, since it's such an easy mistake.