Version 2.6 of the ArduCopter code is now available in the AP Mission Planner and in the downloads area!
Updates to MavLink 1.0 means you will need to use "ArdupilotMegaPlanner10.exe" to connect. If you've updated your mission planner recently you should find this executable in the directory where the mission planner is installed.
The above video is done using a prototype 3dr ublox GPS which seems to have better accuracy than the standard mediatek.
Improvements over 2.5.5 include:
- MavLink 1.0 support (use with ArdupilotMegaPlanner10.exe) [Tridge, Craig]
- Stability improvements especially during level hover [Jason]
- throttle range improvement (higher min and max) [Jason]
- improved standard Loiter PIDs [Alan, Heino, Jason, Angel]
- dataflash erase speed up ('+' messages removed but it only takes 6 seconds now) [Tridge]
- Copter LEDs [Robert Lefebvre]
- RTL loiter stage target set to home to improve final landing position [Jason]
- flip & acro improvements [Jason]
- circle mode target improvement for ground station [Jason]
- Auto Approach [Adam Rivera / Marco]
Bug fixes include:
- UBLOX driver fixes (lock should now be more reliable) [Tridge]
- enable mavlink messages during dataflash erase which resolves issue in which new APMs fresh from the factory appeared unresponsive [Tridge]
- proper printing of lat/lon values in dataflash logs [Randy]
- removed duplicate GPS reads [Jason]
- resolve flooding of telemetry link with low-battery warnings [Tridge]
- RTL bug would land if rtl_approach_alt was more than 1 [Jason]
- WP Radius could not be set larger than 1.3m [Jason/Randy]
PIDs are optimised for the 3DR/Jdrones quad with 850 motors and 10" props. If you're using more powerful motors/props and are seeing bad flight behaviour in stabilize, start by turning down Rate Roll P in 25% steps.
This time we spent some time optimising the loiter PIDs. Tuning loiter can be tricky so please refer to the discussions which will appear below for more community feedback on what parameters work best.
All feedback welcome below. Enhancement requests and bug reports can be put into the arducopter issues list. When possible please include logs (tlog and/or dataflash) and tell us whether you're using APM1 or APM2 and what version of the software you're using (presumably 2.6 but tell us anyway!).
at first many thanks to the Dev-Team, since i started in Sept. last year with a pre-finished Hexa by JDrones with 2.6 now i feel the first time really save in the air with my lawnmower.
Pls. can anybody explain exact the difference between "Simple" and "Supersimple" ?
And what happens, when i enabled the "Supersimple" - Option in MP and switch with CH7 to "Simple" ?
Thanks a lot for your answers
as far as i understand your question about CH7, "supersimple" is an option for simple mode. if you enable simple by any means (CH5, CH7) then youll fly in that mode - if supersimple is enabled then thats how it will fly, if not then just plain "simple".
as for the difference between SIMPLE and SUPERSIMPLE, the best way to describe it for me would be that SIMPLE flies with a rectangular reference, whilst SUPERSIMPLE flies with a polar reference, where the centre is the point the motors were armed.
in SIMPLE mode, i believe the "forward" direction is defined when arming motors, once set this direction will not change. so if you arm motors with the hexa facing north, pushing forward will always incline the craft towards the north (left will lean to the west, etc.)
in SUPERSIMPLE the point of reference is always based on the position when motors were armed, pushing the stick forwards will always incline the craft away from this point, back will always incline towards it. so in ideal, windless conditions, if you fly out to 50m distance, push and hold the stick left, the hexa will orbit the position motors were armed at a distance of 50m and in a CCW direction.
its important to bear in mind that these modes control the inclination of the craft and not the direction. theres nothing here compensating for the wind.
at least in SUPERSIMPLE there is a "dead zone" of 10m around the reference point due to the unreliable GPS position, im not really sure how the craft behaves in this area, but i assume it will revert to a normal "craft relative" reference in this area?
is there any reason why my copter drop drastically in alt if i sw to alt hold or loiter with APM2 and 2,6 firmware.
It's most likely that your TRIM_THROTTLE parameter is too low. Normally it should be set after about 15 seconds of flying in stabilize mode while maintaining a reasonably stable hover. It's saved back down to eeprom when you disarm your engines.
Maybe if you post some dataflash logs we can be sure...pretty sure it's this issue though.
ah, the other possibility is that you have a very overpowerd quad..if say it doesn't take much throttle to maintain a hover (i.e. much less than 1/2 throttle) then it could be that when you switch to alt hold mode your throttle is below the bottom of the alt-hold deadzone and it thinks you want to descend. This shouldn't lead to "dropping drastically" though...but if you push your throttle to the midele when entering alt-hold does it still fall?
I posted this earlier but I got no response and I feel this is a really significant issue and would really appreciate some input on it.
Basically when you go into any automatic mode, the manual override serves to offset the set point for whatever auto function(s) you are in, this means that the least bit of stick displacement from center (or throttle from position alt hold was engaged in) causes continuous movement of set point causing continuous movement of copter in direction of displacement.
Especially for the throttle, this means you are often going slightly up or down in alt hold mode.
But it can also cause slow continual horizontal displacement if stick doesn't exactly return to dead PWM center.
I think an adjustable dead band for the manual over ride might be the solution.
Maybe it's already in there, but having an adjustable dead band for the manual over ride on auto modes seems like it would be a really big help.
In Alt hold, I often end up with the Quad continuing to rise or fall slowly, and I have a very strong feeling this relates to my throttle being just slightly displaced from the point where I put it into Alt Hold which would act to move the altitude at which it was held.
Possibly similar results on Loiter horizontally (drift). If there was a little bit of dead band this could be eliminated as even a a possibility, if it was parameter list adjustable, even better.
For the throttle you could dynamically establish the dead band center point at the throttle position where alt hold was engaged, for the other axes, fixed stick center would probably be OK.
The throttle is a particularly problematic example because if you use any Yaw control, you are bound to displace the throttle slightly.
If I'm completely off on this please let me know. and please let me know what you think in any case.
Gary, In the new revision of the code, I think Jason (Developer) mentioned if your machine is slightly underpowered or overweight? one of the issues would be what you are experiencing? and was resolved by manually raising or lowering the throttle?
Thank you for responding Dean, but at about a quarter throttle my little 1 1/2 pound quad hovers and above that it would be happy to head for the stratosphere.
I really think that this problem is related to the allowing of the transmitter sticks to provide manual offset of the position or altitude set points.
A great idea in itself, but requiring exact return to center or to the current throttle stick position to prevent unwanted offsets being introduced.
An adjustable dead band for manual offset feature in the parameter list could completely eliminate this. problem
The deadband is adjustable for the throttle channel? but that would effect all modes including stabillise?
I'm actually only talking about a stick dead band exclusively for auto modes.
As I understand it, in an auto mode, the affected stick input no longer serves to fly the Arducopter, but rather serves to provide a way to manually displace the auto set point (location) for that auto mode.
The problem with this that I am seeing is most prevalent in alt hold (and alt hold using modes) relating to the throttle. If the stick (throttle) is not replaced to the exact spot it was when alt hold was entered the copter will continuously rise (or fall) in response to the altitude set point being over written by the slight offset of the stick.
If yaw is used at all, the throttle never gets back to exactly where it was and this offset provides a continual albeit small offset to the altitude that was originally set when alt hold mode was entered or to a Waypoint entered altitude.
Even if yaw isn't used, the throttle is still very sensitive to the slightest bump.
This dead band would need to be placed centered at the current throttle position when alt hold mode was entered.
It is less of a problem in roll, pitch and yaw because those sticks self center. But if they don't return to the exact calculated internal PWM center point they still seem to provide a small but continual X or Y offset or heading offset in the case of yaw.
I'm in an awkward position. I'm just completing a Y6 build (my first build, actually) and I'm starting to do some initial testing. My setup is as follows:
Scarab YSiix airframe, 775kv motors, GWS HD-9050x3 props (3 blade, 9"x5" - balanced), 2650 4S, APM2 on AC2.6
I have been running some tethered hover tests (light fingertip pressure to keep it in position) and I noticed that it was twitching randomly, mainly in the roll axis when one or the other of the front pods (2-3 or 1-5) seemed to do a momentary jerk up or down. Didn't notice it so much in pitch.
Rather than tearing it apart and soldering all the motor connectors (that will come, but after I've confirmed everying is behaving properly), I started looking at the logs. I'm new to this, so it took some time to get familiar with the information, but it appears that the servo outputs to the front pods were experiencing random spikes (high and low) that appear related to spikes in the x accelerometer and x gyro IMU.
Since I've never done this before, I'm not sure where the problem lies. Is this just a normal tuning issue (Rate Roll P, perhaps), or is this an indication that there is something amiss, either in the wiring of the copter, or in the sensors on the APM2?
Logs are attached.
Have you got any Rate D term? That would be more likely to cause this than P.