Servers by jDrones

Large copter crash on take off pixhawk cube black

Hello all. this is my first post after months of using this platform to setup our copter.
we have been developing a quad copter for agricultural use with AUW 27KG. the copter was doing great on auto mode. loiter mode. lots of manual tunning was done and everything was going great until few days ago.

I was developing a way to resume a mission after the sprayer tank was emptied. basically the copter will go to RTL mode and return home. we take off the battery and replace it with full battery and also fill the sprayer tang. I simulated the situation while activating RTL while in mission and the copter landed perfectly. I removed the battery and connect it back again. I went to MP and pressed resume mission. it warned me that all the arm and take off commands will be overwritten. it asked me for the which WP i want to continue and the default was WP20(where i activated the last RTL). then the flight plan was received by copter and before even taking off the copter flipped over and all the props were damaged.
I have been checking out the logs and tlogs but didn’t find any reason to justify the crash.
the new mission that was written also had no issues as the take off command to 3 meters was there.
I have attached the TLOG and bin file. the bin file is for the time that I restarted the battery and immediately after that leads to crash however the TLOG is for the entire flight I had,

I’d appreciate if I could get some insight from you all. thanks in advance

copter info
P80 TMOTOR
30 inches props (RIP)
copter 4.0.3
quad frame with sprayer tank

bin file
https://drive.google.com/file/d/1--sa7FL-LcBzO0X-7cXtJ23imZrKwDez/view?usp=sharing
Tlog file
https://drive.google.com/file/d/1etvLLJeewXWQmHW3tA9nRvoPmWoJ8hGv/view?usp=sharing

crash param.param (18.2 KB)
crash wp.bin (2.5 KB)
change the WP format to .waypoints as I couldnt upload it.
this is the wp after I resumed the mission and just didnt take off and crashed. the wp looks fine to me though

Could have been a desynch or failure of M4 on takeoff.
Do you have a log from a ‘normal’ flight?


At the point of takeoff all motors went to max but M4 stayed there while M3 was cut to compensate.
The desired v Actual shows the FC was trying to do its job.

Could a leg have been caught on the ground or M4 just failed to spin up?

Thank you for your reply.
The thing is crash already happened before the mission 1 which was take off could’ve taken place. And if you see from the graph all the motors were working right before the crash. This all happened in 3 second. 1 second to flip then the mission started. FS was activated and motors were disarmed.
I’ll post a normal flight log tomorrow when I go back to office. Everything was fine. Did hours of missions in auto mode. But had never tried the bloody resume mission.
I’m starting to think something was wrong with the command sent in guided mode. Because that’s where the crash happened. And why all the motors working in max when taking off. When you see my other logs you’ll notice all they need is about 1500 to take off and once hover it’ll go down to 1450.
That’s really bugging me right now. Aside from the fact that 700 dollars worth of props were destroyed. I just wanna figure out this issue to avoid it in future. Could it be MP bug in guided mode scripts maybe? I wanna get to the bottom of this.
Anyway I’ll send you a normal flight log tomorrow.
Thanks again for your reply.

Oh btw my take off location was clear. There was no way anything could have pull down the legs. Oh and the pos hold and alt hold you see there is me panicing and pressing random buttons once the crashed happened already

Hi Jack,
I am sorry for your “accident” , while I don’t exactly understand the root cause of the problem, but lesson learned from this accident will prevent similar problem in the future. Here is what I learned:

  1. Always simulate the mission using SITL before actual flying to make sure that all steps are correct.
  2. Don’t power off the drone while changing battery. So we must use at least two battery packs in parallel. So, we just disconnect one battery to change with a full one, then change the second one. In this case the drone keeps getting power ON.
    That is just my logic of thinking what I will do before knowing exactly the root problem. But to be honest I have not tried to do changing battery during a mission.
    That is just my 2 cents…
    Tony

Or just power the Flight Controller from the USB port…

Yes, that is one key point, to implement triple redundant power supply for the FC, one BEC to Usb port and two BECs to servo rail…

BEC’s need a power source, I was suggesting either a laptop or a small power brick just to keep it alive while changing the batteries. But I suppose there are a few strategies you could use.

Thanks everyone for your support.
actually I did use the simulator before the flight and it went well. but I still can’t understand the reason why should this happen. check out the logs before the crash. I did a mission and did RTL.
could this be a bug in mission planner? should we avoid using resume mission? this is one costly issue.
so if we keep FC on during changing the batteries the issue would be solved? This really isn’t and optimal resolution.

https://drive.google.com/file/d/1BVJl8rOqUgVMibr_vO0PACzKyIoqDf5x/view?usp=sharing

Hi.
Have you any video of flying your drone ?

Correct. A simple way to do is with a power bank (18650 inside):

  1. Connect the power bank to the controller.
  2. Disconnect the discharged battery.
  3. Connect the charged battery.
  4. Disconnect the power bank.

If having accessibility problems, attach a micro USB extender.

Anyhow, check that accelerometers and ESC’s are calibrated, so that all motors start equally when horizontal.

https://drive.google.com/file/d/1k6-_9GxikelThFwAMX5bToOyfcObVzO3/view?usp=sharing
here is the link to one of my auto flights

https://drive.google.com/file/d/1Ky39FFSkeuMm4QzA2aVuDdPr8DKB4663/view?usp=sharing
here is log file for this

1 Like

Anyone else have any comments or idea about this?

Yeah, it just hit me now.
Whenever I’m in a mapping mission (usually at 180m altitude) and see air traffic or receive a tower call, I switch to loiter and descend to 50. After it clears, I have to manually climb back to 180, otherwise resuming Auto will gradually climb to the next waypoint, affecting photo coverage.

I think the way you did it lacks the initial takeoff to altitude command, and since spraying is at very low altitude angle of departure is too shallow and it flipped.

[LE] I re-read your op, and you say the take off command is there. I’ll try this in my backyard.

Thanks for your reply. I’m gonna try it again on Monday. With a small copter running same ardupilot 4.0.3. The only difference in my test would be that the small coper wouldn’t be having lidar as primary source of altitude like Mt large copter

I 'm also pretty sure that this is what happened. I experienced it in another context long ago by having my drone on the ground landed and flipping the Auto mode on. However I had a wrong take off first WP with 0 in altitude… So the drone reaches the first way point (which is supposed to be take-off) immediately or too quickly before trying to the newt waypoint, still resting on the ground. That makes your drone flip obviously.
In your case you say you had a take-off command to 3 meters as a first command. But 3 meters is right in the barometer “imprecision”, especially after you have flown just before ( zero altitude resest point is not correct anymore).
You probably would not have had this issue if the take off altitude were to be much higher than 3 meters.

Just a tip on using two batteries in parallel.

Changing batteries while keeping the power to the craft live requires knowledge of what can happen and how to avoid it. This is how we train our pilots on how to hot-swap batteries in parallel on our Nexus LiDAR UAV.

After a flight, land with two discharged batteries.
You CANNOT just connect a fresh battery to craft with a low one attached.
What happens is that the power from the full battery rushes in and can over load the low battery.
This will over discharge the full battery, and over charge the low battery.

Our solution only requires a small jumper that you make up. The jumper is a 6amp fuse and a diode to control the power flow.
When you land with two low batteries you unplug one of the low batteries and attach the jumper to the low battery and plug it back in which keeps the system running. Then unplug the other low battery.
Then you leave the battery with the jumper keeping the system running and you plug in the new fully charged battery. Because you have a 10amp Diode and the Fuse connected to the low battery the Diode prevents the voltage from going back to the low battery. For those of you who do not know, a Diode is like a one way valve for power.
Once you have the new full battery attached you can remove the low battery with the jumper and then put on the new fresh battery.

The reason for the fuse is for safety, We would never allow customers to work on a system with full power to the motors. This way if for some odd reason, and they happen, the motors start up, the fuse will blow and the power is killed before the operator :slight_smile:

@Infinite, Yes this is 100% correct. Sorry for not talking about this issue on my previous post… Another alternative simple way is by using small power bank 5V that is connected to the Pixhawk USB port, to keep it alive… And give a power redundancy for the Pixhawk.

Or we can use the altimeter as @JackJavan’s drone, is it right? Since the problem may come from the error of barometer when working in low altitude. Alternatively, a very convenient way as @Infinite provides is helpful in case of using dual battery.

Servers by jDrones