Hi all,
I had an accident with the drone, and I’m struggling to find out the cause of the crash. The drone landed using precision landing with a companion computer ( using guided commands, which can be seen in GUID tab in cm/sec).
The drone landed on the surface, started to reduce throttle, and suddenly got a high desired pitch ( around 30) from an unknown reason . It flipped vertical and went off from the surface.
I can see in the graph some things:
1- The drone does not know it has landed-> If you look at the graph although you can see that it is not making any attitude change(Drone on ground), the control is still active, if you look at the altitude it is still dropping and the control is still drifting and integrating, in fact you can see that it is trying to follow the reference(it is not doing anything wrong).
2-The same you can see in the second AHRS graph. In my opinion, when you have landed if it is a moving structure you should tell the drone to disarm the motors because if the surface is unstable, things like this could happen.
As an additional comment, I think the multicopter is very reactive and over oscillates too much on its reference.
ALPetrus, thanks a lot for your detailed explanation! We don’t use a moving surface, but a fixed one. It’s a flat plastic surface, and it can become a little bit deformed/inflated due to hot weather. Any ideas about any action we can do to prevent extreme behavior of the drone on the surface, and make it disarm quickly? ( without using RC control).
The commands come from an onboard PC inside the drone, connected to the Pixhawk4 FC through TELEM2. The commands are sent in Mavlink2, and the device make decisions based on what it receives from sensors on the surface.
We use ArduCopter firmware 4.0.3. We saw there is a bug fix in 4.0.4 in the land detection, relating to the vibration filter, however we received similiar results even after we upgraded to 4.0.4 .
Here is a link to another flight log. We have descended the drone in loiter mode to ~0.5 meter above the surface and then switched to land for the final phase. In this scenario, the drone was not controlled by an onboard PC.
Looking at the AccZ values, my arm chair qb makes me think the landing detector didn’t detect the landing. Back a few years ago before the crash check was added or updated, can’t quite remember but I had an idea (don’t confuse me for a programmer! ) that used a weighted trailing avg with a small timeslice to detect an impact. I tried to code a routine but I couldn’t figure out where to get the data from. It would have to be unfiltered accel data. I didn’t really know enough to design something like, but I figured it would be good to add as sometimes the crash detector doesn’t quite catch crash events. I think at the time it was using something like a variance of > 30 deg from commanded pitch and roll for more than 2 seconds. I know a lot of times the only big spike on my accZ graph is the landing or a crash so seemed like a reliable way to determine if it wasn’t in the air anymore. But then Randy said something to the effect that a itchy trigger crash detector would going off in flight would be a very bad idea so I kind of gave up on the idea. I think what got brought up usually after that in the forums when such an issue arose was to set up the motor interlock or take over with stabilize and kill the motors with the throttle (which is the route I’ve gone) but with commanded landings as OP has, has to rely more on the landed flag being set when it really has landed. With the hairy thing being you really don’t want it going off accidentally. Wish I could help, ran into this myself a few times, but I don’t have a good answer.
So the way the landing code works is that in the past it was based off of detecting the thump via the accelerometers of a landing but this proved to be a bit problematic in certain cases. Nowadays landing is detected as the inability to drop altitude for a certain time. And then a second check (I could be wrong about this) is for the bump. This would happen in the Z direction if the drone was straight and level and your auto pilot was installed in a default orientation. So I’m going to assume that is the case. Just looking at your accelerations I would say you have a moderate vibration issue. I forget what the specs are as I have not done multi rotors in a while but go to the multi rotor documentation do a search for landing and read the landing logic as it is currently coded. The potential problem that I see is that your drone has so much vibration that it is unable to interpret a landing. As far as altitude detection goes that can be thrown off, especially in multi rotors, buy ground effect or poor placement of the auto pilot itself. The internal barometer‘s are nothing more than pressure sensors and wherever that pressure comes from it cannot and will not care so if you fly long enough and a storm front comes through with a different pressure your drone will interpret thatChange in pressure as an altitude change when in fact it is not an actual altitude change.
So the short and sweet answer is figure out what is vibrating so much on your drone, check that you are not in any propwash, see that your rotors are tilted somewhere between one and 5° skyward in order to help dissipate the chaotic motion of ground affect. You can also shield the entire auto pilot which will help stabilize rapid changes in pressure but will still be able to detect actual pressure.
Another thing that I would highly recommend for you is that, as I understand it precision landing is just ex and Y coordinate accuracy it does not aid at all in altitude. To combat this I would highly recommend an infrared or laser sensor that kicks in a right around 20 to 50 feet of actual altitude. On my aircraft it is an infrared sensor plug directly into the auto pilot and it understands mav link It gives me altitude accuracy when under 20 feet two decimal places in centimeters. I have no doubt that this will solve your landing issues.
If you go to the landing sensor route do not use sound sensors has ground wash bounces the sound waves and can cause inaccuracies please use infrared or laser only.
Summary: check auto pilot placement, fix your vibration issues, shield your auto pilot from wind and propwash, and most definitely add an altitude sensor that is not sound driven but rather infrared beam or laser only. Oh and don’t crash.
bigler, the ATT.Pitch, ATT.Roll and ATT.DesRoll, ATT.DesPitch look like the values go up quite a bit around the time of the landing. Chad’s post on the workings of the crash detector got me looking at the code again. The crash detector routine has this at the top
// Code to detect a crash main ArduCopter code #define LAND_CHECK_ANGLE_ERROR_DEG 30.0f // maximum angle error to be considered landing #define LAND_CHECK_LARGE_ANGLE_CD 1500.0f // maximum angle target to be considered landing
My guess is the landing detector is being inhibited from setting the landing flag because the craft is pitching or rolling over its target or error limits when touching down. But there might be more going on as that’s as far as I looked.
edit: nm i re-read the thread and see bigler’s landing on a flat surface. Maybe its sliding or twisting a little instead of sticking/planting the landing? Then things snowball from there…
) that used a weighted trailing avg with a small timeslice to detect an impact. I tried to code a routine but I couldn’t figure out where to get the data from. It would have to be unfiltered accel data. I didn’t really know enough to design something like, but I figured it would be good to add as sometimes the crash detector doesn’t quite catch crash events. I think at the time it was using something like a variance of > 30 deg from commanded pitch and roll for more than 2 seconds. I know a lot of times the only big spike on my accZ graph is the landing or a crash so seemed like a reliable way to determine if it wasn’t in the air anymore. But then Randy said something to the effect that a itchy trigger crash detector would going off in flight would be a very bad idea so I kind of gave up on the idea. I think what got brought up usually after that in the forums when such an issue arose was to set up the motor interlock or take over with stabilize and kill the motors with the throttle (which is the route I’ve gone) but with commanded landings as OP has, has to rely more on the landed flag being set when it really has landed. With the hairy thing being you really don’t want it going off accidentally. Wish I could help, ran into this myself a few times, but I don’t have a good answer.