I am new to the Pixhawk System and to this forum and looking desperately for help in analyzing the crash log from this weekends flight. I am running a BORMATEC Explorer with Pixhawk SW Version 3.0.0 Arduplane. This weekends flying ended in a total loss of the frame of the plane due to what has been perceived of complete loss of maneuverability. Fortunately Pixhawk and electronics are still ok. We have investigated the servos after the crash and after the plane has been retrieved and they worked perfectly. Flying procedure and fail in chronological order:
Start went perfecty (manual mode)
First turns went perfectly (manual mode)
Percieved lock of steering shortly after start (ability to not turn right anymore)
Tried to switch to Stabilize Mode without effect and going back to manual
Loss of control and crash
As this crash ended in a estimated loss of approx. 700 Euro I would be very interested to know what happened precisely. So far I liked the concept of the Pixhawk and the APM (have a Bixler equippend with APM as well and never had problems) but unless I can get out the root cause I am seriously considering switching the system. I have attached the Tlog of the flight (attached) and have recorded the flight with a GoPro 2 as well (Full Video can be provided if needed).
I am looking for someone that can give me a hand with analyzing the log and probably point me to the root cause of any error visible in the log. I have attached the tlog of the flight below and would be very thankful for any member here that can help me in analyzing the log and point me to any error.
Hi Locoracer,
Sorry about your crash!
It looks like your main problem was your power supply. How were you powering the Pixhawk?
Here is a graph of your board voltage and servo voltage over the log: http://uav.tridgell.net/Users/locoracer-power-status.png
As you can see, the board voltage drops to 4.2V with occasional drops below 4.0V. If it reaches 3.8V then it will reset the Pixhawk. I strongly suspect it did reach 3.8V (at which point it would have rebooted, and stopped logging). It if reset then it would have come back up with the safety switch off.
You need to look carefully at your power supply. I very strongly recommend you use the supplied 3DR brick power supply with your Pixhawk, and make sure your battery is fully charged.
One strange thing is your logged battery voltage: http://uav.tridgell.net/Users/locoracer-voltage.png
It shows you started with over 12V, but then dropped to less than 5V. Did you connect a 5V supply to your board? Maybe the wrong battery?
Cheers, Tridge
Thanks a lot for providing me help here. I am not using a separate Power Supply but the one that came with the PixHawk and using 2 x 3S Batteries in parallel for flying so the Pixhawk gets Powered directly from them (trough supplied Pixhawk Power Connector with Power Cable). Could of course be that the board could have an error, I do have a second one that I can use. The Batteries have been found disconnected after the crash. Do you see any other strange anomalies? How much time went by until the voltage dropped from 12V to 5V?
Hi Roland,
Looking more closely at the log it is clear that the strange voltages are after you’ve brough the airframe back to the start location after the crash. Perhaps you powered it differently then? The voltages are certainly very strange. It looks like you plugged a 5V battery into the 3DR brick power supply?
The tlog is missing some critical sections where you lost telemetry (you had a very high level of RF noise, leading to very poor radio range), and also doesn’t provide high rate sensor logs. Do you have the logs off the SD card?
Unfortunately you had set LOG_BITMASK to 8062, disabling a lot of the logs on the SD card (can you tell me why you did that? Did you perhaps just copy someone elses parameter file from an APM2?). That means the SD card logs won’t have the really detailed IMU logs that would allow a complete detailed replay of the flight, but it may give some clues. I can try and piece something together if you post the SD card log.
Cheers, Tridge
After we have brought back the airframe we have only connected one of the 2 batteries. Maybe this is the reason for only seeing 5V but strange as well as they have been connected in parallel…
With the fabulous manual of how to gather the logs from Pixhawk I went to work some minutes ago and I have attached them in the below file. Could verify with the KMZ File that they belong together as its obviously displaying the death flight .
I assume that LOG_BITMASK to 8062 has been set since I have ordered the plane built by the manufacturer and I do believe this is the first one built with the Pixhawk as I have requested it instead of the APM. Therefore I assume he copied the settings from his APM “template”. Would you mind to advise how to set the LOG correctly. As the frame is on its way I want to make sure everything is at least correctly logged for the next flight .
Hope you can find something in the logs…
Again, thanks a lot for your help here. Big time appreciated.
[quote=“Locoracers”]I assume that LOG_BITMASK to 8062 has been set since I have ordered the plane built by the manufacturer and I do believe this is the first one built with the Pixhawk as I have requested it instead of the APM. Therefore I assume he copied the settings from his APM “template”. Would you mind to advise how to set the LOG correctly. As the frame is on its way I want to make sure everything is at least correctly logged for the next flight .
[/quote]
The Pixhawk was pre-installed by the manufacturer? Could you put me in touch with the manufacturer?
When a manufacturer pre-installs an autopilot you normally expect them to have pre-configured it with the right tuning for the airframe. I notice that the configuration on your airframe was clearly not tuned yet. I had assumed this was because you had just bought the Pixhawk and hadn’t had a chance to follow the tuning guide yet. If it came from a manufacturer like this then they really should have loaded tuning values for the airframe.
ahh, sorry, I should have been clearer in my last message. I meant for you to send the log files directly off the SD card, not interpreted through mission planner. The raw *.BIN log files have more information in them.
I can get a fair bit from this .log file though. I’ll have a look at it.
Cheers, Tridge
never trust anything RTF.
Bormatec isn’t exactly pinnacle of safe flight, they delivered tail with elevator prone to ripping (you should use proper hinges )
Generally I dont trust RTF and I have done the full set of checks and calibration prior flying. I thought that due to the flying characteristics when loosing control that there could also have happened something with the tail or elevator. As written, Steering of the plane was increased difficult if not impossible. This behavior is also typical when elevator has moved to a side. Unfortunately the tail was half destroyed when we have recovered so proper analysis was impossible. Anyway, you need to get the stuff in the air to discover any error and failing forward is not only part of this hobby but should be a credo for life . Now looking primarily forward what the analysis brings…
[quote=“Locoracers”]I have attached now the .bin files directly from the SD. Hope this helps further in investigating.
[/quote]
yes, there is some interesting things there, although because of the LOG_BITMASK setting some important data is missing.
The key thing is that the plane went into RC failsafe at the end, and switched to CIRCLE mode.
When it did that it produced this message:
This was a part of the flight that was not in your tlog telemetry log, as you had enough RF interference that your telemetry link was lost.
the “MSG FS ON 1053” means that your throttle channel was at 1053 at the time it got the failsafe. That is above your THR_FS_VALUE of 970, which means that it must have been a loss of PPM frames from your receiver.
At that point in time you no longer had RC control of your aircraft (as your receiver had lost contact) and your plane was starting to circle, while trying to hold altitude, waiting for you to regain control via RC.
Unfortunately your plane did not manage to hold altitude in CIRCLE mode and descended into the ground. It looks like there were several reasons why the plane did not manage to hold altitude:
the roll and pitch controllers had not been tuned. They were all set to the default values, with no integrator. So the plane did not manage to put in enough up elevator to keep the nose up, and did not manage to put in enough aileron to keep the roll at the desired bank angle of 10 degrees.
To really confirm this I would need the RCIN and RCOU logs, which would show the RC channel inputs and servo outputs. Unfortunately those were disabled (along with the IMU sensor data) because of the incorrect value for LOG_BITMASK.
your battery ran out. Here is a graph of your battery voltage for the CIRCLE part of the flight as the plane descended into the ground: http://uav.tridgell.net/Users/locoracer-circle-voltage.png
As you can see it started above 12V, but got to below 8V at the end of the flight. That is a very dead LiPo!
Before you fly again I’d suggest you check your power supply very carefully and also read up on how to tune the PID values in APM. We are currently developing an AUTOTUNE system to try to make this easier.
Thanks again for your great work on this one. I do have some comments from my side:
I understand that the plane had gone into FS. In the last several second of the flight we have had also lost sight to the plane due to the nature of the terrain. It was in fact behind a hill already so I understand going into failsafe due to loss of packets.
I also understand the circle more due to that and in the end the crash as a consequence of a non tuned frame
The plane crashed and the LiPos got thrown out from the frame (both of them). I see the 8V being a very short period of time so could it be that this was the point of impact?
Now the situation was that we in fact lost control already in the first minute when the plane was airborne and I do not have any explanation to that. So in fact I have gotten into the end state due to loss of control already in the very beginning trying to manually correct the movements without success. Do you have any indication on something strange before it got into FS mode?
[quote=“Locoracers”]Now the situation was that we in fact lost control already in the first minute when the plane was airborne and I do not have any explanation to that. So in fact I have gotten into the end state due to loss of control already in the very beginning trying to manually correct the movements without success. Do you have any indication on something strange before it got into FS mode?
[/quote]
Did you have poor control also in MANUAL mode, or only in STABILIZE mode?
If you had poor control in MANUAL mode then the most common reason is incorrect center of gravity or incorrect control throws. In MANUAL mode the Pixhawk passes all controls directly through to the servos, so the normal RC plane rules apply (good control throws, good throttle control and good center of gravity).
I’d also recommend that FBWA is a much better mode to use instead of STABILIZE. The FBWA mode is the recommended mode for tuning APM. See the documentation pages for an explanation of the differences between the modes.
Cheers, Tridge
Yes absolutely have had poor control already in manual mode within the first minute of the flight. I first tried to assess the behavior of the plane and I have experiences impossibility of steering to the right (this happened approx. after 30 seconds after the start and kicked in suddenly). I have given more throttle to make the plane more maneuverable and then decided to go into stabilize mode to see if the Pixhawk can support me in steering. I know it might not have been the optimal decision but this all happens within 10 seconds. Control was still at the same level in stabilized mode to I reverted back to manual.
Center of gravity was spot on and has been checked before the flight. Also throws have been checked before the flight incl. stabilization (this is normal behavior for me before flying). Also manual control worked fine before the first turn.
.
.
