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
The preemption is both planned and allowed, and is not a bug or omission. At present, it remains the only mechanism to stop motor power when using the tablet as primary controller. At present, the only other way to stop motor power when using the tablet control, is to switch to Stabilize mode from the tablet flight mode pick-box. This takes significantly longer to do, and also poses it's own set of risks, because the mere fact that stabilize mode is in that pick-list makes it too easy to select it be accident, with the exact same results you experienced.
Since most tablet controllers do not even have "virtual sticks" there is no way to "raise the throttle", and stabilize mode is basically kill-mode. However, the reality of this situation is not obvious to most beginners "What is Stabilize mode? Oh no."
I am actually concerned about that problem, and there is already discussion to remove the acro and stabilize modes from the tablet pick-list. However, this puts us in exactly the same problem... if you have no RC Tx, you have no ability to kill power, AT ALL. And that cannot be allowed.
As stated on drones discuss, I believe the proper path forward, is add a kill-switch function to the tablet flight screen. Then and only then can we discuss removing acro and stabilize from the pick-list, and preventing RC Tx pre-emption.
Funny to see this discussion as we had it over the course of many years at a early uav company I worked for. Our system automatically disarmed the motors when it landed (using sonar to detect the ground) and that was an imperfect system that caused quite a few crashes. When it worked it greatly simplified the operation for new users. We also had a kill switch which was for emergencies. One such emergency was when the vehicle was the vehicle spun up and a wind gust flipped it over before it could get into the air. Built into the system was a check to turn off the motors if it was inverted but that check was not active during spinup part of the state machine so the vehicle just danced upside down on the concrete making the now serrated carbon fibre props more and more menacing. The test engineer didn't know what to do and it took him more than a minute to notice the stop motors button which worked. The way this function worked is it was a 3 tap button press with progressively more dire warning sounds/lights as the button was pressed went. Only once was this ever mistakenly executed. An end user was training people in the field and he was so used to demonstrating the kill button on the simulator that he just plowed through all 3 presses and realized the vehicle was in the air - then it wasn't. The difficult balance to strike is being able to use the feature quickly (vehicle careening towards small children) but not accidentally (all other times). In hindsight it was a seldom used function but some of these machines are flying lawnmowers and I would want it on the gui. Just my 2 cents.
I would think it would be very rare and clearly a user error to hit the button 3 times by mistake. You can only make things so idiot proof.
hey rob.. separate kill/CRASHME switch is what I suggested (and still dont think is safe.)
if this function is needed in the first place
just DONT tie it to a flight mode such as stabilize and you lose my objections..
and lock off stab switch/thr=0 and get a precedence system in there instead of catch as can as it presently is..
btw these systems ARE being flown over folks heads by 3DR employees(dont even get me started on Maker Faire last year) and others on a daily basis.. time to get used to that reality and code appropriately..
does any GCS have virtual sticks currently??
the code is long out of droidplanner/tower and no longer works at present when compiled back in.....
Ok, I think we actually aren't far off now then.
Yes, my desire is to employ a kill-switch function, that would decouple the motor-stop from the mode selection.
Your copter would still have fallen, in Stab mode, with low throttle. But it would have been slower, and right-way-up.
However, this kill-switch would be an optional feature. I do not think I can win the battle to make it the default. It would be up to users to set it up. It would also be up to the end user to utilize whatever physical switch they want. I can't write a program for that.
Neither can I write a program, which will prevent power system failure. That is why over-head flight will remain dangerous and illegal, until such time as these aircraft are engineered to the same standards as manned aircraft.
I don't fly over people's heads. I can only be held responsible for my own actions.
actually while GA doesn't exactly depend on "superior" engineering as I stated..
drones will have to exist that way to be accepted..
we have heard several excellent suggestions regarding this issue.
1. throttleKill/crashme having to be enabled separately after arming first.
(and convincing reasons why we SHOULD have a killswitch/crashme functionality just not coupled to flight modes).
2. lower limit to the fence where lowered throttle settings in stab/acro result
in lower throttle settings but still keep the craft flying but setting down
slower than a full crash..
3. locking off stab/acro mode transitions commanded by rc comms error no matter what the throttle settings.
4. tablet kill switch easy and quick to activate intentional but hard to accidentally activate
5. precedence/priority to control GCS contol transitions in a closed control loop aboard the FC ,
this code should not be in the GCS or RCTX which are NOT in a closed loop with each other and these transitions are uncontrolled at present.
6.(did I miss any?) please add to this list...
hzl
ps for what its worth I tend to think the killSwitch if implemented with the additional suggestions SHOULD be the default setup given the precautions around enabling this function for each takeoff/arming cycle(which?) manually each time or having the ability to enable in flight.
and on the flying over folks heads??
supposedly the TJPD purchased a couple of the 3DR X8 systems and are using them for aerial patrols over TJ...and definitely over peoples heads.. and they are NOT the only PD to do so... again its time to accept the reality of how people and city governments are using these products and code/SQA appropriately...
and to get all the flight safety rules we can stuffed into the aerial platform NOT the GCS which is NOT an appropriate place for interlock decision involving an Open loop controller(RC-TX) NOT tied closely to the GCS current modes and settings.
hzl
hilarious.. after I just replied to drones-discussion to you on GA aircraft.. wife turns on a show with what? documentary on crash investigation into GA crashes
funny how that works
hzl
That kill mode sounds like a damn good idea Rob. Perhaps 2 or maybe even 3 quick taps on the screen so no mistakes.
btw on the return to stabilize while in flight.. it can be allowed safely if the current throttle stick position >= current flying throttle setting .
hzl
-
17
-
18
-
19
-
20
-
21
of 44 Next