BlueRov2- Method for additional sensor integration

Hey,

I have managed to integrate other sensors on my ROV through the method below.

Would be great to hear peoples thoughts or suggestions on how to improve it.

More than happy to elaborate on anything i have done!

Our method inputs all additional sensors through an Arduino to take advantage of its analogue ports and ease of use.

  1. Attach sensor to Arduino and Create script to serial print data

image

  1. Download Putty to enable connection of raspberry pi and computer http://www.putty.org/
    Open putty window and in logging, ensure “all session output” and browse location to which data is stored.

Power on ROV and connect to topside PC. To access the raspberry pi, enter its IP address (192.168.2.2) as host name and open.
In putty command terminal, enter the user name (pi) and password (raspberry) to access raspberry pi.

  1. Create new python script on raspberry pi
    sudo nano scriptname.py

To read com port the script below was used

import serial
ser = serial.Serial(‘/dev/ttyACM1’, 9600)

while 1 :
ser.readline()
print(ser.readline())

  1. Turn off power to ROV. Remove the USB connection from pixhawk and insert into top left serial port as this is automatically designated ACM0 which will be required for pixhawk communication. Any remaining serial port can be used for Arduino connection and should automatically be designated ACM1.

  1. Turn on ROV and again access the onboard raspberry pi via putty. Run command

python scriptname.py

Sensor data should now be being displayed in putty terminal even when Qgroundcontrol is running.

Next steps
• Linking sensor power to main battery
• Fitting in and attaching the additional sensor and electronics
• Using acquired data for feedback controls of ROV

3 Likes

Owen,

This is fantastic - thanks for sharing! This is actually very similar to our long-term plan for payload integration. Basically, anything that is added will be connected to the Raspberry Pi via USB or other method and then send that data through UDP to the surface computer.

If you want to get a sneak peak at the development for that, you can actually check out the “Routing” page on the new ArduSub Companion WebUI (http://192.168.2.2:2771/routing when you have the vehicle connected). This page will allow the creation of “end points”, such as an Arduino’s serial connection or a UDP port, and will allow you to connect those end points together. That will allow you to connect a serial device to the surface computer without writing any code.

This is still very early in development so I can’t guarantee how well it will work.

I’m very glad to see that you chose to follow a similar path! Keep it up.

-Rusty

Very nice!

I’ve got a couple notes about your python program:

import time << for sleep()
import serial
ser = serial.Serial(’/dev/ttyACM1’, 9600)

while 1 :
ser.readline() << You can take this out, you are loosing half of your data here!
print(ser.readline())
time.sleep(0.01) << Wait 0.01 seconds. Without this, the script will utilize 100% of one of the cpu cores.

Hey,

Thanks for the input!

One of our sensors will require power from from the main battery. Would it be possible to see a more detailed circuit diagram of the BlueRov2 ?

Hey Owen,

thanks for sharing!

@LinK To take Owen’s approach a step further: I’m really interested in accessing RC commands from a XBox Controller via Python on the Pi to trigger events like setting/resetting GPIO pins or issuing specific messages via the serial interface of the Pi. Is there a best practice?

Thank you in advance!

-Patrick

@Owen, sorry I missed this. Here is a diagram of how everything is connected:

@collaxo

Can you clarify? Do you want to connect a joystick controller directly to a Raspberry Pi?

This is already supported (GPIO pins on the Pixhawk).

@jwalser I’d like to press one of the (yet unused) buttons (e.g. ‘A’) on the XBox Controller to execute code / run a script on the Pi that then should control some Pi-GPIO pins. I didn’t change the default setup of the BlueROV2.

My current understanding is that the Pi runs MavProxy and forwards all communication from the surface computer to the Pixhawk via MavLink protocol. I’m wondering how and where to integrate own code on the Pi to be able to react to RC commands sent by the XBoxController via QGroundControl. Is there any tutorial / documentation on this?

No.

The current code is not really designed for this; the RC commands are directed toward the pixhawk and only the pixhawk.

There are a few different approaches you could take to modifying it to your liking. I would suggest setting up a mavproxy module to ‘snoop’ for the MANUAL_CONTROL (joystick information) packets. You can then handle the joystick information however you want on the Pi, before passing on to the pixhawk.

Okay. I just found a thread on ArduPilot.org about this topic (Adding RPi GPIO switch functionality to MAVProxy - #8 by JAR4x4 - MAVProxy - ArduPilot Discourse) and started to read up on module development in MAVProxy. Actually it seems pretty straight forward.

Thank you for your support!

-Patrick

Another tip:

You can add this hook to your module, it will be called automatically from another thread every time a mavlink message is decoded by mavproxy.

Cool, thank you!

@jwalser Hi Jacob, just one last question on mavlink messages: I managed to set up a new simple module in MAVProxy which listens on incoming mavlink messages on the Pi. When looking for messages which describe button press events, i noticed that my first guess RC_CHANNELS(_RAW) does not include any information on button actions. Furthermore, i never received MANUAL_CONTROL messages from QGC, which would include a field “buttons”.

Do you know where i could find some (raw) information about button presses?

Thank you very much in advance for your support!

-Patrick

Do you have a joystick plugged into QGC? The message you are after is MANUAL_CONTROL.

In the mavproxy console, try the command watch MANUAL_CONTROL.

Yes, it’s a XBox 360 Controller. I’m using QGC v3.2.4-BlueRobotics-Rev2 and everything is working fine with the controller.

If i execute “watch MANUAL_CONTROL” in MAVProxy, i could receive MANUAL_CONTROL messages including the “buttons” field. But i’m not able to receive MANUAL_CONTROL messages via the mavlink_packet callback function. Is this a bug in MAVProxy?

The mavlink_packet hook looks like this:

   def mavlink_packet(self, m):
        '''handle mavlink packets'''
        mtype = m.get_type()
        if mtype == "MANUAL_CONTROL":
            print m.buttons

Hm, I may have made an incorrect assumption that the hook would fire on ALL messages passing through mavproxy. Maybe it’s just the ones from the --master system (autopilot). Can you check this? You can print out a message on every HEARTBEAT showing the sysid of the heartbeat. That will let you know quickly.

Source system ID of the heartbeat is always 1, so it seems that the mavlink_packet hook only fires on messages coming from the Pixhawk…

What do you recommend?

  1. Extend the custom_1-method in ArduSub/joystick.cpp and generate a new mavlink NAMED_VALUE_INT message with button state
  2. Adaption of MAVProxy to fire “mavlink_packet” on all incoming messages (Will probably result into negative side effects…)
  3. Adaption of MAVProxy to fire “mavlink_packet” on all incoming messages from Pixhawk and on MANUAL_CONTROL messages from QGC
  4. Use one of Pixhawk’s serial interfaces with Arduino and use GPIO pins there

Thank you in advance!

Just extended the custom_1-method in ArduSub/joystick.cpp. After selecting “custom1” for button 0 (=‘A’) in QGC joystick settings, everything works as expected.

I think, using the GPIO pins of an additional Arduino via the telem2-port on the Pixhawk will do the job best.

-Patrick

@collaxo If you don’t neccessesarily need the GPIO on the pi that sounds like a fine solution. Can you share what you need to do with the GPIO? You might be able to use the gpio on the pixhawk without too much trouble.

I’m currently working on a simple payload for the BlueROV2, which will be able to take up to 4 x 50ml water samples. Each sampling procedure will be invocable by a press on the ‘A’-button of the XBox 360 Controller. The GPIO pins are needed to operate a MOSFET 4 board (http://bit.ly/2heYZnh), which controls four electromagnets.

To use the Pi would have simplified the whole integration process without additional hardware and with a single MAVProxy module (simple GPIO handling, file logging, no altering of ArduSub)

What do you mean with GPIOs on the Pixhawk?