My second test of the Ranger EX QuadPlane had an added air speed sensor and an upgrade to APM Plane v3.8.0 beta 5. We took off in QSTABILIZE mode which worked perfectly into the 14mph breeze. The odd noise during initial takeoff was a passing motorcycle. Just after transitioning to FBWA mode, the plane wanted to pitch upward and loose control. I quickly recovered back in QSTABILZE mode and repeated the test. On the ground, I re-tested the control surface compensation and it was correct.
Back at home, a question from Cala had me looking at the Q_FRAME_CLASS and Q_FRAME_TYPE parameters. Apparently, the firmware upgrade changed my Q_FRAME_CLASS setting from 0 to 1 which previously meant hexacopter not quadcopter. Without yet looking at the logs, this may or may not have been my issue in FBWA mode.
I hosted my log file below from the latest test flight. I would appreciate any help in looking for something wrong. At this point, if I don’t find a solution to my FBWA issue, I will likely revert back to v.3.6.0 and see if it still exists.
Thanks for posting this. You have motivated me to convert my Ranger. I had similar issues to you with a recent Skywalker conversion. It turned out to be mostly an issue with the COG. Sorry if I’m stating the obvious as I assume you have checked that. Hopefully someone will have a look at your log and provide more help.
My technique, which worked great on my Bix3 QuadPlane conversion, has been to fly the plane first as stock in Manual mode and then FBWA mode. Once this works great with APM Plane (which has been v3.6.0), I then add the quadcopter portion keeping the same CG as before.
Are you suggesting that the CG changes for a QuadPlane?
Unless the quadarms significantly change the aerodynamics I wouldn’t expect the COG/COL to change. The QP COL can be different than the plane one provided the quad motors have enough lift and it will still fly, but the plane one has to be spot on for the wings for forward flight, and should stay the same as without the Quad parts, provided they don’t produce lift.
With a firmware update we make it a habit to either reload the last good parameter file or use the MP comparison feature to check the parameters. It shouldn’t always, but we’ve had frequent parameter changes after firmware upgrades, in particular from the beta ones. There’s also a RC channel setup/mixing update in 3.8 that you need to double check, so I’d do a complete parameter setup from scratch for 3.8.
Without looking at the log properly (yeah I’m one of those ) I don’t know whether what your experiencing on transition is due the Q_FRAME_CLASS setting. In fact I’m finding it hard to figure out how that thing flew in hex config as only the 2 and 3 motors are the same in quad and I can’t tell which ESC are plugged into what RC channels. From the ferocity of the pitch change in the video it looks like the pitch up is from the quad motors and not from wing control surfaces. It looks like the rear quad motors go off while the front motors go to max. In the log ch5 and 6 saturate prior to the pitch up, and strangely in the first transition they track eachother perfectly.
Also where is your current sensor connected in the power loom? From a quick look at the RCout your quad motors don’t have much headroom and your current goes up to around 90A (12.9V), so I expect the quad drivetrain is all on one current sensor? Is it rated for that much power? It also looks like your PXH isn’t getting enough voltage at only 4.5V VCC. I’d only put the power module and current sensing on the forward motor and put the quad motor direct to a battery to be safe. We’ve lost airframes like that before with the power module browning out at 120A.
I’d probably try going over the parameters again and make sure the frame/class setup is correct including the output function numbers for the correct RC numbers etc. and then do another hover test to make sure everything is as it should be. Whilst you’re at it have a look at how your QP ESC/motor temps are doing after a few minutes of hover.
Hopefully, the devs can find the cause and whether this is related to the uprising frame.
As I understood, your flew directly in FBWA mode without transitions before without any issues,COG should be ok.
Hi Jeff, yes this is good advice that I have not been doing when upgrading firmware.
I am using a Mauch PM with 100 amp sensor and 5v regulator. They are usually quite accurate. I would suspect that 90amps at full quadrotor throttle is correct and it probably reached that level when changing to QSTABILE to save the plane. I will check the logs.
Hi Rolf, thanks for looking! Yes, your understanding above is correct. On the test flight prior to this one, recall that I was using v3.6.0 without an air speed sensor and it flew fine in FBWA mode until I turned into the 15mph (7.5m/s) wind where it stalled. Then I learned quickly about the need for an air speed sensor!
It looks like the normal current for QSTABILIZE mode hover on take-off is around 60 amps. Normally, this hover period for take-off and landing would be as brief as possible so I did not add much overhead in my power system design. The current spikes around 80-90amps are mostly transitory and possibly due to the loss of control when switching to FBWA mode. I would not expect the forward flight motor to draw more than 20amps at full throttle but I should probably measure this. The flight battery voltage seems to handle the load without issue. I did feel the ESCs after the flight and they were just barely warm.
I found the old and new sections of QuadPlane code that upgraded the frame_class so the new value for a quad is 1 and if you still have a 0 from before, which now means unknown, it sets the value to 1. So the frame_class setting was not my issue in FBWA mode.
// frame class was moved from 30 when consolidating AP_Motors classes
#define FRAME_CLASS_OLD_IDX 30
// @Param: FRAME_CLASS
// @DisplayName: Frame Class
// @Description: Controls major frame class for multicopter component
// @Values: 0:Undefined, 1:Quad, 2:Hexa, 3:Octa, 4:OctaQuad, 5:Y6, 7:Tri, 10: TailSitter
// @User: Standard
AP_GROUPINFO(“FRAME_CLASS”, 46, QuadPlane, frame_class, 1),
// @Param: FRAME_TYPE
// @DisplayName: Frame Type (+, X or V)
// @Description: Controls motor mixing for multicopter component
// @Values: 0:Plus, 1:X, 2:V, 3:H, 4:V-Tail, 5:A-Tail, 10:Y6B
}
/*
dynamically allocate the key objects for quadplane. This ensures
that the objects don't affect the vehicle unless enabled and
also saves memory when not in use
*/
motor_class = (enum AP_Motors::motor_frame_class)frame_class.get();
switch (motor_class) {
case AP_Motors::MOTOR_FRAME_QUAD:
setup_default_channels(4);
break;
case AP_Motors::MOTOR_FRAME_HEXA:
setup_default_channels(6);
break;
case AP_Motors::MOTOR_FRAME_OCTA:
case AP_Motors::MOTOR_FRAME_OCTAQUAD:
setup_default_channels(8);
break;
case AP_Motors::MOTOR_FRAME_Y6:
setup_default_channels(7);
break;
case AP_Motors::MOTOR_FRAME_TRI:
SRV_Channels::set_default_function(CH_5, SRV_Channel::k_motor1);
SRV_Channels::set_default_function(CH_6, SRV_Channel::k_motor2);
SRV_Channels::set_default_function(CH_8, SRV_Channel::k_motor4);
SRV_Channels::set_default_function(CH_11, SRV_Channel::k_motor7);
AP_Param::set_frame_type_flags(AP_PARAM_FRAME_TRICOPTER);
break;
case AP_Motors::MOTOR_FRAME_TAILSITTER:
break;
default:
hal.console->printf("Unknown frame class %u - using QUAD\n", (unsigned)frame_class.get());
frame_class.set(AP_Motors::MOTOR_FRAME_QUAD);
setup_default_channels(4);
break;
}
Ah phew…the QP universe does conform to the frame rules!
I didn’t even notice the frame # change with 3.8, good to know.
Did you have a chance to look at your low VCC voltage and fly it with a fresh parameter setup? It would be nice to know if the issue still persists. Thanks for testing!
You are right about the rather low Vcc voltage. I haven’t looked into it other than comparing the two graphs below and verifying that there were no resets during the flight. The Mauch current sensor is a true hall sensor so 90 amps is not an issue as there is no resistance in the LiPo supply line.
The upper image is from my latest flight using v3.8.0 beta 5 firmware with an analog air sensor, and, the lower image was from the previous flight using v3.6.0 without the sensor. Other components powered by Vcc are my X8R receiver, M8N GPS and 900MHz telemetry unit. The servos and ESCs are powered by a separate CC BEC.
For my next test, I have reverted back to v3.6.0 firmware where I have had previous success. Assuming that works ok, I will then use your suggestion of forcing a new parameter setup. Do you think loading Rover code prior to upgrading to v.3.8.0 is a good technique?
I’d also save your current params before using rover to overwrite. I’d take the opportunity to setup the params from scratch and use the MP compare afterwards to double check everything. That way it’s 100% not a “funny” setting somewhere.
It’s a bit weird that the VCC looks better on 3.6, but that could be a series of things, some of which only intermittently occur. Do you have a Companion Computer onboard as well running on the same UBEC? Are you using a RFD900 radio or a 3DR? It would be good if it stayed over 4.8-4.9V with everything running.
I forgot that you are in Winter down under. Our summer has been windy and wet so far. In fact, I did not get to fly yesterday as my 4-wheel drive Ford Expedition truck got stuck in the mud going to the back of our private field where I did the last flight test and video. We tried to get the truck free yesterday but failed so I left it there overnight but took my R/C stuff home.
Today, we will try to free my truck again. Ahh, the R/C adventures we have!
We have more sand than mud where I normally 4x4. But I do use the Disco or Mavic to scout ahead through the bush from time to time before I drive through with the Landcruiser. In particular it’s useful before driving through the surf to get around rock outcrops on the beach to see if it’s passable. I try to fly every chance I get now, plus it’s good practice for when you really might need to get off-road to get past a washed out bridges etc. We had three bridges washed out this year too, but that was from unusually heavy summer rain. One is a $10m fix no one wants to pay for so the only way across is currently via a sand bar, a 2 hour detour or to buy a ferry to get the car across.
No luck getting my truck out. A good Samaritan came to help and he got stuck so we spent the day getting him out. That night it rained most of the night so Monday you couldn’t even walk on the normal part of the field. We’ll try again Friday so hopefully I can get back to the fun stuff soon!
I measured my Vcc with a Fluke multimeter at 4.84v which seems to agree with the graphed log above. I pulled out both the air speed sensor and telemetry unit connectors and the voltage remained the same. Perhaps my Mauch PM voltage on this unit is just a bit low but it seems to hold.
My buddy got my truck back off the field so I’m back having fun with R/C again. Friday we plan to go to an AMA flying field and test the Ranger again. Hopefully, v3.6.0 will function properly for FBWA and CRUISE modes and then I can try v3.8.0 from a fresh load after first loading Rover to clear the parameter list.
I had similar issues to you with a recent Skywalker conversion. It turned out to be mostly an issue with the COG. Sorry if I’m stating the obvious as I assume you have checked that. Hopefully someone will have a look at your log and provide more help.
) I don’t know whether what your experiencing on transition is due the Q_FRAME_CLASS setting. In fact I’m finding it hard to figure out how that thing flew in hex config as only the 2 and 3 motors are the same in quad and I can’t tell which ESC are plugged into what RC channels. From the ferocity of the pitch change in the video it looks like the pitch up is from the quad motors and not from wing control surfaces. It looks like the rear quad motors go off while the front motors go to max. In the log ch5 and 6 saturate prior to the pitch up, and strangely in the first transition they track eachother perfectly.
