increased number of external mode to 16

[feoz0]

Solved Problem

Thanks to px4-ros2-interface-lib it is possible to register to PX4 a certain number of external modes that are implemented in ROS2. Currenlty the number of external modes is limited to 8, this PR brings it to 16.

Solution

• aded 8 external mode where needed
• changed navigation_mode_group_t to a uint_64_t instead of uint_32_t to allow more modes
• increased the uORB queue to 32 for the ArmingCheckReply message
• changed the reported modes to a uint_64_t in HealthAndArmingChecks --> this was done to avoid PX4 reporting some modes as not ready but without any error message

Changelog Entry

Alternatives

It wold be ideal if the number of external modes could be a configurable parameter that could be changed at build, I believe this would be an increadible benefit. I wasn't able though to make it like that since the number of external modes is practically hardcoded everywhere, so this fix brings the number to 16 but also allows for more modes. Any suggestion regarding these changes is very well accepted.

Test coverage

• tested on simulation and on a real hardware, not much to report as for the logs

Context

[farhangnaderi]

@feoz0 Have you tried the param based approach?
Also you know why CI is failing?

[feoz0]

HI @farhangnaderi, thanks for the quick reply! If you are referring to set a PX4 parameter to decide the number of modes, I did try that but wasn't able to make it work since the number of external mode is hardcoded even in the vehicle_status message. If you have any suggestions on how to avoid that issue, feel free to propose me.

On the other hand, CI failing made me realise that there is still a small bug, for instance altitude mode becomes not ready even if it would be. I'll get back on that and I'll try to solve it.

[feoz0]

HI @farhangnaderi, I have fixed the bug that was making part of the CI fail. In addition to that I've changed the CI since it was using the bitmask for 8 external modes, I've now made it more flexible so that if later the modes are augmented, it won't fail again!

Let me know what do you think about it

[feoz0]

HI @farhangnaderi everything looks good on the CI side except the Jenkins one which is failing for some reason I don't really understand, could you help me out?

[dakejahl]

I think we should have @bkueng look at this before we merge.

[bkueng]

I did not expect that someone already hits that limit.
What is the reason you need so many? I'm asking because there might be alternatives.

[feoz0]

Hi @bkueng, the reason is pretty easy: we implement everything as an external mode in practice and the drones we produce have a lot of different modes that are specific to the use case. We already hit the limit and have been using the changes I am proposing with this PR already for a few weeks. We could eventually compact some modes and put them togheter but I think it would be beneficial for everyone the increased number of modes

[bkueng]

Ok makes sense. We can increase it, it doesn't come for free though.
I'll have a closer look.

[feoz0]

perfect, thanks @bkueng, let me know how it goes

[bkueng]

From what I see you covered most of it. There's these 2 places that also need to be updated (both somewhat recently changed):

• https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/fw_mode_manager/FixedWingModeManager.cpp#L1971
• https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/commander/failsafe/failsafe.cpp#L483

[feoz0]

@bkueng I added all the changes you asked and the fixes! I see CI is failing because of some issues that I did not introduce though

[bkueng]

Thanks, the CI flash overflow failure might be real, as a bit more flash is used. You can rebase and check if it's still an issue.

[feoz0]

@bkueng yes the overflow is a real issue introduced by this PR, do you know what I could do? should I decrease the modes by one?

[bkueng]

@bkueng yes the overflow is a real issue introduced by this PR, do you know what I could do? should I decrease the modes by one?

I expect the switch to 64 bits adds the most flash, not the actual mode count.
@alexcekay do you have more flash savings?

[alexcekay]

Hi @bkueng, @dagar,

one possible FLASH saving that I thought about would be removing the bootloader binary from the ROMFS.
I would decouple the BL_UPDATE and allow to have the bl_update tool without it storing the bootloader to the ROMFS.
Then the user could still do a bootloader update by pushing the bootloader onto the SD card. I would need to make changes there anyway. I am thinking about this change on v5x and v6x.

This would not be too much effort and save us some ~10K. What are your opinions?

[bkueng]

Yes I would remove the bl binary.

[feoz0]

HI @bkueng, what should I remove precisely? should I keep the change in this PR or make another one?

[bkueng]

@alexcekay is looking into it (#25469). Once there's more flash you can just rebase.

[alexcekay]

Hi @bkueng, @feoz0,

just realized that we do not even include the BL in the v6x, only in the v5x. So with the PR I mentioned we can only save FLASH on the v5x, which is not the problem here.

There are not a lot of options left to quickly save FLASH:

• Disabling drivers
• Not including longDesc in the parameters.json. This saves some ~36K, then we would still have a simple parameter description in QGC and the extended one for example only online. Need your opinion here, also @mrpollo, @dagar

To get some real win we need to split by vehicle model, but sadly I currently can't allocate enough time to push this.

[dakejahl]

@alexcekay another way we can save a huge amount of flash is by selectively compiling mavlink messages/features. It's also not a quick/easy solution but just wanted to bring it to your attention as an option
#22930

[dakejahl]

This can come in once rebased and once #25715 is merged to free up flash

[hamishwillee]

So 16 external modes. Does this need to be documented in the user guide? Perhaps pointing here so that people can find latest version if it changes.