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.

Views: 57438

Reply to This

Replies to This Discussion

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..

     comments?

     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.

    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

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...

       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.

Hi Randy,

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

Log File using Log_Bitmask 32768

Hey Waladi,

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.

@Waladi,

Ah, sorry.  I misread what the issue was. I thought the CAM messages were not appearing but they are.

Hi Randy,

Please see log below:

TLOG

Pixhawk Log


Brief explanation on the Mission flight:

  1. Mission with trigger by distance and Log_Bitmask: 32768 (so not all info recorded on the log)
  2. Y6 copter with dual Neo-6M gps
  3. Cloudy day with good GPS sat & HDOP
  4. Strong wind during the mission

"Weird" behavior from my ground and log observasion:

  1. GPS_Glitch error several time during the mission
  2. Assuming when the GPS_glitch error occure, the copter was spinning around but still following the path of mission moving toward the destination waypoint but the heading was spinning or pointing other directions so you can see the copter was moving side-ways, backwards or normal head-on (by playing the TLOG on MP).
  3. Assuming when the GPS_glitch error occure on Main GPS, the second GPS was take over and it was working flawlessly guiding the copter to the right waypoint locations, but doesn't auto-correct the copter heading.
  4. Assuming Compass on Main GPS was still working to provide directions for the copter and assuming Pixhawk not using second Compass (internal Pixhawk compass).

Questions:

  1. Are my assumtions on point 2 & 3 above correct?
  2. Why heading on the mission was not pointing to the next waypoint? assuming second GPS take over during GPS_glitch event.
  3. Why during the GPS_Glitch event, I didn't saw the warning on MP HUD for Bad Position as describe on GPS Failsafe and Glitch Protection wiki page: "During a glitch, “Bad Position” will be written on the ground station’s HUD"
  4. How the copter heading can be corrected pointing onto next Waypoint as soon as second GPS take over during GPS_Glitch event? because this behaviour messing the image captured (image orientation vary on the same mission line) during mapping mission flight.
  5. Will it improve the situation if I enable EKF protection?

Personal Conclusions:

  1. Alhamdulillah Thank God and dev team for GPS Glitch protection algorithm that allow my copter fly and landed more safe and avoid lost in cost and perhaps lives.This is real live proof that the protection is working flawlessly.
  2. Always use top quality GPS as main unit and save money to buy second gps.
  3. Room for Improvement: auto-correct heading when second GPS take over.

Many Thanks.

Waladi

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...

Reply to Discussion

RSS

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service