ArduCopter 3.2.1-rc2 (release candidate #2) has completed beta testing and has been released as the official version available through the mission planner and other ground stations.
Changes from AC3.2 are listed below and in the ReleaseNotes:
1) Enhancements:
a) reduced twitch when passing Spline waypoints
b) Faster disarm after landing in Auto, Land, RTL
c) Pixhawk LED turns green before arming only after GPS HDOP falls below 2.3 (only in flight modes requiring GPS)
2) Safety Features:
a) Add desired descent rate check to reduce chance of false-positive on landing check
b) improved MPU6k health monitoring and re-configuration in case of in-flight failure
c) Rally point distance check reduced to 300m (reduces chance of RTL to far away forgotten Rally point)
d) auto-disarm if vehicle is landed for 15seconds even in Auto, Guided, RTL, Circle
e) fence breach while vehicle is landed causes vehicle to disarm (previously did RTL)
3) Bug Fixes:
a) Check flight mode even when arming from GCS (previously it was possible to arm in RTL mode if arming was initiated from GCS)
b) Send vehicle target destination in RTL, Guided (allows GCS to show where vehicle is flying to in these modes)
c) PosHold wind compensation fix
d) prevent infinite loop with do-jump commands pointing at each other
e) pixhawk memory corruption fix when connecting via USB
f) vehicle stops at fence's alt limit in Loiter, AltHold, PosHold (as it did in AC3.1.5)
g) protect against multiple arming messages from GCS causing gyro calibratoin failure
Thanks to Raph for the video. This is actually a video from AC3.2 until we have one specific to AC3.2.1.
Replies
Thanks for this info Richard, I like the concept to the delay in immediately entering the land mode, I struggled with what was happening to the hex because I didn't know about the failsafe land and either I did not hear or see on the nexus tablet the EKF error. Fact is because I didn't know about the failsafe land and the hex was responding as it did to the RTL I guess its number was up. I have a quad also with pixhawk that I practice my flying on, (in Stabilise & AltHold) and sometimes thrash about and have noticed that with fast flight and constant direction changes I can upset that, I need to look at this now I'm assuming as I am not generally in modes that require position info the EKF doesn't attempt the land failsafe.
Now we are going to be alert and solve the main problem but others can do the same error, perhaps is a good idea Richard's one that have a little seconds in Att hold to notice that something wrong has happening and give a little time to paid attention to the GCS warning, and then Land if the pilot don't change to a manual mode. When I crash, I was flying FPV few seconds after, the googles fail (conector problem) I take them away and try to watch the back up screen, when I was doing that, the Nexus becomes to lauch BEEP, BEEP, BEEP!! but too late, I didn't have enough time to watch it, my copter was on the ground; to finish, the DVR was frozen, it wasn't my day, but the Nexus allows me to find the copter with minimun damage. :)
I thougth that Pixhawk with compass on gps didn't have this problem anymore?
I spent about 6 hours walking hilly farmland looking for mine, unfortunately after one of my attempts to use RTL the hex went sideways quite rapidly and out of sight so my last recall of her was heading west at a rate of knots, using this I searched as far as I could of the farmland, my final search I returned to near my last sighting was, to again get a bearing on direction and could hear in the far distance the pixhawk "upside down" sound I was at that time about 500 mtrs away from her and it took another hour to actually find it from this. The damage was really interesting, it appears the props were not spinning on contact with the ground as there is not tip damage to any of them although one is broken from impact, 4 of the six arms are busted and lots of other damage including to my new GoPro, have had pixhawk connected to computer for about 4 hours now and logging armed "flights" then checking results to see if any errors arise. When I finally returned to the launch site I had a look at the Nexus7 to see what it could tell me, when the hex flew out of site the signal to the ground station was lost, but it then returned to almost the original region where I noticed the upset and the telemetry started working again and I found it about where it indicated on the nexus7.
Yes, I love the Nexus /, I'm trying with dipole antennas to have more range just now, I can share results
Yes, your copter was trying to land because it was lost caused by a bad heading estimate, you can switch to manual modes to bring back but not to an automatic one because the copter prefers to land and not to fly away and lost, here you have the full explanation
http://copter.ardupilot.com/wiki/configuration/ekf-inav-failsafe/
Here how to analize logs
http://copter.ardupilot.com/wiki/downloading-and-analyzing-data-log...
http://copter.ardupilot.com/wiki/common-diagnosing-problems-using-l...
And here a discussion about a similar crash that I had and possible solutions,
http://diydrones.com/group/arducopterusergroup/forum/topics/compass...
Another thing: you have a flight mode err too, check if your PWM for each mode are correct (mode 6) and you have a mode err 16 that I saw in a crash log but I didn't find What it's means yet
Thanks for your reply Cala, I have been reading the wiki pages in an effort to help understand the info in the logs, the flight mode error 16 relates to pos hold.
From Sasaha's comments I'm starting to see the picture more clearly now, I was attempting to use the RTL to bring the hex home but this relies on positioning info and via the EKF that was corrupt and thus every time I tried to use a mode which required position info the EKF failsafe kicked in (I was not aware that when the EKF entered failsafe that it initiated the land command), I did put her back into stabilise then Alt hold, for a short time but then again attempted RTL and thus a further EKF failsafe occurred. I should have left it in Alt hold for a while to settle down. As I had lost orientation at that point, the stress levels were somewhat elevated at which point reflex was RTL.
A lesson from this for me is that my fence is not really the ultimate protection I thought it was as it to relies on position info, but now that I better understand with F/C responses I can be better prepared.
My real decision now is whether I make the EKF less sensitive or disable this function, I also need to understand and work on the compass calibrations and attempt this out doors away from the building.
I think so when I crashes, but the problem if you disable or less sensitive you are in more risk to fly away and I prefer to crash (only changed cheap landing gear) and no lost all my cuad, so I read all about compass, try different things to solve the problem and find a stupid little bolt inside the APM case causing it, if I only disable that function perhaps I lost my cuad now.
I've read through this forum post in an effort to gain some insight into a wee crash on Friday which involves my hexacopter and Pixhawk flying with 3.2.1
I have spent some time looking at the attached log and reading through the definitions on ArduCopter in an attempt to isolate what may have happened.
Flight was the second of the day, a simple mission with 5 way points splined from 2 - 4 with the fifth being RTL. Heights may seem strange but I was on a ridge and thus some of the heights are lower than my position. The hex overflew the first waypoint and then flew on straight ahead, it appeared to be somewhat unstable, the range was approximately 500 mtrs I was not able to determine orientation and attempted to utilise RTL which according to the logs was quickly over ridden by the failsafe land command an number of events occurred around this time. I switched between stabilise, and alt hold, also requesting RTL without response, until hex flew behind hill. I even switched of the transmitter in an attempt to trigger its failsafe which again was over ridden.
I am not able from my understanding of the logs, to establish a cause which gives me confidence to rebuild and re use existing FC, ESC,s motors etc. so someone with greater understandings input would be appreciated. Perhaps along with an explanation of how you read the log.
ta
phill - Northland New Zealand
4.BIN
Your compass Z offset is very high, which implies you did the compass calibration inside near other magnetic fields, or have i.e. magnetic metal screws near your compass.
You have repeated errors that the actual position and calculated position vary, this may be due to the bad compass data.If the copter faces differently from how it expects to face, it will end up going into completely wrong directions.
You also had a fairly mediocre satellite reception.
On top of this, you had a few baro glitches, so your baro is possibly not properly protected by foam.
To sum it up, your copter had loads of bad sensor data, so it simply didn't know where it is.
Thanks for your reply Sascha, can you give me a quick rundown on how you are reading the actual position / calculated position variance in the logs please.
The GPS count / HDOP may well be my location - Down Under in New Zealand, I don't think I have ever seen a sat count of over 12 and an HDOP below 1.2, I have set my prearm HDOP to 3 so that I can initially gain some height and always move from Stabilise, to Alt hold, then Pos Hold for a time before I use the auto function.
F/c is pixhawk so I didn't realise the baro needed further protection.?
I have flown this Hex on about 40 odd occasions, both in Stabilise / Alt Hold if I'm flying as well as video missions in Auto, this is the first time it has played up but then I've perhaps only had a couple of flights with ver 3.2.1, I might have to make the EKF a little less sensitive.
-
31
-
32
-
33
-
34
-
35
of 59 Next