Servers by jDrones

Copter Tailsitters

Ah I see. Could the autopilot infer a motor failure from the flight response – or lack thereof – and compensate accordingly? Does ArduCopter/Plane overall not have any contingency for motor failures/redundancy? It would be quite tricky on a quad of course but w/ more rotors it might be possible.

That’s probably a question worthy of it’s own thread, rather than hijack this one.

thanks for sharing. Amazing aircraft !!
It seems they solved the yaw control problem also by tilting motors. A linkage can be seen at 7s and 1.01s and motor position at 8s suggest they can tilt.
I can not see any control surfaces on wings but horizontal tail surfaces seems to be actuated. As far I can see, airfoil seems not to be reflex. So it look like more to a biplane aircraft than a flying wing.

I think it can in copter mode but not in plane mode. From my dual motor tailsitter experience, when a motor is stronger than the other, it cant be seen in copter mode (just the weaker motor run with higher pwm) but during transitions and FW flight I can see non symmetric flight (the same pwm value is sent to all motors)
@kd0aij probably have a better understanding

The copter code does look for unbalanced thrust (demand) to detect motor failures:

I suppose Plane could look at yaw rate and rudder demand to detect an imbalance in port/starboard motor thrust.

This is a photo of my copter X tailsitter almost finished. Calibrations and parameters are OK, I already made a small hover flight, stability seems to be very strong. However I have a glitch problem that affect RCin and RCout (and rc8 which is my mode channel)… I suspected the BEC to be responsible and changed it but glitches again. Today I have inspected my TX frsky DJT module and made an other test on the ground, no glitch.

2 Likes

a video of Q_hover test flight. Everything seems to be fine now. Pitch stability is very strong but yaw could be better. Only top wing control surfaces are elevons. Bottom wing control surfaces are ailerons only. The 1/4 mean cord of the bottom wing is at the same longitudinal position than the CG so I am wondering what would be the effect of elevator on bottom wing. Is someone know ?
The fuselage is very rigid and there is no need for legs between wings. The ugly nose is for the battery in order to get the CG at the same distance from both wings. The CG longitudinal position is at 20%.
The landing is not good because of thin legs, not suitable for sand. Also the design is not the best one for landing: too high CG and not enough span between wings.
Some important parameters:
Q_frame_class = 1 for copter tailsitter
Q_frame_type = 1 for quad X and yaw control with differential thrust
Q_angle_max=7000
Q_tailsit_gscmsk=2 for gain attenuation based on attitude and throttle
Q_tailsit_gscmin=0.2 gain attenuation max
Q_tailsit_input=3

I will test soon transition to FBWA, I still don’t now if this aircraft will be stable as a plane…

4 Likes

Congrats on another successful build!

Are you calculating CG using this method?

I guess elevator would be more effective on the lower wing since there is a longer moment from elevon to CG.

Can you post a log from this flight? I’m chasing a potential bug in hover thrust learning.


this is the log of the flight but

  • I have q_m_hover_learn =0
  • Apm planner tell me the log is corrupted (but can be read), this is the first time I have this message with the current binaries.
    If needed, I can make a flight with hover learn enabled.

Congrats to you and all developers, from my side it will be a success only if it fly as a plane.

My method to find the CG is not the same you showed. I have considered the mac of each wings (which is rather simple considering wings are rectangular) and taken the 2 points at 20% from the leading edge. I have drawn a segment between these 2 points and set the CG in the middle of segment because both wings have same surfaces. So my method assume 2 flying wings without interaction. I am a little concerned because with your method I find a CG 3 cm in front of mine (keeping the 20% rule). We will see, the lake is still around 20°C…

I wouldn’t expect that the biplane CG determination method is right for a tail-less configuration.
But hopefully QSTABILIZE or QHOVER would save it if the CG is too far off for FBW modes.

Thanks for the log, I’m also looking at the throttle expo function. I see you have
Q_M_THST_EXPO 0.600000
Q_M_THST_HOVER 0.500000

Do you set QSTABILIZE mode up for hover at mid-stick?

No because I dont use Qstabilize.
To set Q_m_thst_hover I look at logs Qtune_tho and add 0.1 for safe transition tests. This is a stating point that I will adjust. A critical point is to keep enough airflow on control surfaces during the first part of the back transition and q_m_thst_hover set the throttle level up to transition angle.
I remember I have tested the thst_expo parameter some time ago with my test wing and probably forgot to get back to default value. Now I have just copied the parameter list to the new model.

This is the log of a flight I made this evening with a transition to FBWA. You will see the biplane fly very poorly with large pitch oscillations. I was happy not to crash but I think this is simply a bad CG. But this is not the problem. Around 179s right after the back transition I had a very weird behavior, I asked a pitch change and got a 60° roll response instead. Looking at the log it seems to me there is a large attitude difference estimation between DCM and EKF as AHR2 roll and yaw does not match XKF1 and XKF6. Could you please have a look ? Could it be a compass problem ?

It does look like the EKF attitude estimate was wrong… But the normalized mag innovations are smaller than the normalized innovations, though I don’t really understand what those numbers mean.

I’ll ping @tridge about it

This looks like aliasing of high-frequency vibrations. Better vibration isolation (including that coming in from cables) would be worth a try.

Thank you for the log analysis. The propellers produce some vibrations, I am going to balance them carrefully or change them for better ones.


nice plane mode flight during the sunset.
CG is now around 15%
I found a motor to produce abnormal vibrations and replaced it. Now vibrations are lower.
Problems reported in my previous post seems to be solved. The flight is smooth, low speed is stable and safe but a lot of tuning is still needed.
On the second flight I forgot to plug in the bec that power the servo rail and make a transition to fbwa. Of course, as soon as the aircraft was in plane mode it made a lot of tumbling so I switched back to hover and saved the plane. Without control surface the yaw control was very weak but good enough to land. It was really a scary moment…
3 Likes

Forward flight looked great to me!
Glad you were able to recover from a tumble; I wonder if the torque-based yaw was an advantage or disadvantage when tumbling. I’m sure it was nice to have for landing though.

I dont understand what you mean, I believe all motor output are equal in plane mode except a right /left difference through roll to rudder mix and rudder to differential thrust.
Nevertheless I begun to analyze flight logs and found again a large difference between AHR2 and XKF roll and yaw mainly when the aircraft is close to vertical. I am wondering if it could be a bad accelerometer calibration of the vertical position.

I meant that switching to QSTABILIZE while tumbling might result in in some control instability due to large yaw torque demands. It would be interesting to see the log for that.
I’d also like to see the new log to check for evidence of aliasing effects in the IMUs.

the log of the video (airspeed does not work, I forgot to remove the pitot cap but airspeed use is 0)

the log with no control surfaces (only up to 150s)

the transition to fbwa is at 69s,
at 74s baro altitude =19m , airspeed=22m/s, Ahr2pitch= -46°, AHR2 rll = 82°
that was almost a big crash and I dont speak about trees that was very very close…

Servers by jDrones