Spacecraft Build and Bare Control Allocator

[Pedro-Roque]

Solved Problem

Provides support for spacecraft-like vehicles available in https://github.com/DISCOWER/PX4-Space-Systems . This PR introduces spacecraft board for SITL, as well as a barebones allocator for preliminary spacecraft build targets.

Solution

• Add spacecraft SITL board
• Add barebones spacecraft control allocator

Changelog Entry

For release notes:

Feature/Bugfix: Support for spacecraft vehicles
New parameter:
Documentation: 

Test coverage

• Simulation/hardware testing: more info here http://atmos.discower.io/

[github-actions]

🔎 FLASH Analysis

px4_fmu-v5x [Total VM Diff: 24 byte (0 %)]

    FILE SIZE        VM SIZE    
--------------  -------------- 
+0.0%     +24  +0.0%     +24    .text
  +0.0%     +14  +0.0%     +14    ROMFS/nsh_romfsimg.c
  +0.0%      +7  +0.0%      +7    [section .text]
  +0.2%      +3  +0.2%      +3    ../../src/systemcmds/ver/ver.cpp
+0.0%     +56  [ = ]       0    .debug_abbrev
   +11%     +56  [ = ]       0    ../../src/lib/version/version.c
-0.0%      -8  [ = ]       0    .debug_aranges
  -5.0%      -8  [ = ]       0    ../../src/lib/version/version.c
+0.0%      +8  [ = ]       0    .debug_info
  -0.2%      -4  [ = ]       0    ../../src/lib/version/version.c
  +0.0%     +12  [ = ]       0    ../../src/modules/control_allocator/ControlAllocator.cpp
-0.0%     -16  [ = ]       0    .debug_line
  -1.3%     -25  [ = ]       0    ../../src/lib/version/version.c
  +0.0%      +2  [ = ]       0    ../../src/modules/control_allocator/ControlAllocator.cpp
  +0.6%      +7  [ = ]       0    task/task_cancelpt.c
-0.0%      -8  [ = ]       0    .debug_ranges
  -2.6%      -8  [ = ]       0    ../../src/lib/version/version.c
+0.0%     +28  [ = ]       0    .debug_str
  +0.1%     +28  [ = ]       0    ../../src/modules/control_allocator/ControlAllocator.cpp
-0.2%     -24  [ = ]       0    [Unmapped]
+0.0%     +60  +0.0%     +24    TOTAL

px4_fmu-v6x [Total VM Diff: 16 byte (0 %)]

    FILE SIZE        VM SIZE    
--------------  -------------- 
+0.0%     +16  +0.0%     +16    .text
  +0.0%     +17  +0.0%     +17    ROMFS/nsh_romfsimg.c
  -0.0%      -1  -0.0%      -1    [section .text]
+0.0%     +56  [ = ]       0    .debug_abbrev
   +11%     +56  [ = ]       0    ../../src/lib/version/version.c
-0.0%      -8  [ = ]       0    .debug_aranges
  -5.0%      -8  [ = ]       0    ../../src/lib/version/version.c
+0.0%      +8  [ = ]       0    .debug_info
  -0.2%      -4  [ = ]       0    ../../src/lib/version/version.c
  +0.0%     +12  [ = ]       0    ../../src/modules/control_allocator/ControlAllocator.cpp
-0.0%     -24  [ = ]       0    .debug_line
  -1.3%     -25  [ = ]       0    ../../src/lib/version/version.c
  +0.0%      +2  [ = ]       0    ../../src/modules/control_allocator/ControlAllocator.cpp
  -0.1%      -1  [ = ]       0    task/task_cancelpt.c
-0.0%      -8  [ = ]       0    .debug_ranges
  -2.6%      -8  [ = ]       0    ../../src/lib/version/version.c
+0.0%     +28  [ = ]       0    .debug_str
  +0.1%     +28  [ = ]       0    ../../src/modules/control_allocator/ControlAllocator.cpp
-0.0%     -16  [ = ]       0    [Unmapped]
+0.0%     +52  +0.0%     +16    TOTAL

Updated: 2025-02-06T18:48:53

[Pedro-Roque]

@dagar @sfuhrer Inputs are welcome on this - Should I start by adding build target followed by the control modules, or should I go the other way around?

[sfuhrer]

@dagar @sfuhrer Inputs are welcome on this - Should I start by adding build target followed by the control modules, or should I go the other way around?

You mean what to work on next? Should we clean up the build target / airframe side, then add SITL, then the low level control module (rate, possibly attitude)?
You'll also need to rebase since #24199 caused diffs. How do you plan to enable the metric allocation, hard-coded per vehicle type or configurable per parameter(s)?

[Pedro-Roque]

@dagar @sfuhrer Inputs are welcome on this - Should I start by adding build target followed by the control modules, or should I go the other way around?

You mean what to work on next? Should we clean up the build target / airframe side, then add SITL, then the low level control module (rate, possibly attitude)? You'll also need to rebase since #24199 caused diffs. How do you plan to enable the metric allocation, hard-coded per vehicle type or configurable per parameter(s)?

Thanks for the prompt reply @sfuhrer ! Ok great, I was planning on proceeding exactly in that order, so its a perfect since. Currently I've added a build target with airframe and SITL, as well as a control allocator (just so that I could have the build target configure the sc_apps and sc_defaults.

Let me know if I should remove control allocator and just proceed with airframe. The issue is that none of the apps are then loaded, but that could go together with ca_allocator. What do you think?

[DronecodeBot]

This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-sync-q-a-jan-29-2025/43479/4

[DronecodeBot]

This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-sync-q-a-jan-29-2025/43479/1

[Pedro-Roque]

@MaEtUgR I've pushed CA_AIRFRAME to control_allocator, as suggested. Should we keep this PR as is and I add control allocation on the next PR?

[DronecodeBot]

This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-sync-q-a-feb-05-2025/43562/1

[Pedro-Roque]

@dagar I made it to work without functionThrusters while keeping CA_THRUSTERx params.

So it should be alright!

Now we could merge this in but the current failure comes from a checker that looks at all yaml's and xml's to check for duplicates - this will fail due to duplicate params in my and control_allocator params. The only to avoid this is to combine it all in control_allocator, but that's not a good idea as we discussed. However, for now, perhaps it is?

Thoughts? @Jaeyoung-Lim @MaEtUgR