ArduCopter 2.9 / 2.9.1 released
ACRO bug (fixed in 2.9.1b): while doing flips in ACRO mode, if you switch to Stabilize while inverted your throttle will go to minimum. To regain throttle control you need to switch back to ACRO then back to Stabilize again (i.e. switch to stabilize twice). You never lose control of roll/pitch/yaw.
Loiter/AltHold/Auto/RTL bug: if you switch into these modes with throttle at zero motors will go to minimum until you raise the throttle.
Auto mode altitude bug (fixed in 2.9.1b): setting a waypoint altitude greater than 320m over home altitude may wrap around and instead be interpreted as a low altitude.
ArduCopter 2.9 is now in the mission planner and the downloads area!
The major improvement is we use inertial navigation to improve altitude hold. This increased reliance on the accelerometers means you must do some additional set-up before flying:
1. Perform the new accelerometer calibration in the mission planner (video). The auto-trim metho has also changed (video).
2. Add vibration dampening foam between your frame and the APM. Some suggested materials: DuBro, gel, hk foam.
3. If upgrading from 2.8.1, modify the throttle and altitude PID values:
- Increase your Throttle Rate P, reduce I to zero, increase D
- Increase Altitude Hold P, reduce I to zero
- Tune Throttle Accel P and I terms but try to keep P about 1/2 the size of I
Here is the list of major changes (a more detailed list can be found in the release notes):
- Alt hold using inertial navigation (Leonard, Randy, Jonathan)
- AUTO_VELZ_MIN, AUTO_VELZ_MAX parameters control the max climb/descent rate for the autopilot (cm/s)
- PILOT_VELZ_MAX controls max climb/descent rate for the pilot (in cm/s)
- Landing improvements (Leonard/Randy). Copter will descend to 10m or until an object is sensed with the sonar. Then slows to 50cm/s descent (speed can be adjusted with LAND_SPEED parameter). (video).
- Surface tracking with sonar (Randy/Leonard). Copter will attempt to maintain current distance from objects in front of sonar regardless of altitude. Only used in alt-hold and loiter, not used for missions. Sonar can be enabled/disabled with CH7 switch. (video)
- Failsafe improvements (Randy/Craig/John Arne Birkeland) including bug fixes, additional check for PPM encoder failure and implementation of battery failsafe. Set-up instructions are here.
- Mediatek gps driver accuracy improvements and use of SBAS [Craig]. Instructions on upgrading your mediatek to firmware 1.9 are here.
- Traditional Heli improvements (Rob) including (a) bringing heli code back into the fold, (b) enabled rate controller (previously only used angle controllers). (c) fix to rotor speed controllers - now operates by switching off channel 8. (d) allow wider collective pitch range in acro and alt hold modes vs stabilize mode (e) bug fix to allow collective pitch to use the entire range of servos
- Acro trainer (Leonard). Copter will return to be generally upright if you release the sticks in acro mode.
- ACRO_TRAINER : set to 1 to enable the auto-bring-upright feature
- ACRO_BAL_ROLL, ACRO_BAL_PITCH : controls rate at which roll returns to level
- Camera control improvements (Randy/Sandro Benigno): (a) AP_Relay enabled for APM2 (b) Trigger camera with CH7 or DO_DIGICAM_CONTROL command (c) Allow pilot override of yaw during missions and fixed CONDITIONAL_YAW command.
- PPM sum support for transmitters with as few as 5 channels (Randy/Tridge/John Arne Birkeland).
- Performance and memory useage improvements (Tridge).
As per usual 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.
Special thanks to our testing team lead Marco and the dedicated bunch on the 2.8.1 release thread who put their copters at risk while testing the pre-release version. Some of their videos are here: 1 2 3 4 5 6 7 8
Please feel free to report issues you find in the discussion below and/or add them to the issues list.
Replies to This Discussion
-
Permalink Reply by Bhanu on -
Hi Guys
I was away for 2 weeks and now back. I have recently flashed my RTF 3dr Hexa with latest Version 2.9 and glad to see that alt hold is actually holding and it was not working in my case in ver 2.8.1 Congratulations to the team.
I am having a strange problem and suffered few crashes because of that. I would post videos of two flights here. First is to test RTL using mode switch and second one a few minutes later to see it happening again. Copter was going away and when I switched to do the RTL it lost control and flipped and crashed. Broken props and motors. I have replaced those and couple of days later I tried running missions and during those missions it crashed few times in autonomous flights and later in a new mission it did not took off in auto but motors started without sufficient lift so I switched to Stabilised and took it off but within minutes it crashed landed.
I am attaching the logs of the video graphed flights here. What could be the problem and I am using APM 2.5 and stock 850KV motors and 10.47 APC props.
Following is the link for a good flight and RTL
and this is the crashed flight minutes later.
Please suggest me what I am doing wrong or there is some hardware or firmware / Software issue.
I have done accel calibration as suggested before these flights.
regards
Bhanu
- Attachments:
-
-
2013-01-22 16-04-57.tlog, 597 KB -
2013-01-22 16-44-37.rlog, 150 KB
-
2013-01-22 16-44-37.tlog, 195 KB
-
-
Permalink Reply by Bhanu on
-
No Balloon, Prop was ok in the air. Every crashed landed flight props were fine in the air.
-
DeveloperPermalink Reply by Randy on -
Bhanu,
You don't have dataflash logs do you? I've had a look at the tlogs but I find they don't have enough information about what the controllers were trying to do. In the dataflash log we can compare Roll-In vs Roll and Pitch-in vs pitch and I suspect we will see they diverge which normally indicates it's a mechanical failure.
I strongly suspect that it's a mechanical or power problem. The copter very much looks like it's trying to maintain it's attitude but it simply can't. I think it would be good to check that all your ESCs' bullet connectors are ok, that none of the ESCs have the low voltage cut-off set. That the props are securely fastened. That your battery is well powered, etc.
You're just in stabilize mode so it's pretty hard to imagine it's a software issue...
-
Permalink Reply by Stephen R Mann on -
The copter very much looks like it's trying to maintain it's attitude but it simply can't.
It looks to me like an over correction that gets progressively worse. In the Cessna world we call this PIO, or Pilot Induced Oscillation. Could the AP be so highly tuned that it is overcompensating?
-
DeveloperPermalink Reply by leonardthall on -
I agree.
-
DeveloperPermalink Reply by leonardthall on -
I would need to see you .log file from the copter to be sure but I think this may be a tuning problem with your basic roll pitch pids. What are the two long weights below the arms?
-
Permalink Reply by Bhanu on
-
Hi Leonard
Let me see how to get logs from the copter and then I would post it. Those two long pieces are just foam cushions taken from the packing of LED PC Monitors. Couple of days later on a windy day I have removed them because I felt they were the reason of toppling because of wind pressure and cut new legs cut from the discarded PCB boards from a friends factory.
regards
-
DeveloperPermalink Reply by leonardthall on
-
Permalink Reply by Kevin B on
-
I had an uncommanded RTL this weekend, which at first I thought it was just a normal battery failsafe based on OSD video (10.2V, although 21% is also close LOL). Upon closer investigation, I am not sure if it was a throttle failsafe, or what. First, here is a log view:
... and here is the OSD video (go to 6:25, when the RTL in question occurs):Looking at the logs and OSD video, the only clear reason for failsafe to kick in then was maybe low voltage (10.2V minimum configured). So why is that coming up as a "radio" failsafe in my log? BTW, the capacity failsafe has never worked as it should for me... only the voltage and throttle failsafe are known to work, and I do have attopilot configured in MP (option 4).
- Attachments:
-
DeveloperPermalink Reply by Randy on -
KevinB,
Thanks for the report. That ERR, RADIO, 2 is a ppm encoder failsafe. Your symptoms are exactly the same as what Graham Dyer has reported over on this thread. Just like Graham you've got this sudden ppm encoder failure but that should never fail unless the ppm encoder hasn't provided an update in 2 seconds. But from your logs I can clearly see updates are arriving.
My guess is that there's an issue with the APM_RC.get_last_update function and it's very occasionally not reporting the correct time that it was last updated. Another thing I notice is that both you and graham have a very large amount of logging turned on. This is badly affecting the performance of the main loop which can be seen in the PM message. For example look at row 34784 of your logs and you can see that 34% of your main loops are running slowly and the worst performing is 2x what it should be (10,000ms).
The performance issues may not be related although it seems a bit of a coincidence. Interrupts are very time sensitive as well.
Could we discuss over on Graham's thread? This will allow a more focused discussion.
(P.S. for those worried about hitting this issue, it can only occur if you have the APM's throttle failsafe enabled and it's off by default so if you haven't specifically enabled it, it's most likely not enabled on your copter).
-
DeveloperPermalink Reply by Randy on -
Ok, I've found the issue and fixed it in the 2.9 branch and I will be pushing out a 2.9.1 release as soon as we can get it through testing.
The problem is in arducopter.pde's read_radio function. The value passed back from APM_RC.get_last_update() is the time the last radio frame arrived. It's possible for that frame to arrive right in the middle of when the line below is being executed and if we're really unlucky it's possible for us to be just crossing the boundary of one millisecond to the next. In this case the result of the millis() call can be one less than the result from the APM_RC.get_last_update() call. This makes the result a small number - big number = -ve number. Because time is an unsigned int, it overflows to a very big number. So the APM ends up thinking it hasn't received a radio packet in 49 days.
// turn on throttle failsafe if no update from ppm encoder for 2 seconds
if ((millis() - APM_RC.get_last_update() >= RADIO_FS_TIMEOUT_MS) && g.failsafe_throttle && motors.armed() && !ap.failsafe) {
Log_Write_Error(ERROR_SUBSYSTEM_RADIO, ERROR_CODE_RADIO_LATE_FRAME);
set_failsafe(true);
}
It's just bad luck if these things all happen at the same time. I don't think you can protect against it.
Sorry for the troubles and anxiety over this.
Social Networking
Top Content
Contests
Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.A list of all T3 contests is here.
Groups
-
Moderators
24 members
-
Documentation Editors
51 members
-
Agricultural UAVs
133 members
-
ArduCopter User Group
1298 members
-
Telemetry over cellular …
249 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
