Hi I have an Hexa with this configuration
-OrangeCube 4.0.5
-Here 2 GPS
-RangeFinder TFMINI to the floor
-HereLink
We had a great morning flying arround our drone. Even we did some RTL and automatinc landing, and everything great.The last time I try to land the drone (on loiter, with the sticks) as I have done it before that morning, it seems the FC didn´t detect it was already on the floor, I try to disarm but no luck. When I saw the drone tiping to one of the sides on the ground, I push the throtle full to avoid the props touch the ground, but no lift. So the drone flip over and of course some damage.
In this picture you can see on the red square where I did land, the blue sqare try to disarm but not luck and the orange square where I try to take off again, but motors didnt respond.
So the questions:
Why the FC didnt detect the landing?
Why the FC didn´t let me took off again to avoid the crash.
Here is the log (because a missconfiguration on the divider on the mauch, there is no current data)
My opinion is tuning affects landing reliability, amongst other more obvious aspects of flight.
I’ve definitely seen where substandard tunning affects things like landing reliability, and “the shakes” during throttle-up for take off.
Pitch and Roll attitude control is reasonable but not quite perfect. Yaw is very good though.
The ATC_ANG_RLL_P and ATC_ANG_PIT_P are very different. Did you Autotune with a payload or manual tune? Weight is much more along one axis than the other?
You should be able to get all these little wiggles out of the attitude:
Set these right away (as per the spreadsheet linked below)
MOT_BAT_VOLT_MAX
MOT_BAT_VOLT_MIN
They will definitely help as the battery depletes.
And this for more manual throttle control since there doesn’t seem like a danger of fly-aways
ATC_THR_MIX_MAN,0.5
Actually just recheck all your params against the latest download of the spreadsheet.
It will definitely be worth it to set up Harmonic Notch filtering, then increase INS_GYRO_FILTER to the value recommended by the Tuning Guide and in the spreadsheet.
Then run Autotune without a payload, then adjust these for your payload:
ATC_ACCEL_P_MAX x (min_TOW / max_TOW)
ATC_ACCEL_R_MAX x (min_TOW / max_TOW)
ATC_ACCEL_Y_MAX x (min_TOW / max_TOW)
Let us know if you need help with the Harmonic Notch filtering.
I would even test and tune without the payload at all then reduce these to suit:
ATC_ACCEL_P_MAX x (min_TOW / max_TOW)
ATC_ACCEL_R_MAX x (min_TOW / max_TOW)
ATC_ACCEL_Y_MAX x (min_TOW / max_TOW)
These values don’t have to be something exact like Autotune produces, eg: 25678.31, you can just round them off to whatever works best for you, like 20000.
And you could even reduce the ATC_ANG_RLL_P and ATC_ANG_PIT_P a little and do some test flights, checking logs.
min/max_tow = minimum and maximum take off weight
So if you Autotuned with absolute min take off weight of say 10kg and achieved ATC_ACCEL_P_MAX,45337.77
then you added 4kg payload = 14kg TOW
you would do 45337.77 x (10/14) = new ATC_ACCEL_P_MAX, 32,384.121428
round that down to 32000 if you like
Also try increasing ATC_INPUT_TC to 0.2 or even as high as 0.3
Try lowering the disarm delay
DISARM_DELAY,5
It’s not obvious to me why your aircraft didn’t disarm sooner, but the motors were ramping up to try and maintain stability (the best it could) then motors tried to ramp up more because of your throttle and pitch/roll inputs but it was too late.
It’s not a Cube issue, just tuning of Arducopter and all the physical components together.
NOTE: don’t take this as advice to avoid the previous suggestions - they should all be implemented regardless of the following comments.
Actually, looking at the log again this is what I think contributed:
As you are landing the HDOP (horizontal accuracy) is rising (a bad thing) and GPS speed is going up indicating the GPS position is moving, thus causing the aircraft to try and shift while landing gear is on the ground, causing the tip over.
Try improving your GPS reception and maybe move it higher up away from the battery.
Try some different GNSS settings to see what works best in your region, probably:
GPS_GNSS_MODE,65
You will need to test though. For example where I am we get really good BeiDou reception and a high number of Sats, but poor HDOP, so it’s essentially useless. For me GPS and GLONASS gives best accuracy and reception on ordinary receivers. More than 2 constellations can easily overwhelm a standard receiver too.
Aboout this, I have asked here some time ago, becase if I use the Here2 with CAN connection, the HDOP always went very high. This is the post, and in fact, is the same drone.
Can you try to connect the Here2 as CAN, then modify its node id from original value?
I don’t think the mode on Here2 would cause landing problem. It might be software problem, or maybe some data is not feeding into the ardupilot correctly.
In another 3d I reported the interference problems in the canbus with i2c magnetometer but no one has really considered the matter. I had solved it by changing the canbus addess. In my opinion there are several critical issues of interference in the canbus
I cant, beacuase the drone was already delivered. I will try to do it in another drone when I have it.
I remember the landing, the drone start to drift meanwhile is was landing (the same place where we have landedn before, with open sky, no metals near), so when it touch the ground it keep drifting, didnt detect it was already on the ground and tip over. I saw did was happening and I try to take off again, but the drone didnt respond.
I just checked a Cube Black with Here3 (CAN only) and HDOP was about normal for this area (0.83 to 0.61), number of sats is normal and there’s no abnormal position drift while stationary (groundspeed between 0.04 and 0.009)
