In the sense that changing the controller dynamically is not an implemented feature, yes.
It seems like Copter uses the CC_* parameters to deal with controller switching, and those are not present in ArduSub.
ArduSub in general doesn’t have focused support for anything RC-related. As-is this seems like an intentional misuse of flight mode switching functionality to change the controller instead.
For reference, ArduSub can change flight modes (via the set mode MAVLink command), but there’s also currently no implemented mechanism for changing into a custom mode (or special handling to change to a custom controller). That includes up to the control station software level, so if you wanted to pull off the same trick via a custom control mode number that’s handled in addition to the existing modes (i.e. instead of replacing one of them) then you’ll also need to modify and re-build QGroundControl so that it knows about and allows you to change into the new control mode (unless you’re willing to send the relevant MAVLink message directly, via a script or some other means).
You can replace the normal controller, which I believe is how controller changes have traditionally been done. Granted that’s not as pleasant or convenient as being able to press a button to dynamically switch between controllers while operating, but it should at least be testable, especially if you’re comparing the effects of identical input sequences in a simulation.
Alternatively you could operate the vehicle in manual mode and intercept the motion control commands sent from the operator, then modify them before sending them on to the vehicle, but that involves some hassle and would then require operating on MAVLink telemetry data for the vehicle’s state predictions, which is at a lower frequency and higher latency than the vehicle firmware has access to.
The final option (that I can think of at least) would be to work on updating ArduSub to include the Copter’s newer controller switching functionality, and then be able to do things in a similar way to copter.
Thank you for your kind reply.
I’ve considered the second method (intercept the control commands). However, the open source code was too large and complex in structure (hard to understand the code).
Can i ask you a few more questions?
Where can I see the diagram related to the controller code of ArduSub?
Can you find an example of how to intercept commands?
If the method is complex and difficult, is it possible to customize it by using another board(i.e. arduino, openCR…) instead of BlueROV2’s pixhawk?
That does not currently exist. The closest thing would be the ArduCopter controller documentation, but the controllers are not exactly the same (because ArduSub assumes direct control over each motion axis, whereas ArduCopter achieves horizontal motion with a combination of thrust + pitch/roll)
There are a variety of MAVLink routing and proxy softwares, e.g. MAVProxy, MAVLink-router, MAVp2p. If you’re wanting to intercept commands then you’ll need to modify one of those (or make a new one) to allow passing through most MAVLink messages, but processing and modifying specific ones as relevant.
ArduSub can run on multiple different flight controller boards, but the main changes for supporting different boards are handled in the hardware abstraction layer (AP_HAL libraries).
Control system code is handled at a higher level of abstraction, so changing flight controller boards is largely irrelevant to the difficulty of writing a new/modified controller, assuming you want to use ArduSub. If you don’t want to use ArduSub then you could write an entire vehicle control firmware for your hardware of choice.
