Cool!
The foam parts of the FX-61 are a good start for a lot of projects. Great design, as is the wing-wing. I like to modify-sometimes radically- the basic airframe.
The drawback here is added complexity, so I solder everything I can, and avoid as many failure points as I can.
The ugly foam goatee is because tailsitters, even with wheels, tend to trip and fall on their faces in real life, and the foam cushions the impact, reducing the shock load on the motor vectoring servos.
Learned the hard way to make servos replaceable.
Thanks very much for the files. do I just download them, then move them to the .log folder in MP, and review them in the usual way|?
Did I tell you I was a newbie?
My thinking on the motors was to keep their weight and power penalties to a minimum, as well as their effect on the aerodynamics, since they will just be dead weight in level flight. Perhaps a mistake. Time will tell.
You must not load these parameters into your pixhawh as they include a lot of calibration parameters.
Mandatory calibrations are very important and the compass calibration can be tricky specially with an aircraft which fly vertically and horizontally. I advise you begin with default parameters and try to hover your plane as a dual motor tailsitter , then observe what has to be improved. Only at this stage you can compare my Q_parameters to default ones. In MP/config/full parameter there is a useful compare tool.
Because you begin with ardupilot, I suppose you already read http://ardupilot.org/plane/
Did you read the quadplane support pages ?
Iāve read the plane docs till Iām blue in the face. Iāve read the quadplane section also. I struggle with an ancient memory, so I read again and again, till it sticks.
I will take your advice about hover testing first with near-default parameters, and I would not copy any parameter list āwhole hogā (entirely). I still donāt know how to do it in any case.
I will need some lift assist from the main motor in order to hover well Iām sure, and Iām not sure of the best way to do that. I could just program it in as a third motor, linked to throttle position along with the wing motors, but then all three will be running at half throttle or so at liftoff and wing motors will be not able to stabilize well enough I fear. All aircraft of this configuration will need a different throttle curve for the wing-mounted motors vs. the main motor, with the wing powering up more strongly early in the curve. New parameter?
For early hover testing, I plan to set up a channel as a pass-through from a knob on my radio, run the main power up to 50% with the knob, and then lift off with throttle, but that seems really crude. A different throttle curve or mix could be easily done in OAVTOL, but Iāve read up on making mixers here, and itās beyond my knowlege at present. I get the concept, but I donāt know how to code it.
As for compass, itās internal, but itās in the very front inside the balsa nose, with nothing near it to cause problems except the battery.
Now what I need is a good swivel chair to calibrate the compass better!
Q_Tailsit_Input=0 is multicopter input mode, which is the mode I normally use. Does your vehicle rotate clockwise (viewed from above) when you apply right rudder in QHOVER mode?
No, it rotates counterclockwise when I apply right rudder in QHOVER mode (which is wrong). And when the plane is horizontal in FBWA mode, with I apply right rudder, the left motor speeds up (which is right).
So if I simply reverse a servo to fix the QHOVER mode then the FBWA mode will be wrong. Im not sure how to fix one without ruining the other.
It sounds like something is reversed somewhereā¦ but I canāt pin it down. Obviously start with your transmitter. Then move to servo reversals, then move to servo functions (and back to servo reversals).
when q_tailsit_input=0, in VTOL modes, rudder stick control plane aileron and roll stick control differential thrust. When your aircraft is hanged to its prop you have to imagine you are flying an helicopter with the nose in the belly position. When fbwa transition is done rudder stick control differential thrust and roll stick control ailerons.
When q_tailsit_input=1 rudder stick always control differential thrust whatever the mode.
This long introduction to say I am not sure whether you have a problem or not !!
hello Mark,
Finally I managed to get rid of this flash overflow error and have compiled your stryker quad code with the sign correction and differential thrust in ff. I tested it this evening with my modified wing which has now a top and a bottom motor. I also have to mention that I have kept the wing motors vectored. I have tested Q_hover and transition to FBWA. I can say your code works very nicely. Differential thrust works perfect in fbwa when elevator is used and maneuverability is very strong.The only complain is that motors can be spun with the elevator stick when motors are not armed. Back transition is really smooth, the best I have seen up to now.
Q_hover is very stable when the wing is prop hanged. Top and bottom motors respond as expected when the wing is pitched. But when flying fast forward in q_hover there is an uncontrollable tendency to climb whatever the throttle stick position. I have reduced q_m_spin_min from 0.35 to 0.25 but the problem remains. I believe this is because the reduction of control surface is too strong so there is not enough elevon throw at high lean angle. Also I can hear the top motor spinning very fast, (probably too fast). Are top and bottom motor constrained to keep altitude provided the throttle stick is centered?
I hope to post a video soon.
regards
pierre
Great news, Pierre! I wish I hadnāt destroyed mine on the second flight.
Iāll take a look at the arming issue. And yes, the top/bottom differential thrust is based only on pitch angle (itās the multicopter attitude controller), so I think youāre right about the need for more elevon authority. I guess itās probably worth adding a parameter to control that, now that youāve shown it can fly.
I believe the unexpected roll at the end of the video is due to the tendency to climb and too much reduction of control surface. I think I can replace the 0.5f magic attenuation by 1f in tailsitter.cpp . Am I right ?
Videos look great; I think the transitions look pretty smooth, and you do them at very low altitudes, too.
Yes, magic_attenuation is the parameter controlling the strength of attenuation when pitch > transition_angle. A value of 1 will result in a gain attenuation of transition_angle/pitch, so the max attenuation would be transition_angle/90. What value do you have for Q_TAILSIT_ANGLE (thatās the parameter which sets transition_angle)? If itās 45 degrees, then attenuation would ramp down from 1.0 at pitch of 45 degrees to 0.5 at 90.
That roll at the end of your second video is something Iāve seen too, and Iām not sure whatās causing it. I assume that was QHOVER mode. Can you post the log from that flight so I can compare it to mine?
I have also seen this funny yaw behaviour, it seems to suddenly not respond to yaw in one direction or yaw round through 180 or more. I have always put it down to the yaw integrator building up to fight wind in one direction then the wind shifts to catch the other side of the wing and the integrator and wind are acting in the same direction.
I havenāt had a change to have a more in depth look yet, except to see that the yaw I often reaches IMAX.
This is the log corresponding to both videos but there are more transitions in the log than in the videos and I cant say which one correspond to the video.
Q_tailsit_angle was 30
Q_angle_max was 5000
servo 8 is 89
servo 7 is 90
servos 6 and 5 are wing motors throttle.
From what I have seen, in q_hover, top and bottom motors are constrained by q_m_spin_min which is fine but they often hit the spin_max which explain the tendency to climb. Something which surprise me is the fact that this is the bottom motor that want to spin fast despite my full forward input with the elevator stick. I am pretty sure I have not miss wired top and bottom motors as I have verified top and bottom motor correct in the right direction when the wing is tilted.
@iampete , I totally agree with your remark concerning yaw integrator building and aerodynamic or wind effect. At the beginning of the tailsitter project, the problem was the pitch stability. With tilt motors or quad motor configuration this is no longer a problem. Now the main stability problem is with yaw.
I am back home and I have double checked the behavior of my wing. I can say that everything is in order. In fbwa the elevator stick cause a differential thrust in the right sens. The same in q_hover + self stabilization also in the right sens. So the styker quad code is OK.
So I changed q_tailsit_angle to 60 instead of 30 with q_angle_max still to 5000. If I am correct it should kill the attenuation. I made a test in q_hover and the flight is almost perfect. very very stable !! In that way it confirms the result I got with the Iampete fix in which I ended to set q_tailsit_thmx to 1.
@losawing Iām getting hundreds of errors from MAVExplorer reading your logfile, so I donāt think Iām seeing all of your flight. Are you also getting errors like this?
Skipped 530 bad bytes in log at offset 3014668, type=(4, 7, 0)
Skipped 3768825 bad bytes in log at offset 6701068, type=(85, 85, 85)
Skipped 477 bad bytes in log at offset 10485802, type=(32, 16, 255)
Skipped 530 bad bytes in log at offset 10551300, type=(32, 32, 32)
https://youtu.be/wgp4mF_53n4The data I do see shows very good yaw control, with no significant differences between ATT.Yaw and ATT.DesYaw.
So it looks like the elevon gain attenuation may not be necessary for your airframe, although Iām not sure whether elevons are handled differently for tilt-vectored tailsitters.
My pitch-angle-based elevon gain attenuation was intended for tailsitters with large elevons, but those are not necessary with thrust vectoring or 4 motors. So Iām not surprised that you would need less attenuation or none at all.
Hereās a video of my non-vectored tailsitter with tailsit_angle=45 and actual pitch angles of up to 60 degrees:
Pitch control was about right, but roll and yaw were a bit soft. I was lucky that it didnāt do any uncommanded 360 degree rolls at low altitude. At higher windspeeds, I was unable to avoid gaining altitude, but the effect wasnāt too strong. Of course a soft landing would have been impossible if the wind got any strongerā¦
I use mission planner / dataflash logs / review a log to analyse logs
I have checked right now and it works. But I am not surprised as I had to change the SD card this evening because of bad logging message.
I did a last test this evening with more speed in q_hover and I saw oscillations so the attenuation is needed but yes it depends on airframe and airspeed. Do you intend to make a parameter ? and to merge your branch ?
A last funny story, during my last test the back transition ended into the water again !! Not a big deal as the water is now over 20Ā°C. The conclusion is : do not try a transition if q_tailsit_angle > q_angle max. It seems there is not a lot of damage, only the 3.3V GPS voltage regulator is burnt.
Hello Mark,
I have had a look at your video. This is a lot of wind for a tailsitter. From what I have seen in my logs, when at high lean angle, the bottom motor spin almost at his maximum. This is at the expense of other motors, so at the expense on airflow on elevons. A simple test would be to reduce propellers size of top and bottom motor. Also I have the feeling this is not a stable situation to get the pull force sum well bellow the CG. A software solution would be to put more constrains on top and bottom motors output.
Pierre
