BlueOS Navigator Board Detection

Blue Robotics Software BlueOS
1

Hello,
One more question about hardware. I’am trying to make my own “navigator” board using the blueos. I have seen in the software a function detecting the card by adressing four I2C devices.
I have plugged such devices on a breadboard. But unfortunatly my setup is not recognized as a naviagator one. How the sofware is detecting the navigator board? Do I need something else? I have only the SITL board available when using the frontend interface.
But the way what is the function of the EEPROM? is there some informations enabling the detection write in?
Thanks a lot
Best regards

1 Like
2

Hi @ThierryB,

I’ve moved your comment to its own post, because it’s on a new topic.

Interesting - are you willing to share more information about that, and why you’ve chosen to make your own? :slight_smile:

I asked about this internally and was told that BlueOS’s Navigator detection logic just checks for the existence of the sensors at the expected I2C bus. If your setup is failing to be recognised as a Navigator you should confirm:

  1. The sensors are physically connected to their expected buses
    • bus 4 for the PCA9685, bus 1 for the others
  2. The sensors are working and actually detectable at their expected addresses
    • you can use i2cdetect, which is available from BlueOS’s web terminal
      • stay in the docker - no need to red-pill

The EEPROM was originally included because we were aiming to make the Navigator a valid Raspberry Pi HAT. There were other reasons that ended up being not feasible, but the EEPROM could still be useful for storing identification and configuration data. Since BlueOS can detect the Navigator from its sensors alone that’s not a hard requirement right now, and the EEPROM is not currently being used, but we do not guarantee it won’t be used in the future (e.g. it could be helpful to distinguish Navigator variants or versions, if that becomes relevant).

3

Hi Eliot,
Thanks for your quick response.
Well clearly my motivation is to simplify the hardware suppressing some unusefull fonctions accoding to a ROV use, like Bus command, or RGB LED, reduce number of serial to just have the necessary function onboard.
Well I used i2cdetect and on bus 1. I’ seen Baro at 0x76, Analog at 0x48 and Mag at 0x0C. So these chip are connected and responding.
The PWM is normaly connected to bus 4 if I have the last version of your schematics. But ‘i2cdetect 4’ returns /dev/i2c-4' or /dev/i2c/4’: No such file or directory
In the code you switch on bus 4 : bus = SMBus(4). So it seems to be really pluged on bus 4.
Do you know were this issue come from? It seems just like the I2C bus 4 was not declared or existing in the OS?
Thanks a lot for your help. I appreciate. Your BlueOS is perfect and the consol application is at the top.
Best regards.
Thierry

4

Ok then. The Navigator was designed to be useful for ROVs of all kinds, but I suppose our goals of modularity and easy expandability with external devices are not important to your project, in which case I suppose it makes some sense to strip back to only the essential components for your particular build, if that will save on costs.

Are you using a Raspberry Pi 4B?

BlueOS is made to be able to run on multiple systems, but our current Navigator board is only compatible with Raspberry Pi 4B. I get that error when I try to read on I2C bus 4 from my Raspberry Pi 3B, but it works fine when I read it on my Raspberry Pi 4B.

It may be possible to use a different Raspberry Pi model, but doing so would presumably require changing BlueOS to check a different bus, and making a custom ArduSub firmware that can work with your setup, and may also have issues with insufficient CPU performance.

5

I’am using a raspberry PI 3B. The issue comes from that point.
Ok clear for me. Thanks a lot Eliot.
Best regards

1 Like