Plane: quadplane: improve mav_type reporting for GCS#21596
Plane: quadplane: improve mav_type reporting for GCS#21596tajisoft wants to merge 1 commit intoArduPilot:masterfrom
Conversation
|
@IamPete1 @peterbarker Thank you for your wonderful support! I pushed a fix. Solved the problem I was facing with my quadplane being misidentified as fixed wing. No further changes are required for this issue at this time. Thank you again. |
|
Looks like this is confusing MAVProxy.
|
|
@IamPete1 It seems so. I think I need to add MAV_TYPE handling to pymavlink and MAVProxy. Adding VTOL is expensive, so I would like to modify MAV_TYPE_VTOL_* to be treated as FIXED_WING as before. What do you think? |
tajisoft
force-pushed
the
patch-plane-report-vtol-mavtype
branch
2 times, most recently
from
70571be to
0368353
Compare
|
Fixed pymavlink and MAVProxy. Verified that the following commands display correctly on the simulator.
|
|
I found this confusing Mission Planner. I am looking into it. |
I was mistaken. The mode was displayed correctly in Mission Planner. |
peterbarker
left a comment
peterbarker
left a comment
There was a problem hiding this comment.
I can see TILTROTOR being a thing here.
I don't think we should generally be changing MAV_TYPE mid-flight, however.
Upstream now has MAV_TYPE_VTOL_FIXEDROTOR which would be relevant for many of our motors-frames.
@tajisoft did you want to pursue this?
peterbarker
force-pushed
the
patch-plane-report-vtol-mavtype
branch
from
0368353 to
9f955db
Compare
|
I have adjusted this PR to only magically change our vehicle type to a known-good subset of the types. So VTOL_QUADROTOR and VTOL_TILTROTOR. MAVProxy is going to do odd things on other frames, so continuing to use FIXEDWING is the safer solution here until more elaborate GCS changes are made. Tested in SITL. |
| if (!available()) { | ||
| return MAV_TYPE_FIXED_WING; | ||
| } |
There was a problem hiding this comment.
I think this quadplane check needs to before the mav_type param check. Otherwise I could enable quadplane, set a mav type and disable quadplane again and still have Q_MAV_TYPE taking affect.
There was a problem hiding this comment.
Hi @IamPete1. I was tajisoft before and I'm RtoS now.
So you're pointing out that this order is better? I certainly agree.
if (!available()) {
return MAV_TYPE_FIXED_WING;
}
if (mav_type.get() != 0) {
return MAV_TYPE(mav_type.get());
}
|
Need to double check mission planner and QGC still detect the correct vehicle type after this change. |
| } | ||
| switch (motors->get_frame_mav_type()) { | ||
| case MAV_TYPE_QUADROTOR: | ||
| return MAV_TYPE_VTOL_QUADROTOR; |
There was a problem hiding this comment.
This one is now tailsitter specific upstream.
There was a problem hiding this comment.
So I have to fix it like this:
switch (motors->get_frame_mav_type()) {
case MAV_TYPE_QUADROTOR:
return MAV_TYPE_VTOL_TAILSITTER_QUADROTOR;
default:
break;
}
There was a problem hiding this comment.
You would need to check tailsitter is enabled. Something like:
if (tailsitter.enabled() && (motors->get_frame_mav_type() == MAV_TYPE_QUADROTOR)) {
return MAV_TYPE_VTOL_QUADROTOR; // This is MAV_TYPE_VTOL_TAILSITTER_QUADROTOR upstream
}
5 participants
I am using QGC. When connected to QuadPlane, it is recognized as Fixed-Wing. This happens setting Q_MAV_TYPE to the default 0. You can work around this by setting it to something other than 0.
I know this issue has been discussed in #7137 but it doesn't seem to be fixed. 0 is auto so I would expect it to report correctly. I don't know if my suggestion is good, but I'll make a PR. Please give me your comments and advice.