Crash during first flight - Log included
-
Hello all,
I am interning at a company who purchased a Starling V2 to get started working with a flying VOXL 2, in anticipation of integrating the VOXL 2 into their own aircraft. I was tasked with getting it flying to validate the Qvio performance.
For the initial flight test I followed the video guide:
https://www.youtube.com/watch?v=Cpbbye3Z6coThe purpose of this test was just to arm the drone, hover it above the ground in position hold mode, land and disarm.
I first confirmed through VOXL Portal using the Qvio overlay that the room I would use for testing had enough feature points, and that position estimate seemed reasonable by moving the drone through the room. I also checked that the IMU and gyro readings seemed good. No errors were present in the Qvio overlay prior to flight. I had the left-hand rocker switch on the Commando 8 in the middle position, and confirmed through Portal that it was indeed in position hold mode. The propellers and motors were free to spin. At this point I had (probably mistakenly) not confirmed through QGroundControl that heading looked good.
I armed the drone, observed the motors start spinning. Moved the throttle to the middle position and the drone started to take off. It slowly, but immediately started to drift to the right which I then tried to counteract. After the drone kept drifting I attempted to land it by pulling the throttle down, but It stayed airborne. It felt like it was not really responding to inputs at all at this point. I decided to disarm the drone mid-air (which worked immediately) before it eventually hit a wall. This broke the propellers on the front left motor, but the drone otherwise seems fine.
The log is attached
https://logs.px4.io/plot_app?log=41653826-4300-4222-bc74-d8a169c3e31dThe VOXL 2 is on SDK version 1.0, system image 1.6.2.
Something else I, and another person present in the room noticed, was that the thrust sounded "spikey", which the logs also seem to confirm on the thrust plots.
I noticed looking at these logs that the yaw estimate seems to be rotated 180 degrees from where I would have expected. Though I am mostly certain I had the front pointed in my forward direction, which would be mostly north-facing. This is why I suspect the compass calibration might have been off. After doing a few compass calibrations through QGroundControl (and looking at the arrow on the GPS module in the Starling V2 Datasheet)l, it seems that the magnetometer rotation should be a yaw 180 degree rotation. However we noticed that this setting did not always stick after power cycling the drone, and sometimes still pointed 180 degrees in the wrong direction until we changed the parameter back and forth. We are not able to reproduce this consistently though. Sometimes it would also just take ~10 seconds after connecting to QGroundControl before the yaw heading snapped to the correct value.
We were wondering if this had something to do with the split PX4 architecture, somehow causing the yaw configuration to not be loaded in time, or at all. Merely speculation on our part.
Any feedback on what might have gone wrong would be appreciated.
Regards
Peter Krull -
Edit:
We later noticed that it seemed like the drone compass always was at 0 deg after power-on. It seems like this is the intended behavior when bit 3 is set in the EKF2_EV_CTRL parameter, which was the case here. I would have expected the behavior to be to trust the mag heading initially, and then fuse in yaw-data. This seems like odd default behavior to me. It does however explain why the drone was facing 180 deg in the wrong direction during my test.I just tried, after a fresh mag calibration with rotation_none for the magnetometer, to place the drone in the same location as I took off initially. The values seem to align in this case. What is the correct rotation to use? Our previous observations about it being right at 180 deg might just have been because we happened to power on the drone in the right orientation.
-
Yes, the yaw estimate will track VIO unless you turn off the Yaw bit in EKF2_EV_CTRL and have EKF2_MAG_TYPE set to 0 (which is it on Starling by default). If you are doing mostly indoor flights you can completely disable the mag by setting EKF2_MAG_TYPE to 5 and SYS_HAS_MAG to 0.
The default EKF2 setup for starling is focused on indoor flight. It enables the magnetometer for calibration and logging but does not use the data. Every time I power on a starling QGC reports 0 degree yaw unless I rotate it. This ekf2 setup is described by the following file that's loaded during the flashing process
Note that we are very close to the tip of px4 development and PX4's integration of EKF2 is undergoing a lot of rework right now, including restructuring the EKF2_AID_MASK param into several other EKF2_XYZ_CTRL params.
Please put the CAL_MAG0_ROT rotation parameter back to the default of 0. The driver handles rotating the sensor data from the IC into the frame of reference of the GPS/MAG module, the CAL_MAG0_ROT parameter exits for the case where you mount the gps/mag module in an unusual orientation.
Finally, looking through the logs it seems you experienced a typical vio failure, mostly likely due to lack of visible features on takeoff. Starling is a very small drone with the tracking camera close to the ground, so I recommend trying again by taking off on a feature-rich surface or off of a stand that lets the camera see more of the room during the critical takeoff stage. Once it's up in the air with a good view it will lock in.
-
@James-Strawson Thank you for the reply,
I will revert the CAL_MAG0_ROT parameter back to 0, and also study the other configurable parameters and their impact.
About VIO losing track during the test, that is definitely possible, but I believe this part of the room was fairly visually distinct. In the log it seems that the failsafe flag for local position invalid was 0, but global position invalid was 1. Shouldn't the local position be the indicator for good VIO? I will just have to try again and double check the robustness of the tracking beforehand. But that makes me wonder, what happens if VIO loses track during flight? Must I then land and be stationary before I can take off again? At least that seemed to be the case when I was waving the drone in the air to try out the tracking. Also if the VIO was unable to make a good estimate from before take-off, shouldn't it refuse to take off in position hold? I guess if it loses track again, I should just switch it into manual mode to regain control.
Thank you for taking the time to answer my questions.
Regards
Peter Krull -
I have a similar problem where I set the Starling to position mode, arm, and put the left sticker a bit up like for the drone to fly at 1/1.5m, and then the drone starts to go all the way to the ceiling and a little forward.. when in position mode I checked the thrust on Qgroundcontrol and is initialised to 0.001, but after arming, it goes up. The drone is new.. I just bought and didn't change and config file.
-
@Caio-Licínio-Vasconcelos-Pantarotto I just got new propellers and tried flying again. This time with visually contrasting objects on the ground in front of the drone. Much better than before. One thing that might help, is to set
"enable_init_while_moving": trueinetc/modalai/voxl-qvio-server.conf. Then if the track is bad at some point during flight in position hold, it will in my short experience at least, do a better job at reinitializing in-flight. It can however also also initialize in a way where the position estimates quickly become nonsensical, before returning to something normal. In any case, I think the behavior when VIO loses track or otherwise performs poorly is not great. Unless the pilot is also inspecting the Qvio overlay while flying, it is not easy to know the state of the estimator.In my case, I did my initial flight on a carpet which is has a bunch of contrast up close, but not so much at a medium distance. It could be that Qvio decided to track the carpet initially but lost all tracking shortly after and never recovered.
-
P peterkrull referenced this topic on
-
@peterkrull Thank You. Yes initialising in a place with many features improved a lot. I have a question for you.. have you tried enabling collision avoidance ?
-
@Caio-Licínio-Vasconcelos-Pantarotto I have not experimented with collision avoidance. I doubt that would do much in the case where VIO has completely lost its tracking, but that is only my guess.
