The CM4 is NOT officially supported. @williangalvani has successfully run BlueOS on CM4 hardware before, but not with a Navigator connected. It MAY work, if the pin mapping is the same on your breakout and things for the CM4 are all configured properly.
Give the instructions in the note at the end of this issue a try, and please let us know how it goes! (Use the install script, running Raspian Bookworm official image for the CM4.) If you get to the BlueOS web interface and download the system logs from the gear icon in the lower left, and share that zip file here. Thanks!
This differs from the original BlueOS image installation, where only:
/dev/i2c-20
/dev/i2c-21
were present.
GPIO configuration
sudo pinctrl get 2
Output:
GPIO02 = SDA1
sudo pinctrl get 3
Output:
GPIO03 = SCL1
I²C scan
sudo i2cdetect -y 1
Detected devices at:
0x48
0x76
This suggests the CM4, Waveshare carrier board, and Navigator hardware are communicating over I²C.
BlueOS Installation
After confirming the above, I installed BlueOS using the installation script as suggested, rather than using the prebuilt BlueOS image.
After installation:
/dev/i2c-1 is still present
GPIO2/3 remain configured as SDA1/SCL1
BlueOS starts normally
I can access the BlueOS web interface
Current Issue
Despite the above, the Navigator board still does not appear in the Autopilot Firmware page and is not detected by BlueOS.
At this point, it appears that:
The I²C bus is available
Devices are visible on the I²C bus
BlueOS is running correctly
Navigator is still not being recognized by the firmware detection process
Is there any additional device-tree overlay, Navigator-specific driver, or CM4-specific configuration required for Navigator detection on a CM4 + Waveshare carrier board?
Please let me know what additional logs or diagnostics would be helpful. I can also provide the BlueOS system logs ZIP if required.
The install process should configure all the required overlays. These are the devices, address, and buses that BlueOS scans to detect the Navigator.
Try checking the buses manually using `i2cdetect -y [bus]` to check if they are available as expected.
I’m also interested in the output of `blueos_startup_update.py`. You can run this in the terminal and then find the logs in system logs.
I would like to clarify one point regarding our hardware setup.
We are using a Raspberry Pi CM4 mounted on a Waveshare CM4 carrier board. According to the Waveshare documentation, the GPIO header pinout is identical to the standard Raspberry Pi 4B 40-pin header, and the Navigator is connected through this header.
After following the recommended approach:
Installed Raspberry Pi OS (Legacy) 64-bit (Bookworm)
Enabled I²C
Installed BlueOS using the install script
Verified that /dev/i2c-1 is available
Verified that GPIO2 and GPIO3 are configured as SDA1 and SCL1
Detected I²C devices at addresses 0x48 and 0x76
From these results, it appears that there is at least some communication occurring between the CM4 and the Navigator over I²C.
However, the Navigator still does not appear in the BlueOS Autopilot Firmware page.
Since the GPIO mapping on the Waveshare CM4 carrier board is the same as a Raspberry Pi 4B, should the Navigator theoretically be detected in this configuration?
Also, is there a recommended way to verify whether the Navigator is actually interacting correctly with the CM4 beyond the I²C scan results? For example:
Which specific I²C devices/addresses should be visible on a correctly detected Navigator?
Are there any additional buses that should contain Navigator devices?
Are there any commands or logs that can confirm successful Navigator detection at the Linux or BlueOS level?
We are trying to determine whether:
The CM4 is successfully communicating with the Navigator but BlueOS is failing to recognize it, or
The Navigator is only partially detected and some required devices are not being enumerated.
Any guidance on how to conclusively verify Navigator-to-CM4 communication would be very helpful.
We followed the Navigator-lib Raspberry Pi OS instructions and tested the setup on our CM4 + Waveshare CM4 carrier board.
Steps performed:
Flashed Raspberry Pi OS (Bookworm / Raspberry Pi OS Legacy 64-bit).
Ran the board configuration script exactly as mentioned in the Navigator-lib documentation:
sudo su -c 'curl -fsSL https://raw.githubusercontent.com/bluerobotics/blueos-docker/master/install/boards/configure_board.sh | bash'
sudo reboot
During the process, the system rebooted multiple times automatically. We waited until the system stabilized and became accessible again.
After booting successfully, we checked BlueOS again, but the Navigator still did not appear in the Autopilot Firmware tab.
We also attempted to manually upload/install firmware through the firmware page, but the Navigator was still not detected and we were unable to proceed further.
Additional observations:
I²C is enabled and available.
/dev/i2c-1 is present.
We can detect devices on the I²C bus (previously observed addresses such as 0x48 and 0x76).
The CM4 is mounted on a Waveshare CM4 carrier board whose GPIO mapping follows the standard Raspberry Pi 40-pin header.
At this point, could you please advise how we can directly verify whether the Navigator is being detected by the operating system itself (independent of BlueOS)?
Would you recommend running specific Navigator-lib example scripts or diagnostic commands to confirm whether:
The CM4 can communicate with the Navigator correctly, and
All expected Navigator devices (ADC, IMU, barometer, PWM controller, etc.) are being detected?
If there are any expected i2cdetect outputs, specific device addresses, or Navigator-lib test commands we should run, we can provide those results as well.
@adarsh_05 yes, please run the examples, there is some docs on lib/github or even here in the forum. The example use all the sensors.
But as far I remember it should directly with BlueOS once installed in CMs too, I remember to discuss and ask to add this to the .sh scripts during some mvp.
Per the detection file (which Willian linked to earlier), bus 1 should show devices at 0x48, 0x76, and one of 0x0C or 0x1E, while bus 4 should show a device at 0x40.
There is also a CPU detection requirement which may not be allowing for CM4 boards, though that is currently only the case on the master branch (not in 1.4 releases). It would be helpful to know what the output of cat /proc/cpuinfo is on a CM4 board - I suspect the model will match your /proc/device-tree/model check from earlier, in which case that filtering will be relevant if you’re running on master.
If the expected I2C devices are present, and assuming you ran the install script without a specified version, I would recommend using the BlueOS Version page to download a 1.4 core image and seeing if it detects your board normally. You may need Pirate Mode enabled for the version manager to show older versions.