that depends on how you want to fly it. You only need a smallish angle for flight (I think 30 would be plenty), but having more for takeoff/landing is nice. Having 90 both ways allows you to land and takeoff much more easily in wind.
personally I love the vectored approach. We only have basic support for it now in ArduPilot, but I think there will be a lot we can do with it as the controller develops.
It is very new, so weâre still learning how to best set it up. The motors do need to be far enough off the leading edge to prevent some nasty wash effects over the wings as you tilt. The CoG needs to be close enough to center of lift on the wing that it will fly well in fixed wing.
Weâre building one now for CanberraUAV where we are using +/- 90 degrees, so 180 total. The aim is to be able to takeoff with the wing either way up on the ground.
The Q_M_THST_HOVER parameter sets the base that the integrator works off. So if you set it to 0.2 and it actually hovers at 0.7 then the integrator will end up at 0.5. Setting it right makes it learn the right integrator faster. That leads to better takeoffs.
It also is used to scale some limits in the attitude controller, and to constrain the IMAX for the Z controller.
yes, but look at PIQA.I and youâll see that it changes as you change the hover throttle.
We should add hover throttle learning. It will help with takeoffs and landing.
thanks for the video - itâs fun trying to work out what its doing by watching the shadow on the ground
looking at the logs, the biggest problem is the health of the EKF. I notice you have ARMING_CHECK=0, so all of the pre-flight checks were disabled. The EKF was very unhappy, with huge attitude estimation discrepancies. Iâll look in a bit more detail and see if I can work out which sensors are not behaving correctly.
@tridge,
Thanks for the help.
I wondered why the safty switch was intermediat blinking after pressing and not full ON.
Will change ARMING_CHECK quickly.
analysing EKF logs for tailsitters is getting a bit tricky with euler angles, so Iâve opened a PR to add quaternion logging of EKF state, SITL state and DCM state
this will help analyse whats going wrong with the EKF state for @lorbass
@lorbass Iâve had a bit more of a look at your log.
You should move the motor servos to outputs 5 and 6, so they arenât in the same rate group as your elevons, otherwise youâll be running servos at 400Hz, which may damage them.
You should give your elevons more throw by pushing MIXING_GAIN up to 1.0, and set MIN/MAX of SERVO1 and SERVO2 to 1000/2000 instead of 1100/1900
I also think you need more D term on pitch, Iâd start by increasing it from 0.0036 to 0.01 and it may need more
Try with those changes (and arming checks on) and see how you go
I hope it wasnât damaged!
Note that it is still pretty early days with learning how to tune tailsitters, so it will probably take quite a few tries before we learn the best approaches
I donât understand the word âServosâ for motors.
Do you mean the ESCâs for the motors to move from 3,4 to 5,6?
Some foam to glue, and one Prop.
I know the risk, a little bit less than Kolumbus:slight_smile:
But Iâm happy with your support and of cours with your development work, thank you.
@lorbass He means put your ESCs (motors) on channels 5,6. The PWM outputs are called âservo outputsâ regardless of whether theyâre driving servos or ESCs.
My configuration has elevon servos on channels 1,2 and ESCs on channels 5,6.
The way the code currently works, the entire group of PWM output (servo) channels which has a motor function assigned to any one of the channels will be set to 400Hz. The groups are 0:[1:4], 1:[5,6], 2:[7,8]. Since channels 1-4 are in the same group, assigning any one of them as a motor channel will have the effect of running all 4 at 400Hz. But if you put your ESCs on 5,6, then only those two outputs will run at the high speed.
Of course, if youâre using digital servos, theyâre probably OK with 400Hz PWM signals. And the higher PWM rate might reduce control latency and improve your control margins.
for what itâs worth ,on mine when you touch down on the t/e a slight forward stick to move off itâs balance point works, and is very controllable, assuming your landing into the wind. You could move the landing gear/point to move the c/g to auto land upright ?
In the window EKF of MP I could see what happens, and
after I have seen, that the horizon in the HUD of MissionPlanner drifted away (angle) even if the
Wing was on the desk, I checked the compass calibration.
Calibration was not possible because of a âstupidâ mount of the Buzzer near the GPS/Compass???
After solved this the GPS Position drifted around 5km again on a table outside(10 Sats).
The issue was that the GPS was close (15 mm on top) to the RX (Taranis)
Now, the horizon ist stable and the GPS Positon
Only one thing is strange as bevor.
After pressing the safety switch, the slow flashing light change to a double flashing not to a stable on.
Any adwise why?
I have set ARMING_CHECK TO 1 (all)
No error messages in MP.
After arming (Stick right,down) it reports in the HUD of MP "Armed"
Light still double blinking and the mots are running.
Will analize more deep.
No issue found.
Can somebody help to analize the log?
Test with Rover and Plane the Safety switch reacts as i should.
Loading again from master the Switch blinks when pressed even with the default params.
When powering Pixracer after twittering 2 tones are to hear first high, second low.
The same tones are to hear after the music tones when loading FW in MP via âload custom firmwareâ is finished.
Is Version 4 correct for Pixracer?
When I load the FW via MP âBeta Firmwaresâ then the Safety Switch reacts as it should and after booting
the well known sounds are to hear.
I just flashed master (ArduPlane V3.8.0beta4 (20f7d75b)) on the X2 in my Stryker (board type px4-v2) and the safety switch LED behaves normally: (4 rapid blinks pause, repeat) immediately after boot. The LED is on solid after pressing the safety switch.