Available Addresses on I2C Bus 1 for Additional Sensors

Blue Robotics Software
,
1

Hello!

I’m trying to create our own altitude sensor to connect to our BlueROV. It’s mainly a Raspi that outputs float data through the I2C bus. I used 0x04 as a temporary address. I tried connecting it to Pixhawk’s I2C Extender but it seems to be conflicting with the Bar30 sensor. With that, what are the available I2C addresses that can be used by additional sensors? I’m currently in the process of writing a driver but not sure which address to use.

Thanks!

2

Hi Angelyn,

How are you going to communicate with this sensor ? Have you done modifications in ArduSub source code ? Can you provide this changes ? What you want to accomplish as your final objective and how do you want to do it?

3

Hi Patrick,

As mentioned, communication will be through I2C. I haven’t done modifications yet on the source code but I read in a thread here that I need to make my own driver for the sensor.

Final objective is to have an additional mode similar to Depth Hold – Altitude Hold. So the ROV needs to be at a fixed distance from the seafloor for surveying, ie. it should be able to adjust its depth automatically on a slope.

Right now, we have a sensor that gives us distance data from the seafloor. I would like to connect it to Pixhawk, read its data and modify the control system to use this data.

4

Hi,

Thank you for your explanation, there will be no problem if you are going to write your own driver, since it’s not possible to connect sensors that ArduSub does not have support.
Bar30 I²C address is 0x76, so there will be no conflicts.

5

With that, what are the available I2C addresses that can be used by additional sensors?

You will need to refer to the schematic for your autopilot and the device datasheets connected to the i2c bus. I expect there is not much connected by i2c on the autopilot, and as @patrickelectric mentioned, the bar30 is at 0x76.

6

Thank you for your replies!

We currently have the Bar30 and Temp Sensor connected on the I2C bus. When I connected the Alt Sensor that just sends out signals to address 0x04, its values conflicted with Bar30. But, I still have to write the driver for the Alt Sensor to accept signals in that address. I’ll keep you posted.

By the way, which drivers are used by BlueRobotic’s Bar30 and Temp Sensor? Would like to confirm if they are the ff:

AP_Baro/AP_Baro.h
AP_TemperatureSensor/TSYS01.h

I checked it in Sub.h file. Maybe I can use these as basis for the new driver.

OR

Would it be much easier if I use the driver for Temperature Sensor (libraries\AP_TemperatureSensor) as basis since I’m only sending 1 integer value anyway?

7

By the way, which drivers are used by BlueRobotic’s Bar30 and Temp Sensor?

The Bar30 is MS5837 and the Celsius is TSYS01.

Would it be much easier if I use the driver for Temperature Sensor (libraries\AP_TemperatureSensor) as basis since I’m only sending 1 integer value anyway?

Perhaps. As with any algorithm, there are numerous ways to accomplish the same thing.

I recommend picking up the Ping1D echosounder, which is already supported by ardupilot, and will likely save you a lot of time and effort sorting this out.

8

Hi Jacob,

Apologies for the late reply.

Thank you for the recommendation but we’re actually trying to come up with a different type of altitude sensor that involves image processing instead of acoustics.

I’ve actually written the I2C driver already, built and uploaded the firmware. Unfortunately, I’m having troubles with it so I decided to take a step back and start from the beginning again:

I checked out Sub-3.6 from GitHub as instructed here, built and uploaded it to Pixhawk. Then connected the sensor to the I2C bus and ran the code that will send data (RasPi). Once it sends data to I2C, QGC gets disconnected and hangs. Now, what is odd here is that when I try to upload ArduSub 3.5.4, the stable version, and send the same data through I2C, it just conflicts with the other data. QGC doesn’t hang or gets disconnected. Any clues on why this is?

By the way, I also tried building Sub-3.5 just to check if the issue can be replicated, but couldn’t build it. Keep receiving this error:

waf-light: error: option --board: invalid choice: ‘Pixhawk1’ (choose from ‘aero’, ‘aerofc-v1’, ‘bbbmini’, ‘bebop’, ‘bhat’, ‘blue’, ‘dark’, ‘disco’, ‘erleboard’, ‘erlebrain2’, ‘linux’, ‘minlure’, ‘navio’, ‘navio2’, ‘px4-v1’, ‘px4-v2’, ‘px4-v3’, ‘px4-v4’, ‘pxf’, ‘pxfmini’, ‘raspilot’, ‘sitl’, ‘urus’, ‘zynq’)

Ok, also tried with Sub-4.0. It doesn’t disconnects and QGC doesn’t hang. Something might be up with Sub-3.6.

9

Ok, there are several problems here:

  1. You can’t just send data from your sensor to the autopilot whenever you want, this will interfere with normal operation of the application and hardware. The autopilot is the I2C master, and your sensor must send data only when addressed by the master.

  2. You can’t just connect your sensor to ArduSub, because ArduSub has no software support (i2c driver) for your sensor, and does not know how to communicate with it. You need to write a driver that addresses your slave sensor and requests data.

  3. ArduSub 3.6 only ever reached beta, and never reached stable. 3.6 development has been abandoned in favor of our 4.0 beta, and you should not use 3.6 in any event.

  4. To build ArduSub 3.5 you must use px4-v2 for the pixhawk, or one of the other targets listed instead of Pixhawk1.

  5. I recommend continuing the remainder of your testing with ArduSub 4.0.