no argument from me on that!
can you post a picture of your aircraft? Are you OK with working out the right parameters to set or do you need some help?
When my friend send me some photo I’ll post, now he building the mechanism for tilt motors. I thinks that when we started the test the help will be appreciated
the airframe is 1.7kg without the battery, and the battery is 433g, so it is 2.1kg total
Thank you very much for the reply! I have a question about modification. Since quadplane is using multicopter code for hover and then transitions to plane mode if I insert my own frame in these lines in quadplane.cpp:
…
case AP_Motors::MOTOR_FRAME_BICOPTER:
setup_default_channels(6);
break;
…
Is that all I need to change? Or if I simply keep let’s say MOTOR_FRAME_TRI, but change the AP_MotorTri.cpp to bicopter, will that be easier? I currently just modified AP_MotorCoax.cpp because it has same amount of motors and servos as bicopter of mine. Also, how can I build the file? Do I type smth like: make px4-v2-quadplane? And then change to Q_ in mission planner?
It depends how your airframe is setup. There needs to be extra code if the code that handles the hovers shares the same output channels as the code that handles forward flight. For example, you will see extra code in ArduPlane/tiltrotor.cpp to handle use of some of the vertical lift motors for forward thrust.
If your bicopter frame uses separate output channels then it is indeed very simple to integrate the new frame type. If not there there is some extra work required. If you can post a picture of your airframe and explain the control outputs then I may be able to offer suggestions.
You don’t need to do a special build, just build the plane code as usual, and set Q_ENABLE=1 as a parameter.
I’d also strongly suggest you get it flying in SITL first before you test on a real aircraft.
Cheers, Tridge
Rotors are tilted with servos, roll works with thrust differential, yaw works by tilting one rotor forward and another backwards, and pitch is controlled by tilting both rotors in the same direction, and the mixer is as following:
actuator[0] = - rp_scale*pitch_thrust + yaw_thrust; // Right
actuator[1] = - rp_scale*pitch_thrust - yaw_thrust; // Left
_thrust_yt_ccw = thrust_out - roll_thrust; // Right rotor motor
_thrust_yt_cw = thrust_out + roll_thrust; // Left rotor motor
output pins are same as Coax: pins 1,2 - servos, 5,6 - motors, 3,4 - elevon servos.
Thanks in advance
Tridge,
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.
Bin:
Log:
Params:
RC set up:
Great job, Tim. I would just turn the power down on the RFD900 for now. It’s not like you will be flying in the 6-25 mile distance for a while.
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
@tridge, I’m experiencing some strange RTL behavior. When you have some time could you take a look at this? Quadplane Hybrid RTL confusion
Thank you.
I’ve replied on the issue with a suggestion on how to tune QLOITER to better suit your handling needs
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:
http://ardupilot.org/plane/docs/common-transmitter-tuning.html
Might take a bit to get configured but hope to try it out next week if that seems the best method.
we are making tilt rotor that it’s have tow bruchless motors and tow servo motots for tilting and we use APM 2.5 what is the suitable code for it?
A pixhawk is required, the APM 2.5 will not work.
Tim,
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?
Greg,
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.
Thanks for the help and interest.
Hello,
In quadplane.cpp:
"#if FRAME_CONFIG == TRI_FRAME
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.
Thanks in advance
If you are using the current 3.8.0beta3 then just set
Q_FRAME_CLASS=7
and reboot