Running a simple Qplane mission: VTOL takeoff, proceed to a waypoint, then another, then proceed to a LOITER_TIME waypoint hovering in copter mode since Q_GUIDED_MODE is enabled, then proceed to yet another waypoint, and RTL.
The mission proceeds fine, turns at the first waypoint maintaining altitude thru the turn, then proceeds to the waypoint before the LOITER_TIME, climbing to that waypoints target altitude (doesn’t quite get there)…but as it reaches it and begins to turn to the LOITER_TIME waypoint it drastically drops in altitude (to ~60feet) instead of smoothly beginning to transition from 150 feet to 100 feet…in addition, as the transition occurs, throttle momentarily completely goes to idle and then surges back…this throttle glitch also occurs as it transitions back to plane mode to fly away from the LOITER_TIME waypoint…very dramatic…
Questions:
Why the radical (and dangerous) altitude drop and recovery as it turn to the LOITER_TIME waypoint? In the log you can see that the unused Qplane alt target is at that low value, and moves to the LOITER waypoint altitude…the plane recovers altitude at that point…its almost like the alt target is set before the transition is completer…actually at the crossing of the waypoint radius since altitude loss begins dramatically as the turn begins…
Why the massive glitch in motor power on transitions?
It would be good to test this in SITL (this is possible with MP). Testing this will allow us to know if it’s a software issue or a vehicle setup/configuration issue.
David Buzz just tested with a quadplane (a little different from the vehicle you’re using) in MP and it seemed to be OK which pushes us in the direction of a vehicle setup issue but let’s see.
Thanks…I can get the MP sim to run with std SITL quadplane, but when I load my Convergence params in, the sim (even backing out the upside down Convergence FC orientation), it refuses to run the sim…BAD AHRS, BAD Compass, etc. Obviously, the sim expects a certain hardware configuration (servo/motor outputs?, zero-ed INS/Compass?) but there is no list of what that needs to be that I can find. (another potential doc update for me to do
Edit: I now understand that I need to get a specific convergence physics model…
@hurzburg I ran a similar mission with RealFlight 8 and my Convergence parameters. Didn’t see anything wrong with throttle management or the flight profile. Here’s a plot of altitude and throttle outputs (motors are on channels 5,6,7).
The params are also in the log file, and can be extracted with a command like
“mavparms.py log.bin > params.txt”
I put the result of that command in the gdrive folder. I’m not sure if Mission Planner can display parameter values from a log.
Also, I’ll be traveling for the rest of the day, so it may be a while before I can do any more on this.
Thanks Mark…since I am using Windows , I am having trouble comparing the param files…the python script separates params-values with lots of whitespace instead of a comma, the values have lots of superfluous trailing zeros, etc…will take me a while (prolly a couple of days) to format the values to do a compare using any diff program in Windows…but thanks for working on this…I will also try to setup Mavproxy environment in my Linux VMWare window that I do compiles in…will probably make working with others easier…
I ran “mavparmdiff.py” on the two sets of parameters and put the result in paramdiff.txt
Not sure what the problem is with whitespace; the param files look fine in both gedit and (windows) notepad.
I also put my copies of your logfile and params in a subfolder: https://drive.google.com/drive/folders/1vhYh4fQbBv6rAdTwd78TXQrx5M2TcHnp?usp=sharing
Let me know if you can see that OK.
Thanks Mark!..after some tedious trailing zero work on the files, I can get a pretty good comparison with my Winmerge file comparison utility…overall, I dont see anything radically different that would account for the altitude loss as it turns through the waypoint toward the transition to vtol for loiter waypoint…but I do have the VTOL ahrs level attitude much more nose down than in plane mode in order to hover in trim, perhaps as I hit the waypoint radius and the turn begins, the ahrs level change happens instantly, forcing the nose down and losing altitude…as the plane exits the waypoint radius it starts the transition of motors to VTOL mode…I appears to me that switch to using the AHRS VTOL trim value occurs before the tilt motor transistion actually even begins, forcing a rapid altitude loss that the TECS system cant overcome quickly enough…I think that this is a bug…I will test this some more this week…it may only occur during waypoint transitions in a mission…
