Hi, just wondering if anybody could help analyse my log file. This Pixhawk is on a large quad running TMotor U8 motors. It has flown now over 10 hours in the air with no problems. Today, while climbing to altitude in auto the quad rolled over and crashed while passing 60m. After reviewing the log, it looks like the quad was struggling to climb to height (THROUT) pinned high. The quad climbing into a 15 km/hr wind and for the first time I bumped up the waypoint speed to 7 m/s from 6m/s.
Would really appreciate someone with more log analysis experience than me to take a look. Has anyone seen an issue like this before?
Thankyou.
Replies
GocGoc,
I've had a look at the logs and as you say it appears the quad was struggling trying to climb. I suspect the battery or ESCSs weren't able to provide the required current for this extended period of time and they shut down.
This isn't related to the false-positives we're seeing on the landing checks with AC3.2. We know that because in the false-positive cases we see a landed event in the log. These logs have a landed event but only at the very beginning of the log, not at the time of the troubles.
Thanks Randy for taking the time to look at my data. Still a little lost though. I have bench tested these ESC's and motors under load for 5 mins continuous running, the motors at full throttle only pulls 16 amps and I am running TMotor 30 Amp Pro Esc's. My quad was definitely struggling to climb in the wind visually and from the graphs but can you tell me why the Pixhawk decided to drop power to the motors as evident by THROUT. I would of thought that the Pixhawk still would of been trying to maintain full power throughout this event? What am I missing?
GocGoc,
I think we can't see everything in the log. In particular we're missing the acceleration which is what the lowest level of the althold controller uses (if IMU was enabled we would see it but that puts a heavy load on the APM2.x's CPU). I've put a thin yellow line at the moment the throttle drops but it's hard to see if the vehicle is accelerating up or not just before this period. Also sadly the desired climb rate doesn't seem to be displayed in the CTUN message so we can't compare the desired vs actual.
Thanks Randy and Andre K for you input. Randy I am flying a pixhawk, what bit masks to you recommend I use to log the data needed to analyse ay future issues? Hopefully the new 3.2 code as rectified what ever happened.
Today I flew 2 40 minute flight still on rc5. Tested, Auto grid missions, spline waypoints, guided mode and auto tune all with EKF on. No issues at all, noticed 'pitch up' jitters as the quad passes spline waypoints.
I conduct quite large mapping missions, takes quite a lot of time and energy to pull up, turn, then accelerate to the next waypoint, loved the spline waypoints, does anyone know how we can program spline waypoints into Auto Waypoint Grid v2 function?
GocGoc,
I think setting the LOG_BITMASK to "NearlyAll" is best for Pixhawk.
The twitch as the vehicle goes through spline waypoint is fixed in -rc6.
To get the auto waypoint grid v2 to produce spline waypoints will probably need an enhancement from MichaelO. Easiest way to alert him to the request is probably through the MP's issues list. You could manually go through the mission and switch all the regular WPs to Spline waypoints although it would take some time.
Excellent Thanks Randy
Note that when it "fails to climb" , near line 3000, and 3600 , in both cases your groundspeed is above 7.5m/s
the ability to maintain speed seems to be below 7m/s - also, remember that headwind reduces that number.
The priority of maintaining altitude over groundspeed is implemented in 3.2 , not 3.1.5
When throut goes to zero near line 3810 , your roll passed 80degree. - and that's the cause for it to cut throttle.
It seems to me like it had a stable trajectory, that maintained a attitude where throttling up was wrong. it would have been interesting to see if RCOUT tried to flip it back. (do we have code for that anyway ?)
Thankyou Andre for taking the time to look. I have 2 independent 5v supplies to the Pixhawk. Can you tell me what item you were looking at to give you this information so I can take a look. Since this issue I have been learning lots about log review and I really need to get to the bottom of this one before I fly again on another job. I see the Quad was trying to maintain its climb profile where the ThrOut was sitting at maximum but the machine was still slowing defending, then the throut dropped to zero and the quad rolled over and dropped.
It was windy and it was on climb behind maybe a turbulent hill but it still should not of done what it did.
Was the pixhawk trying to maintain its climb rate and my higher nav speed and simply fail against the conditions. I did hear it working hard and not climbing....
I do think the 3.2 Beta's have solved a lot of issues, hopefully this is one of them.
oops, my bad , that conclusion should have been posted on another case, I must have let a browser tab with your case open.
There is no sign of power causing any problems in your log.
In your case, I see no reason for ThrOUT to go low in line 3821 , yes, you may see a GPS altitude spike of 730m , but that's when it's tumbling down and are more upside-down .
your DesAlt is't even reached, and remind high during the fall.
I hope you can get a dev or somebody else to take a look at it, I miss the RCIN/Out data a little, but a misconfigured RX failsafe could not have trigged this alone (not while in AUTO mode)
for what it's worth - I havent seen such problem in 3.1.5, nor read any commits that may indicate a fix for something like this.
Thankyou Andre, is it possible to log RCIN and OUT data?
-
1
-
2
of 2 Next