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:
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.
first 2 scenarios are relatively infrequent compared to copters dropping like a brick with sharp points(which WILL happen at present given how the system is released to the customer.)
You should not be flying ANYPLACE manned aircraft are at present until drones at least support collision avoidance or transponders or ADS-B
. so #3 should NEVER happen and indeed if done in the US would be quite illegal(felony level if air terror charges brought).
and again I remove my objections to a discrete and separate CRASHME function it it is NOT tied to stab or any other flight mode. and is delivered in locked off state initially..
The switches used on the RCTX should be of an interlock nature ie 2 switches moved at same time to activate CRASHME this will help to prevent accidental activation while in flight. and no flight/arming allowed while switches in the CRASHME position.. ie you cant take off in CRASHME mode
the 2 switches used should NOT be overloaded with any other function..
ie a covered top toggle switch with spring return(commonly used in firecontrol systems) would be ideal here or its modern day equivalent and would remove the need for 2 switches being used.
the above would seem to make sense from the flight safety aspect as well as the ground safety issue you and others keep bringing up..
hzl(who has had his share of out of control robotic aircraft) (paparazzi et al)
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.
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
My drone would do just as much damage falling on someone's head from 10m. In my mind this is just the logical conclusion of fencing - essentially a lower limit below which the flight controller takes autononmous action to keep your drone safe, and obviously something you can switch off.
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...
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.
How can I get the DEFAULT + CAM log on Pixhawk since using the suggested LOG_BITMASK : 32768 does not record like Default log do.
Below example of Log result using LOG_BITMASK : 32768
Because you're using a PX4, you should be able to leave the LOG_BITMASK at NearlyAll (i.e. 131070) and it will record CAM messages. I think the issue is that the camera trigger is not enabled. It only logs when that's enabled.
Thanks Randy (as always)..
Will try to use the NearlyAll (131070), but could not understand your point on:
"I think the issue is that the camera trigger is not enabled. It only logs when that's enabled."
Since I enable the trigger using DO_SET_CAM_TRIGG_DIST on flight plan and it's working fine triggering my Sony Nex5n.
Will also post another "weird" behavior related with above log on GPS Glitch & Heading error.
Ah, sorry. I misread what the issue was. I thought the CAM messages were not appearing but they are.
Please see log below:
Brief explanation on the Mission flight:
"Weird" behavior from my ground and log observasion:
I know this probably isn't the right thread to ask this question but I have the px4flow sensor with the sonar onboard (HRLV EZ4)... even though the flow sensor is in the process of integration with EKF for indoor/ non GPS loiter still in the meanwhile is there a way to use the data from the onboard rangefinder for sonar assisted landing and althold ...I figured out how to connect the sensor with the hawk via I2C but I would like to know how to get the hawk to read the range value and hold altitude accordingly...