Congratulations Dennis! Very nice build.
As usual, DF logs can be a big help, although I should mention that I have a bit of a backlog of log analysis at the moment 
1 Like
so do you think your motors lost sync when you went from FBWA to QLOITER? It certainly did lose control very rapidly, but I wouldnât have guessed that was caused by loss of motor sync. Can you explain a bit more of the background on your âdesyncâ issue?
clearly it lost control badly when going from FBWA to QLOITER. I think the problem is that we donât really do a proper transition from fixed wing to hover in tailsitters. It just goes straight to a hovering mode without first trying to bring the nose up. The transition is just too sharp.
Iâm planning on fixing that by adding a transition stage where the aircraft is still being flown as a fixed wing, but bringing the nose up as fast as it can, then switching to the hover controller once the maximum pitch angle for fixed wing flight is achieved, or if the pitch rate drops below a threshold (so it is no longer able to pitch any further).
I probably wonât get that done for 3.8.3 though, it will likely be 3.8.4 at this stage.
hi Caleb. When you ask for help with logs, please try to do some preliminary work at the very least. Offering a download link with 10 files without any notes on what is in them is not useful. I donât have the time to download and wade through that many files.
Here are some guidelines on logs for analysis:
- look at the logs yourself first with one of the available tools for log viewing.
- Work out which of your logs is actually interesting and needs analysis. Pick one log if possible. If absolutely necessary to show some feature, then pick two logs.
- only upload the *.bin logs (the dataflash binary log format)
- for the log you want analysed, write some notes on what happened from the pilots point of view, and what you need help to explain. âhad some troublesâ isnât enough for me to know what to look for.
Just so you understand, it often takes me an hour or two to analyse someones logs. I donât want to waste time on looking through logs that arenât interesting. So when someone just puts the contents of their SD card from a days flying up for download then I usually just ignore it. I donât have time to do the preliminary work for them, sorry.
MANUAL mode doesnât do any stabilisation or transition, so it really isnât useful for a tailsitter. You canât hover in MANUAL (unless you are a really top class 3D fixed wing pilot). Even if you manage it, it doesnât have anything to do with the autopilot code - it is just about pilot skill.
Cheers, Tridge
A question not related to tailsitters, what do you use to show the telemetry data on your video ?
Is it done using the data flash logs in post production ?
We understand your situation.
Here I had a question with detailed videos and graphs to show the situation in order not to waste your time.
To lower Q_A_RAT_PIT_IMAX to 0.25 did not help.
May be Param D could help, but this is limited to a verry low value due to mechanical feedback which cause a shaking wing with motors off.
Can you recommend another method ?
Regards, Otto
Yes. But this is a problem with my propulsion setup and not of AP. When going from low rpm to high very fast, then the ESC loses sync to the motor. I can reproduce this on ground. I changes the motor from the Multistar 3508 580kV to the Tiger MN4012 480kV and tested it on ground, not noticing any desync. But in the air it still happens. I now will change the ESCs from the Multistar 30A V2 ones to Hobbywing X-Rotor 40A. Flying on 6s.
Also did you see what happens in the Video on 28s? Wind is coming a bit from the right. The wing is pitched and the surfaces are at max deflection. Wing is still not able to get nose up again till I give additional thrust. You can see the red indicator at the Cessna Symbol for the demanded pitch angle. The Cessna is the actual pitch angle. Any Idea why this happens?
Also is anybody here able to make an scientific statement whether it is better to have the CG more in the front or more in the back of the plane to overcome this problem in the Video at 28s?
After an initial thinking I got this:
- CG in Front: more lever for the forces of the control surfaces, therefore greater momentum to compensate pitching
- CG in the back: more equal force distribution from attacking wind forces orthogonal to the Wings surface around CG â Less weaker momentum pitching the wing more in wrong direction. But may get difficulties when in forward flight with CG too far back.
So where to put CG?
Your idea that it is related to the CoG is a good one, but I donât think the primary problem is fore-aft CoG, I think it is the âbelly heavyâ versus âback heavyâ CoG.
The integrator for pitch in the multicopter controller is hitting the maximum negative limit. That means it is always fighting to push the nose down. That implies that the weight is too much towards the âtopâ of the aircraft (when viewed in forward flight). That makes it tilt back.
CoG in a tail-sitter is a 3D problem. In a normal fixed wing most people treat it as a 1D problem, and move weight either to the front of the plane or the back. In a tailsitter you also have to consider moving it towards the âtopâ or the âbottomâ.
In FBWA mode (so in fixed wing) the logs show your plane is a little bit tail heavy. If you move the weight much further back in fixed wing mode then youâll start to lose stability in fixed wing flight modes.
In QLOITER you are a bit âtop heavyâ (or âback heavyâ from the point of view of being nose up). So shifting some weight from the top of the plane to the bottom will help, or burying the weight a bit deeper into the plane.
I know this can be quite hard to organise, but it will really help.
Cheers, Tridge
thanks for the analysis.
But are you sure about the âtop heavynessâ?
The Wind was coming from right and was pushing onto the wing surface, resulting in a pitch up force. I designed the plane with symmetric airfoils and the CG right in the middle at X-150/Y0/Z0. And while flying the CG was there with ±10mm tollerance.
When you have more attack surface under the CG then above the CG (in Hover) and there is wind pushing onto this surface, then the wing will pitch into the direction where the wind is coming from. This is what makes an dart arrow point its nail to the front and what makes an Airplane stable again when having a stall. But here with Tailsitters we might not want this behavior. We want the only pitch momentum to be the one from the control surfaces. Otherwise we will be very affected by wind forces. (!!!)
In FBWA the plane is indeed a very slight amount tailheavy, but I designed this for purpose. When its tailheavy the elevons are slightly deflected down, resulting in an more chambered airfoil, having better L/D in my case.
I know that the plane is not self stable, but i will never fly it manually, so this does not matter to me.
Youâre right that the wind could have been playing a big factor. I suggest you try a zero-wind flight in QHOVER mode, and see what the PIQP.I value does then.
ok, makes sense!
No worries @tridge I know youâre swamped so Iâm going to forge ahead with tuning and will report back with my findings. Thanks for all the hard work.
@tridge May I ask why transition looks so completely different (smoother) on px4 (almost three years ago) ? http://px4.io/portfolio/caipirinha-tailsitter/
Also why do we have two semi-identical codebases anyway? Makes no sense to me.
@palm369 May I ask what you mean by âsemi-identical codebasesâ? I assume you are talking about the PX4 and ArduPilot flight stacks, and they donât look very similar to me.
The last time I looked, the PX4 VTOL logic used the same transition strategy for quadplanes and tailsitters. In ArduPlane I donât believe there is currently any attempt to smooth the tailsitter transition; the vehicle pitches forward at maximum allowed pitch rate. While it might be preferable to slow the transition down a bit, a tailsitter should certainly be capable of a fast transition from hover to fixed-wing attitude.
I mean that afaik both where the same in the past and got split up into two projects when 3DR was active on development. Why dont they merge them? Are there different development goals for the two projects?
Afaik they both doing the same thing on same Hardware. Ainât see no diffrence.
Also lot devs are in both projects.
There are a lot of reasons, some Googling can help you find them.
According to the Documentation PX4 VTOL an airspeed sensor is used to determine when to switch to plane mode after accelerating in hover mode.
In the PDF Documentation a special setup is described without airspeed sensor.
In this case it is needed to set a Transition Time to accelerate.
And as Tridge advised he will work out other transitions.
Thanks you, Iâm looking forward to it.
Otto
Found this, https://youtu.be/-bQdrvSLqpg ⊠anyone know how to integrate this to Ardupilot, I need all the help I can get with P I D understanding.
Will take a bit of digging, but there is actually an Ardupilot balance bot codebase somewhere in GitHub, from about 5 years ago (apm2.5).