last 2 logs? sent all
ahh, I see, the LASTLOG.ZIP ? downloading now
Hi Richard, just starting to look at your logs now.
I notice it is running a firmware from 1st March. When working with such bleeding edge features in ArduPilot it is best to test the latest firmware. Once support for tailsitters matures then using the stable releases would be recommended. I suspect you are not familiar with the GCS interface for getting the latest builds. In MissionPlanner firmware load you can use control-Q to get the latest firmware. Or download from here:
This firmware version does support tailsitters, but is missing some features and the logging doesn’t take account of the 90 degree AHRS view change when hovering, so logs are a bit harder to analyser.
I notice you turned off arming checks with ARMING_CHECK=0. Sometimes there are good reasons for that, but in this case I think you would have had some important warnings. In particular your GPS seems quite unhappy in 44.BIN. In 45.BIN it is quite a bit better. In 44.BIN I see high EKF position innovations (see NKF3.IPN NKF3.IPE in the log for example). That means the accelerometers and the GPS velocity were inconsistent. I’ve suggested above (after your flight, sorry!) that switching to EKF3 would be a good idea to ensure that accel biases are learnt on all axes.
The the QHOVER part in 45.BIN it seems to be holding height reasonably, but not great. The throttle is varying quite a lot more than it should for a steady hover. It is staying within about 20cm.
At the end of the hover the throttle went up a lot but the aircraft didn’t climb. Did it just run low on battery? Battery monitoring is disabled so I can’t tell easily. The board voltage (POWR.Vcc) is varying a lot more than it really should. It should stay close to 5V, but I can see it get down to 4.4V at times. How are you powering the board?
Your Q_A_RAT_YAW* gains are setup for a multicopter (see comments in discussion above). Setting the I up equal to P will help. You probably also need some FF gain. I’d suggest 0.25 to start with on roll, pitch and yaw axes. Yaw control looks quite weak.
It is a bit hard to analyse the overall performance of your PIDs with the firmware from early March as it suffers from gimbal lock. Could you try another flight with the latest firmware, and the following changes:
also try with ARMING_CHECK=1 and see what it complains about (if anything!)
I’d also suggest you push up MIXING_GAIN. It is currently 0.5. I think 0.8 to 1.0 is right for tailsitters. That will effectively raise your gains though, so you may get oscillations and need to scale them back.
I think that is enough changes for the next flight. I can look at the results and iterate from there.
Just to hold the motivation on fire, I will follow you with this:
No butter transport intended, just to check the Center of Gravity while waiting for
delivery of the accu.
Weight 850 gr, max Trust 1200 gr (eCalc), Elevons 55mm (original 40mm)
Hi, on the f/w I tried v4 but would not connect after it was loaded? what’s the difference between v1-v2-v3-v4? should I reformat the sd to erase ? I am using a 5V 5A pololu runs a little low 4.9v but usually holds voltage under load better than anything else I tried and pretty clean as well, I will check wiring, thanks again for the help. how do you get all your stuff done and keep you fans happy ?
I attempted a forward transition today, and it did not go well. It immediately went into a crazy (body frame) yaw oscillation. I could hear the motors spooling up and down, so I think it was caused by the flight controller. @tridge, I’m going to send you a discuss private message with a link to the log file. Can you take a look at it and try to figure out where the crazy yaw oscillations came from? I’m guessing it was a result of the YAW2SRV_RLL mixing. I would recommend that anyone else who is going to try forward flight sets that parameter to 0.
On a positive note, I matched my Q_A_RAT_YAW parameters to my Q_A_RAT_PIT and Q_A_RAT_RLL parameters and there were almost no yaw excursions at all, even with some pretty aggressive translations from side to side.
Quick warning to everyone: For some reason, on my airplane the throttle output is capped at 50% in FBWA and AUTOTUNE. I was able to do a successful forward transition by setting KFF_RDDRMIX to 0, which got rid of the crazy yaw oscillations I saw on my first attempt. The transition was perfect… the nose pitched over, airspeed increased and it was flying on the wing with almost no altitude gain at all. However, because of my low-pitch props and a capped 50% throttle, I was unable to maintain altitude. I ended up putting it back into QSTABILIZE in an unusual attitude, with a predictable loss of control.
I’m sending the logs to @tridge , but if you’re going to try a forward transition I would at least make sure you have full power in FBWA, or whatever mode you plan on switching to.
is THR_MAX set to 100 ?
I suspect its due to KFF_RDDRMIX being too high. Set that really low, or even zero. The differential thrust of the motors is treated as rudder, govered by KFF_RDDRMIX
My apologies for not telling you to lower KFF_RDDRMIX. I’m going to make a change now to default KFF_RDDRMIX low for tailsitters. I’ll also default some of the other key parameters to the right values.
@mrjadkowski What’s your power setup (voltage/kV/props) and flying weight?
@tridge THR_MAX was the issue with the power, and KFF_RDDRMIX was the issue with the roll-yaw coupling. I fixed all that, and took it back out for some more flying. There is still some weird stuff going on in forward flight, with what appears to be some inappropriate yaw inputs. I sent you the log files to take a look at, as I figured you would want to look at the transitions. But I did have three more successful forward transitions, and two successful back transitions. It’s the control in forward flight that seems to be acting strangely.
3S lipo (around 11.5V in hover), E-flight Park 480 1020kv motors, and I’m flying 10x4.5 props since I broke my 10x5.5 props. The airplane is around 1300g RTF, and it’s hovering at around 50% throttle.
thanks for the logs, I’ll look at them, but I notice you’re also running beta3, which is quite old. I’ll do a beta4 soon, but meanwhile can you install master? (latest in MissionPlanner, use control-Q). There is an important logging fix for tailsitters in master
I’ll give it a try, but the last time I tried to load the latest master build for px4 v4 I couldn’t get any mavlink heartbeat messages.
On another subject, is it possible to define different AHRS_TRIM values for Q modes and forward flight modes? If not, would it be a difficult change to make? I think it would be useful for this airframe type.
I just built a branch based on a recent version of master for v4 and it’s running OK on the bench; connects to mavproxy and downloads logs.
yes, I agree. just need to work out how to do that and fit into the AHRS API
I release 3.8.0beta4 today, with all of the tailsitter improvements except for Leonards controller changes (as they haven’t been flight tested yet)
It should be on the autobuild firmware server in a few hours.
Many thanks to all the testers who helped make this beta so much better!
One more question: is it possible to disable yaw inputs while not in a Q-mode? I think part of my forward-flight problem is that I’m inadvertently introducing small yaw inputs with my throttle stick. Unfortunately with differential thrust yaw control, those small inputs cause big yaw changes on the airframe.