Change vehicle type with mavsdk and load parameters

I am developing a multi-modal vehicle that has 4 wheels (rover configuration) and 4 propellers (copter configuration).

When I select the airframe as skid-steered rover and configure the actuators appropriately, the vehicle drives as expected. When I select the airframe as generic quadcopter and configure the actuators and geometry appropriately, the vehicle flies as expected.

I would like to change the vehicle type through mavsdk/mavlink messages. Further, I would like to load the appropriate parameters, namely the geometry configuration and output configuration. I am aware of the mavsdk commands to upload parameters and/or reboot the vehicle. These parameters seem so play a particular role for changing the vehicle type from rover to copter: SYS_AUTOSTART, CA_AIRFRAME

If I change these parameters, afterwards reboot the vehicle, and then try to upload the remaining geometry and output configuration parameters using mavlink, I end up having only a subset of the geometry/output parameters configured. I need to re-upload the parameters/reboot the vehicle several times until all parameters get uploaded. It is confusing that seemingly always some geometry parameters do not get uploaded.

What would be the correct approach to change between a rover and copter configuration? Creating two custom airframes with default parameters and store the parameters directly on the SD card?

@maxinho For me what you are experiencing are hysteresis effects on QGC UI, I don’t think chaging SYS_AUTOSTART or CA_AIRFRAME during runtime is actually what you want.

SYS_AUTOSTART is configured such that the right rcS script would be run at boot, and this also resets some of the parameters (such as control allocation) in order to avoid the user configuring the actuators the wrong way.

I would probably suggest that you need a your own custom SYS_AUTOSTART(one airframe), which runs(through your own vehicle specific rcS) a list of modules that is only relevant for your applications. Since PX4 is architected as a pubsub system, you can still reuse the modules and features that you are interested in.

A good example you can look at is VTOL vehicles, which has its own specific vehicle type and rcS, but runs both the fixed-wing related controllers, as well as rover related controllers.

1 Like

Thx @Jaeyoung-Lim for your prompt response and the explanations.

That sounds like I have to dig (slightly more) into the internals of the PX4. I’ll likely not have the time for it atm and have to fallback to manually configuring the frame after changing the vehicle type in the GUI (with several restarts etc.). That’s okay for now to evaluate the robot’s feasibility.

Ultimately, I’d like to switch the actuation system on a button press from wheeled mode to flying mode. As soon as i find time, I might look more into creating a custom sys_autostart, airframe etc.

@maxinho From what I see, the easiest way to achieve this is a) implement a custom px4 module, where you add the actuator switching logic in, and reuse all the other modules as you need. b) If you have a mission computer onboard use the mode registration through the px4 ros2 SDK library

Hi @Jaeyoung-Lim,
Once again, thx for putting thought into this.

I don’t have a mission computer onboard, but I guess I can also use the mode switching mode from the QGS or via mavlink/mavsdk to change mode.

@maxinho Yes, but in order to use the mode registration, you need a mission computer running ROS2 PX4 ROS 2 Control Interface | PX4 Guide (main)

Otherwise, you would need to implement flight modes on the FMU, which might require a lot more invasive modifications on the px4 side.

The reason I was suggesting implementing a new module is that you can keep your stuff contained in your module and therefore have less troubles fighting with the rest of PX4.

Cool, thx.

I wasn’t aware of the new ROS2 Control Interface. That’s either way my more comfortable terrain. I’ll look into this eventually and maybe add a small companion computer (or have the companion computer offboard, but streaming the relevant messages).

I am experiencing this too, and I am not doing anything special. I modified the arm lengths for a Generic Quadcopter and when I reboot via Parameters → Tools. the arm lengths get reset in the GUI. To get around this I quit QGC and re-open when I need to reboot / refresh params.

edit: hallelujah! I found that my issue was just due to the SYS_AUTOCONFIG being set to 2 somehow (which is not one of the enumerated values and shows as “Unknown: 2”). Setting it back to 0 stopped the param resets.