Took a week to get everything set up but we flew our first hover test yesterday with FF6 utilizing Arduplane. Other than me setting up the pitch control incorrectly and having it reversed from what I’m used to, it flew beautifully. Very responsive and very stable. Some hefty vibrations at times, more than likely due to using the beat up props from previous off field landings (don’t want to sacrifice the good props if I don’t have to just yet…). Looking to fix a few things and hover more before transitioning to forward flight but should be in the works in the next two weeks.
Quick rundown of what hardware we’re running:
FF6 DIY25 w/High Efficiency T-motor MT3506’s
Modified battery bays/fairings to hold two Turnigy Multistar 6S 5200 mAh Li-Po’s wired in parallel
RFD900x Telemetry Radio @25 dBm airside, 30 dBm GCS
Emlid Reach RTK onboard as GPS2; Base Reach injecting corrections via MP over telemetry
Seagull UAV #MAP2 camera trigger. Sony A6000 camera removed for hover test.
There was some RF interference from the RFD900 that was affecting the Reach initially and I’m not 100% sure we have it isolated just yet but we’ll chase it down.
The log looks good to me. I notice there is a bit of yaw bias, showing the vehicle has a bit of a tendency to yaw right, and it is needing to compensate. The counterclockwise motors are running at about 20% less power than the clockwise motors to counteract that yaw tendency. That reduces your overall throttle authority a bit.
Next step is a transition from QHOVER to FBWA. Make sure your elevons are setup right before you do that. Test that both in FBWA mode on the ground to make sure they move correctly to stabilise when you roll/pitch the aircraft, and check with stick input that it gives the right response. Also check that RC input reversal is right for pitch.
Hope it goes well!
btw, with logs, you only need to upload the bin file. That contains all the info (including the parameters)
I’d also note that support for FF6 is in master now, so you can just load ‘latest’ firmware from the build server. No need to use my custom firmwares.
I’m also seeing a yaw bias on QHOVER, and I assume it’s caused by a bit of a crosswind on the tail. Could we get weather vaning as an option for QHOVER? I’m also really missing VFWD in QHOVER to prevent pitching the wing down to penetrate the wind. I wrote a github issue on this. https://github.com/ArduPilot/ardupilot/issues/4478
Might think about tuning the hover a little more, I’m guessing some type of PID tuning might clear up the yaw bias? New territory for me here. The autotune flight mode currently transitions to forward flight so I’m under the assumption that to tune the hover, I’d need to use this method:
I’m not sure that we have the full scope of your yaw issue so I would hesitate to run autotune on a frame like this.
Tridge said,
The log looks good to me. I notice there is a bit of yaw bias, showing the vehicle has a bit of a tendency to yaw right, and it is needing to compensate. The counterclockwise motors are running at about 20% less power than the clockwise motors to counteract that yaw tendency. That reduces your overall throttle authority a bit.
What were the wind conditions during this log and were you pointing the node into the wind?
It might be worth a simple test to perform a short hover in calm conditions pointed into whatever breeze exists. Then yaw to the left a bit, hold, back to center, then yaw to the right a bit, hold, and back to center. A log from this basic flight might reveal more information.
Lastly, how is the yaw control? Does it feel ok for manual flying?
Winds were light, say 1-3kts. out of the southwest with no gusts. I tried to keep the nose into the wind for the most part other than a 360 yaw turn to the left and a partial one to the right. Yaw seemed to hold but the logs tell the tale better than my memory. The control I had a problem with was the pitch. Without any pitch deflection, the ship wanted to drift backwards at a steady pace, say 1-2 m/s. Emails to Erich F previously had indicated that was normal flight in ALTHOLD/QHOVER. Easy fix I suppose to just use QLOITER.
Next flight will be the sequence you describe with a yaw left, center, and right.
How can I choose TRI_FRAME? I installed normal ArduPlane to pixhawk and enabled Q_. In frame option there are only quad, hexa, Y6 and similar, but no TRI. I added FRAME_CLASS_COAX=5 in quadplane.h and also added in quadplane.cpp the following:
AP_GROUPINFO(“FRAME_CLASS”, 30, QuadPlane, frame_class, 5),
…
case FRAME_CLASS_COAX:
setup_default_channels(6);
motors = new AP_MotorsCoax(plane.scheduler.get_loop_rate_hz());
break;
Compiled it, and chose flight modes as QSTABILIZE, but when I look at the output from Main out 1-6, they are all in 50Hz and doesn’t correspond on COAX motor output.
Edit:
Even if I choose all of the modes to be QSTABILIZE, flight mode doesn’t change. It stays at RTL after I load firmware and connect to MissionPlanner. If I disconnect and connect again, mode changes to Manual, but I cannot change it. I change the PWM, and Flight Modes are highlighted with green, but Current Mode still stays same. I downloaded tridge/ardupilot and compiled that. It still has the same thing. Did anyone had that? Happens even if I arm it.
I just cloned Github, and chose Q_FRAME_CLASS = 7. I’m sorry for my ignorance, I replugged it again, and it suddenly started working. So I went back and uploaded my original one with COAX_FRAME and have another problem. All of the Main Out’s seem to be correct according to Hz output: 1,2, 5,6 - 400 Hz, 3,4 - 50 Hz. That was how I set them up. However, they don’t respond well to my transmitter except for Throttle. Pins 5,6 are motors, and they respond correctly. Servo 1 responds to Aileron, Servo 2 responds to Elevator, Servo 3,4 doesn’t respond to anything. Do I need to change parameters somewhere to connect Transmitter channels to pitch, roll, and yaw? It works perfectly for ArduCopter, but I’m thinking maybe I need to change something since Channels start from 5 for Quadplane mode.
I have a question regarding outputs to servos. In QSTABILIZE mode, I checked the servo and motor pin outputs with oscilloscope and they respond incorrectly. When DISARMED, motor outputs doesn’t respond to Transmitter, which seems to be correct, and when I arm them, they respond correctly. Pins 1-4 are for servos, and when DISARMED, Servo 1 responds to Aileron, Servo 2 to Elevator, Servo 3,4 no response. When ARMED they act the same. How it should act is: Servo 1 = Elevator+ Rudder, Servo 2 = -Elevator+ Rudder, Servo 3 = -(Elevator+ Aileron), Servo 4 = Elevator- Aileron. I changed to COAX_FRAME in quadplane.cpp, and changed the Q_FRAME_CLASS. What could be the cause of it acting like that? It seems to be not linking servos properly to AP_MotorsCoax.cpp.
now I’m puzzled, do you have a coax frame or a tri frame? Maybe you could post a picture of your vehicle along with what motors and servos are connected to what outputs?
you can actually have channels in any order now in 3.8.0beta3, just set SERVOn_FUNCTION to the right function for each
sounds like you want both VTAIL and ELEVON mixing? That isn’t possible right now, but it could be added.
i’m really puzzled by your frame type, is it really a coax or a tricopter?
@tridge thank you for reply. I’m building tiltrotor bicopter. I modified AP_MotorsCoax for that. It has 2 motors, 2 servos that tilt each motor, and 2 servos for elevon. I put COAX_FRAME as 5 in quadplane.h and .cpp and compiled it. However, when I check the output signals, it seem to correspond to different frame or something. Two motors are supposed to react to throttle and roll only, but they also react to pitch. Servos that should tilt should be: pitch + yaw, but instead one of them reacts to roll only, second to pitch only. Elevon servos doesn’t react to anything. How can I activate AP_MotorsCoax in QSTABILIZE? It seem to connect to different file, not AP_MotorsCoax.
Edit:
In the new update, where can I add the frame? It quadplane.cpp TRI = 7, and enum frame_class { FRAME_CLASS_QUAD=0, FRAME_CLASS_HEXA=1, FRAME_CLASS_OCTA=2, FRAME_CLASS_OCTAQUAD=3, FRAME_CLASS_Y6=4, FRAME_CLASS_COAX=5, };
is removed from quadplane.h. So where can I add another class? Is there a reason TRI = 7, and 5,6 are skipped?
Edit:
Found the problem! My pins correspond to Plane mode: Pins 1-4 are Roll, Pitch, Throttle, Yaw. I enabled Q_ENABLE, and changed FRAME_CLASS to 7. Flight modes are all QSTABILIZE, pins still correspond to Plane mode. What other parameters do I need to activate in order to activate FRAME_CLASS = TRI?
After some discussions with Marco I’ve done a PR for setting the downward tilt rate and upward tilt rate separately:
it also changes it so that if you switch to MANUAL mode then it will tilt the rotors forward at least at 90 degrees/second. That makes MANUAL a viable recovery mode for good pilots.