Throw Mode Failing on Occassion

ArduCopter Copter 4.3
1

Every so often Throw mode results in an uncontrollable aircraft that cannot maintain attitude or altitude. Unique situation is that unit is being powered on while in motion on another aircraft and then released after several minutes. Have tried several modifications to the code to try and reset any accumulated errors. There has been some improvement, but still the occasional flight where unit does not operate safely. See additional details in uploaded text file and in data file link referenced below:

Altitude and Attitude Confusion when recovering from Throw mode.txt (5.2 KB)
.
File 46 - THROW mode challenge

Any thoughts or insight is greatly appreciated.

Thanks in advance.

2

Have you disabled IMU calibration on boot? IIRV it is discussed in the boat takeoff section of the documentation.

3

I wonder if having it in unstabilized (Trainer disabled) Acro mode before switching to Throw would help?

This reminds me of a similar application from a few years ago with a dropped Paraglider drive unit which was essentially a large quad copter. The scale model testing can be seen in this video:

Drop, Throw, RTL

4

I don’t think so, if IMU biases are misestimated there will be issues even in acro.

5

Thanks for the suggestion. We have been flying with INS_GYR_CAL = 0. But after looking at the process we have been following, I don’t see where we have flown with INS_GYR_CAL = 1. We do all the calibration steps as part of the build process but our default parameter load starts with it set to 0 and it is never turned on.

6

There is a bunch of stuff that doesn’t make sense in the height controllers that make me think that there have been some significant changes made in the position controller. I can’t help you here without a link to the git repo.

7

We built on a baseline of 4.3.7. I don’t believe we’ve made changes to the position controller code, and I’ll need to have our SW engineer provide the link to a proper repo. For now, I can provide a link to the files that have been changed…primarily steps within mode_throw.cpp to automate arming and change Throw detected to a timer event. Additional changes still in the code that were made while looking for ways to isolate the problem include adding some timers to make sure throw_attitiude_good and Throw_HgtStabilise persist for a bit before transitioning to the next stage. These latter changes do not appear to have aided or made worse either the altitude or attitude symptoms we have seen. Also, to support those timers, three additional parameters were added.

[NOTE CORRECTION ON CHANGED FILES IN SUBSEQUENT POST]

8

I am seeing what appear to be mismatches in logging outputs for height suggesting something has been changed in this chain. It isn’t worth looking at this further without the full code base.

1 Like
9

Understood. I’m working to make it available. Thanks for your help and patience.

10

The full code can be found here: Full Code Base

A compare for all modifications can be found here: Compare of Changed Files

I need to correct a misstatement in an earlier post. Additional files have been changed.

When making changes to the code base or operating procedures, the build-up testing includes “self-throw” which includes launching from the ground and flying to altitude before disarming, moving into Throw mode, and rearming to confirm the unit would recover. Only after it passes that test is a unit moved into airborne arming and releasing. Rarely, but occasionally, during the “self-throw” testing a unit will not arm as expected. Changes were made to additional files so that the unit would still report any failure to arm but then force it to arm anyway. In the BIN file referenced earlier in this thread there was one of the rare events where there was an arming problem, but the modified code forced arming anyway.

By necessity, this self-throw testing requires the unit to disarm, change the mode to Throw (done via script), and rearm while dropping from the sky. The changes mentioned above were considered helpful because the unit would either crash because it never armed, or we could force arming and hope for the best. Most times there is no problem arming and the unit flies well.

More recently, for units that are carried into the air by another aircraft before they are powered on and released, the process was changed to place them in Throw mode and arm them before they are released rather than waiting until they are released before switching into Throw mode and arming.

It is quite possible that the changes made to force arming during a self-drop are the root cause of this problem when performing an air-drop.

In addition, to the attitude difficulties with the previously posted file, another file has been posted that exhibits an altitude problem when operating in Altitude Hold mode after Throw. While waiting to acquire solid GPS the unit started ascending rapidly. Plotting CTUN:Alt seems to indicate that the unit thought it was descending at a very excessive rate, even before it was released, and was ascending in an attempt to maintain altitude. In this file there appears to have been no issue with arming. There are also instances where a unit will descend as fast as possible, thinking it is climbing, and others where a unit alternates between ascending and descending as fast as it can, alternating every 10-15 seconds until GPS is acquired.

Not sure if the two problems – altitude and attitude – are related, but both are quite sporadic and exciting when they happen.

The file exhibiting the altitude problem can be found here:
Altitude Hold Problem BIN File

11

The second file is an estimation problem with the EKF. Both EKF have no idea what height the aircraft is at.

I am not convinced that there are not more changes to the code run in the first log because the PSCD messages isn’t being logged but it looks like it should be because the Z controller is running. I can’t work out why it wouldn’t be running.

In any case, the aircraft is level and all motor outputs are near maximum and the aircraft can’t maintain altitude. I suspect Motor 4 has desynced or stopped. Maybe the propeller is loose.

It looks like you also can’t regain control in stabilize.

12

On that second file, what would cause that? We booted up in a moving aircraft and the baro shows a fairly steady altitude (GPS was off), which is consistent with the host aircraft flying at a steady altitude. In this case, moving to stabilize does allow us to control flight and land safely. After landing we performed a ground launch and it worked fine and has since had over a dozen in-air boot-and-launch events without an error.

Regarding the first file, we’ll try rebuilding from this repository and confirm we get the same APJ as was loaded on the aircraft. One thing I found odd in reviewing this file is that during the period when things were going poorly, from 00:01:55:00 to 00:02:00:00, just before we determined Stabilize would not work and we shut down the motors, ATT.Pitch and ATT.Roll remain and average nearer 0 while AHR2.Roll (9 to 20, ~15) and AHR2.Pitch (-46 to -25, ~-35) are significantly tilted and represent the observed attitude of the aircraft. I don’t see that same degree of mismatch when I look at files where the launch and recovery in Throw mode went well.

13

We performed a thorough review and confirmed that what is in the posted repository is an accurate and complete reflection of the code base used for building the APJ file for the flight in question.

We also checked all motors and props. Though there was some damage to the frame of the aircraft, all motors spin freely and all propellers are secured tight to the motors.

14

Just having a quick look at log 28…
There does seem to be an issue with the effectiveness of the props and motors. For a steady altitude they seem to work OK, but any attempt to arrest descent causes motors to go to absolute maximum output. Granted the altitude changes can be 10 to 50 meters, but you might need something that can handle that load better.

Vibrations are a problem, and this may be affecting the position and altitude control.

It seems arducopter is expecting more usable info from the GNSS unit, and not relying completely on the barometer. This and the vibrations makes the fused altitude almost useless. You may need to adjust EK3 setting to either rely totally on baro for altitude (which could be bad since the final altitude is like -350m) or get the GPS altitude working more reliably.

The GNSS unit is going to need work to be more reliable. Yours was not showing any Sats or usable HDOP until long after the recovery from throw. I understand the copter is upside-down (roll 180) before being released.
Maybe you could do something with small GNSS units, one on top and bottom so at least one would have a chance. I think Tridge uses the F9P units on planes for acro flying and they seem to work upside-down at least for some period of time.

1 Like
15

Shawn,
Thanks for taking a look. A few notes based on your comments, in reverse order….

The GNSS works great, but prior to being thrown the unit is physically blocked from receiving GNSS signals. In order to not prevent the GNSS from providing bogus data to the EKF processor while it is establishing its position we set the EKF so that is does not use GNSS until after GNSS quality can be validated. We also permit moving into Altitude Hold mode after Throw completes, permitting the unit to at least maintain altitude while a valid GNSS signal is being established.

I agree we have some work to do on reducing vibration, but what we are doing now works 95% of the time and in some test cases we intentionally create more vibration on the system just to check performance limits. Increasing vibrations does not in and of itself appear to cause this problem. Also, the inconsistency that may be at the root of this behavior seems to start when vibrations are near 0 and motors are not even spinning.

While waiting for the actual Throw event to occur, CTUN.ALT starts showing a descent of up to hundreds of meters per second while the aircraft is at a static altitude. The motors go full speed when trying to maintain altitude because even though the unit is properly being reported by the barometer as ascending (consistent with what was observed by the RPIC and VO), CTUN.ALT thinks it is falling and demands full motor speed to maintain altitude it errantly thinks it is losing.

I think what we are looking to identify and resolve happened earlier in the process.

16

You could try feeding the payloads carrier GPS through MavLink GPS backend. This way EKF will have good position estimate before release and should even be able to sustain position control while drone is catching GPS.

17

How about throw mode without GPS lock? Perhaps with flow/lidar, you’d have a bit more redundancy?