TRIM _ARSP_CM is the speed in AUTO , it is the CRUISE mode speed
so basically if i want more speed in auto mode, i just change the TRIM _ARSP_CM…
and what your TRIM_ARSPD_CM value…? mine is 1200 cm/s…
Mine is 1600. And if you want to change the speed during one interval of the fly then you can change it with DO CHANGE SPEED command
today is my darkness day… https://youtu.be/4qCxXeBMXqk
I have no logs from this crash … I hope you have an opinion about what I did wrong in this test …
basically I just set the flight plan and then arm the motor and switch to automatic mode from qstab …
Uffffs…, sorry. I put on your skin and my soul hurts. the message on the HUD in red >> terrain_enable = 1? I do not know if this could have caused the overturn.
Alt column of VTOL_LAND command should be zero but this os not the cause of crash
Likewise, very sorry for your crash! Have you got the TLOG from telemetry?
That is very strange as the movement of the ailerons show that the flight controller was trying to correct the roll so it was wasn’t the flight controller. Musa, did you change or adjust anything on the plane?
It may be irrelevant but in this screen grab the left motor prop has broken (after the first ground strike) but note it is not spinning as it should be even after the strike and broken prop. Complete loss of thrust in one motor could cause it to flip like that as the opposite motor can’t react quick enough to stop the rotation.
@Graham_Dyer i don’t change anything except ARSPD_FWB_MIN from 12 to 15, but well i manage to repair it (with some duck tape and glue) … and i thinking about rewiring and change the pixhawk so next time i have the log to analyze… maybe before i do automation, at first i will fly manually just to make sure it all ok…
Is the TLOG not on the PC?
I looked at your 3.BIN log and could not graph anything in Mission Planner v1.3.62. I am not sure why it doesn’t work. It showed that you are using ArduPlane v3.9.5 with NuttX. All my newer setups are using ChibiOS. Is anyone else still using NuttX builds?
That was painful to watch so I am glad that you are a master of “duck tape and glue”. When you get it flying manual again, try a more simple AUTO flight from the air. First, simply have the mission fly waypoints in plane mode. In this manner, you can manually take off and land the plane. Second, add the RTL (QRTL mode) to the end of the mission and let it land autonomously. This should provide better confidence for the final step of take-off and VTOL transition.
yes, u are right… i will do simple at first… i decided to swap my pixhawk and rearrange all cable and connection, also change the SDcard with a new one, hopefully next time i will have the log file… and yes i do expert on duck tape hahahaha…
i just finish change my nimbus broken tail servo, after some servo trim it’s ready to fly again…
and before it fly again, i have reset all my setting, reconfigure and re calibration all the input and sensor and set this parameter
is there any unusual on my parameter?
The parameters seem fine. Remember to change ARMING_CHECK back to 1 and do a full check before flying.
yes, i think i will but for now i will let it 0
btw, after swapping my pixhawk, the log file is appear… so it’s looks promising…
Your motor is also spinning when your prop isn’t (on the right one after the crash on the ground). Loose props could have done that too.
hmmm… i could be… but my air crash investigation after that accident, i found that the prop hole is burn because of friction… so there is a friction between prop and motor but u are right it’s loose but i’m not sure that’s prop is already loose before or after the first hit… but for sure next time i better check all the prop bolt before take off… thanks…
Just had the weirdest thing. Took the plane for a flight after a few weeks. Plane had flown fine the last time and hadn’t even been booted up since then.
Got an error that the trim values were lower than the minimum values and when I checked all 16 channels trim values were set at 874!?
How on earth does that happen? First time it’s booted in weeks and somehow all the trim values change?
Or is this just one of the idiosyncrasies of Ardupilot that we must accept?
I have seen that issue as well. When it was most prominent on my Tarot 680 Pro hexacopter, I replaced the old Pixhawk 1 with a Pixhawk v2.4.8 (also Version 1) and it went away. On other VTOLS, a re-boot can fix it or simply reloading your parameters from the PC file can fix it. If the plane was recently used, I did not have an issue.
I had some suspicions that my older Pixhawk 1 FCs were just losing their flash capability and I had other suspicions that it was an ArduPilot firmware issue across platforms (Plane, Copter, Rover, etc). I have not booted my VTOLs in months so it might make for an interesting weekend test. Although it is officially Spring here, the weather is still poor.
hmm… it make sense because i think i have experience this too… but after i load my last parameter it fix again…