Custom Board - A more flexible board detector

[goasChris]

Hello and welcome!

Why

I wanted to have a discussion around opening the door for a more generalized / custom board implemented in blueOS.
For instance, we currently have a use case where we need to be more efficient with the physical space in our robots, and we've essentially re-arranged the physical location of some of the Navigator parts, which also resulted in SMBus and addresses getting shuffled around a bit.

This means that this check will of course fail:

BlueOS/core/services/ardupilot_manager/flight_controller_detector/Detector.py

Lines 22 to 37 in 9a0a1b6

	def is_navigator_r5_connected() -> bool:
	try:
	bus = SMBus(1)
	ADS1115_address = 0x48
	bus.read_byte_data(ADS1115_address, 0)
	AK09915_address = 0x0C
	bus.read_byte_data(AK09915_address, 0)
	BME280_address = 0x76
	bus.read_byte_data(BME280_address, 0)
	bus = SMBus(4)
	PCA9685_address = 0x40
	bus.read_byte_data(PCA9685_address, 0)
	return True

Now, the board has the same components (ADS115, AK09915, BME280 and PCA9685), and should be able to be treated as a regular r5 navigator (at least in theory).

In order for us to continue with this custom board, we would need to fork and maintain blueOS and swap out the values, which is a bit of unfortunate busy work, and is likely to run us into some conflicts in the long run. I also saw on the forums that we were not the first to try using a board that is a bit different, and figured it would warrant some discussion.

---

Suggestions / Solutions

If possible, it would be very neat if it is possible to either pass in custom values (while keeping the defaults, of course), somehow. Either thru simply reading a text file, reading env or similar. Could maybe even be supplied at docker build time.

Bigger picture and much larger change, could perhaps be to supply one or several new functions in the Detector class, where one could essentially construct a custom board with supported components, or something to that effect. I admit I have not thought too much about the bigger scenarios one could support if one wishes, just airing some ideas.

---

It is not lost on me that there is a cost to supporting more variants and custom boards, not only in tech debt, but also in support. I appreciate anyone taking the time to comment on a possible solution, and I am more than happy to assist or even implement the suggested design, should this be a feasible idea.

cc @rafaellehmkuhl (as requested)

[rafaellehmkuhl]

Chris, I was thinking about this problem. The main question here I think is: how to support multiple ways of detection?

Some boards will be detected on I2C eeproms, others by identifying specific sensors, that can be on different I2C buses, in the SPI, etc. How can we make something generic enough?

The easiest approach that could already add s lot of value (it would support both the Navigator, the Argonoth and also your board) would be to allow specifying a list of I2C buses and addresses to be fetched from. This list could live somewhere where the user could edit it easily, maybe the bag of holding, or a config file (that could be edited with the built-in file-manager).

Another approach could be to make the ArdupilotManager board detector to try to parse and read python files stored in a fixed folder, that defines a standard-named function for board detection. There could be a file for each board, for example. The user could support his own board by only adding a new file with it's board detection script to that folder.

What do you think about those?

[goasChris]

I think the easiest approach is sufficient. From a support point of view, the second option seems a bit intimidating (still, nice to have).

[patrickelectric]

Hi Chris. At the moment you can contribute directly with ArduPilot Manager and add your hardware definition in the code to include support to you custom hardware. Is there a reason why a fork is necessary ?

Custom board support is really tricky.
At the moment ardupilot hardware definition is hardcoded, for each hardware, you need a new firmware. So besides detecting the hardware, the user also need to provide a firmware.
For Px4 this is different, we are currently working to add support, the hardware definition is the board definition file, so we could use it dynamically to choose the board.

So.. the user could provide a custom definition file for us to check it and load a firmware, but they could also contribute to BlueOS as well.
I believe that an easy solution at the moment, would be to just allow the user to choose a firmware and ask ardupilot manager to run it, without board detection and validation, and use such firmware for each boot.

[goasChris]

Thank you for your input Patrick. Yes, the easy way out sounds like it would handle our use case, and with minimal support cost. I must admit I am a little bit surprised by the willingness to potentially accept a custom board, when I would imagine it to be very niche, and unlikely to be useful for others. I'll have a chat with the team, about how best to proceed.

Thank you you all for your input so far, it's been very helpful :)

[patrickelectric]

Hi Chris, there is no problem for us to support your board/firmware. Be free to submit the necessary PRs for that.

[goasChris]

Just to clarify, as I am not super well versed in all of the different systems working together. We want to submit a PR in order to properly support our custom board.

We have a custom firmware based on ardusub and ardurover, and we will continue to maintain this. We can probably make some changes to it if needed.

We would only need to submit a PR to the blueOS repository that alters the board detection code to detect our card?

Please confirm, and if not, what are the other repos we need to PR? The ardupilot manager lives in the blueOS repo, correct?

[patrickelectric]

Hi @goasChris you can add your linux board here:
https://github.com/patrickelectric/BlueOS-docker/blob/e1cf5e41d7531494bdc82f5d61ebe1e24431f0f1/core/services/ardupilot_manager/flight_controller_detector/Detector.py#L24
Custom firmware here:
https://github.com/patrickelectric/BlueOS-docker/blob/e1cf5e41d7531494bdc82f5d61ebe1e24431f0f1/core/services/ardupilot_manager/ArduPilotManager.py#L186

You can follow "Argonot" board and "Navigator" board as exmaple.
Here you can check Argonot support: https://github.com/bluerobotics/BlueOS/pull/1625/files

[goasChris]

I have a PR ready and tested. However, we are going to hold off on submission for a while, since our hardware are going thru some revisions. However, there is a new issues that has arisen. Turns out we need the serial configuration feature. When I define a custom board, then I lose access to this:

Example submission code:
goasChris@361cccc

If you have some pointers one how I could bring back this feature to my custom board? @patrickelectric @rafaellehmkuhl
I don't need the fancy graphics for now, as long as I would be able to map the hardware devices to internal blueOS "serial numbers".

[patrickelectric]

Hi, are you implying that the serial port configuration menu is not working at all ?

…

On Tue, Aug 6, 2024, 04:47 goasChris ***@***.***> wrote: I have a PR ready and tested. However, we are going to hold off on submission for a while, since our hardware are going thru some revisions. However, there is a new issues that has arisen. Turns out we need the serial configuration feature. When I define a custom board, then I lose access to this: image.png (view on web) <https://github.com/user-attachments/assets/efb74cb8-0d3c-46ae-aad1-f7d1b218f3eb> Example submission code: ***@***.*** <goasChris@361cccc> If you have some pointers one how I could bring back this feature to my custom board? @patrickelectric <https://github.com/patrickelectric> @rafaellehmkuhl <https://github.com/rafaellehmkuhl> I don't need the fancy graphics for now, as long as I would be able to map the hardware devices to internal blueOS "serial numbers". — Reply to this email directly, view it on GitHub <#2630 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJIYCJ46GIEUIM7XZVCANLZQCZTZAVCNFSM6AAAAABILHICO6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTAMRVGI4TGMQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[goasChris]

I'm implying that the button/dropdown does not exist when the custom board (non-navigator) is detected. The website UI only shows the "firmware update" button/dropdown. I'll see if I can get you a screenshot and perhaps some log output (or anything else you might want).

[goasChris]

Ardupilot service Log:

...
2024-08-06 10:48:27.906 | WARNING  | flight_controller_detector.Detector:is_navigator_r5_connected:49 - Navigator not detected: [Errno 121] Remote I/O error
2024-08-06 10:48:27.907 | WARNING  | flight_controller_detector.Detector:is_argonot_r1_connected:59 - Argonot not detected: [Errno 121] Remote I/O error
2024-08-06 10:48:27.909 | DEBUG    | flight_controller_detector.Detector:_detect_linux_board:91 - NaviCube detected.
2024-08-06 10:48:27.924 | WARNING  | ArduPilotManager:start_ardupilot:520 - More than a single board detected: [FlightController(name='NaviCube', manufacturer='**** Robotics', platform=<Platform.NaviCube: 'navicube'>, path=None, flags=[]), FlightController(name='SITL', manufacturer='ArduPilot Team', platform=<Platform.SITL: 'SITL_arm_linux_gnueabihf'>, path=None, flags=[])]
2024-08-06 10:48:27.925 | WARNING  | ArduPilotManager:get_board_to_be_used:433 - Preferred board not set yet.
2024-08-06 10:48:27.925 | INFO     | ArduPilotManager:start_ardupilot:523 - Using NaviCube flight-controller.
2024-08-06 10:48:28.018 | INFO     | ArduPilotManager:start_linux_board:240 - Using command line: '/root/.config/ardupilot-manager/firmware/ardupilot_navicube -A udp:127.0.0.1:8852 --log-directory /root/.config/ardupilot-manager/firmware/logs/ --storage-directory /root/.config/ardupilot-manager/firmware/storage/ -C /dev/ttyS0 -B /dev/ttyAMA1 -E /dev/ttyAMA2 -F /dev/ttyAMA3 -H /dev/serial/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.3:1.0-port0 '
2024-08-06 10:48:28.023 | DEBUG    | mavlink_proxy.AbstractRouter:start:99 - Calling router using following command: '/usr/bin/mavlink-routerd 127.0.0.1:8852 0.0.0.0:14660 0.0.0.0:17770 --endpoint 192.168.2.1:14550 --endpoint 127.0.0.1:14000 --tcp-port 5777 -l /root/.config/ardupilot-manager/logs -T /root/.config/ardupilot-manager/logs'.
2024-08-06 10:48:31.031 | DEBUG    | mavlink_proxy.AbstractRouter:_log_stderr:154 - Router: mavlink-router version v4
2024-08-06 10:48:31.346 | INFO     | logging:callHandlers:1706 - Started server process [121]
2024-08-06 10:48:31.348 | INFO     | logging:callHandlers:1706 - Waiting for application startup.
2024-08-06 10:48:31.352 | INFO     | logging:callHandlers:1706 - Application startup complete.
2024-08-06 10:48:31.353 | DEBUG    | mavlink_proxy.AbstractRouter:_log_stderr:154 - Router: Could not open conf file '/etc/mavlink-router/main.conf' (No such file or directory)
2024-08-06 10:48:31.356 | INFO     | logging:callHandlers:1706 - Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit)
...

Chrome console log:

UI/UX:

Hope this helps a bit more for context @patrickelectric