I want to communicate to pixhawk from Raspberry pi 3 and read the telemetry data like accelerometer and gyroscope data

Hello all,
Good Day.
I want to communicate to pixhawk from pi3 and wants to read the data like accelerometer and gyroscope for position and velocity control.
I did initial setup and mavproxy.py --master=/dev/serial0 --baudrate 57600 --aircraft ardusub
I have got the attached output whether my pi is communicating with pixhawk. I don’t know. please confirm and tell me how can i read the IMU sensor data. please respond as soon as possible.
pixhawkoutput

This might help you.

1 Like

Hi @shakeera, has this been resolved?

The post that @StrikeLines linked to may be helpful, but your post isn’t super clear on what you’re actually trying to do, so feel free to follow up/clarify your post if there’s still information you haven’t managed to find yet :slight_smile:

Dear EliotBR,
while I am following ur code I got the permission denied error.
How can I set additional udp out port. I am not understanding any thing.
Please help me in this regard.
I am attaching the code what I ran and The output.


I don’t know which code you’re referring to.

  • How is your system set up?
    • What devices are involved, and how are they connected?
    • Are you using a standard BlueROV2 setup, or doing something custom?

If you’re using a BlueROV2 setup you should be able to follow our software setup guide, after which you can refer to our Pymavlink examples. If you’re doing something else then you’ll need to explain more about your system and what you actually want to achieve in order for us to help you :slight_smile:

I would like to do this, i.e. request data from the Raspberry Pi 3B that it gets from the PixHawk.
Is the companion Computer set up to reply to a request with data, say compass heading or pitch?
I spent hours trying to figure out how the Companion computer software works then it dawned on me that it is probably the latest version that is for the Navigator, not the PixHawk Flight Controller.

Looking at this post:

it is not clear what is talking to what. Is this coming from the surface computer (useless to me) or being sent to the RPi on USB or I2C (Yes, this is what I want)?

I read the comments at the top of the code that indicate Cameron created a port on the Pi. One of the USB ports? Or is this a physical port at all?
How does he communicate with it? From another computer running Python?

Hi Peter,

These diagrams from my thesis will help in illustrating my post above.

Figure 1: Diagram of the hardware and software components on the BlueROV2 Heavy and the topside, their connections, communication formats and the types of data being exchanged

Figure 2: System diagram of the Underwater Remotely Operated Vehicle (UROV) hardware components, connections, and some of the communication formats

In my setup to obtain flight information from the Pixhawk with the surface computer through running Python with Serial, Ethernet and Powerline data format. In my Python code I created a UDP port (a kind of Transport Layer protocol and not a physical port) on the surface laptop to receive the requested flight information from the Pixhawk. In Python I utilized the Mavutil library to communicate with the Pixhawk. I send the flight information from the surface laptop to a Raspberry Pi 3 Model B with Python in packets through a separate tether in Ethernet and Powerline data format.

The flight information does get sent a Raspberry Pi, just not in the data channel you wish to setup; flight information sent directly from Pixhawk to RPi. You can still communicate between the RPi and the Pixhawk with Mavlink; Mavutil is still a relatively low-level MAVLink API.

Here are some hyperlinks to help out:

https://ardupilot.org/copter/docs/common-pixhawk-overview.html

https://www.researchgate.net/publication/329522616_Communicating_with_Raspberry_Pi_via_MAVLink

1 Like

Thank you Cameron for the excellent explanation. I suspected something like that.
What I want is doable but possibly not by me.
My ROV has two rotating side thrusters that are software coupled to a ruder and elevator behind a third thruster. Control is by PICs programmed in CCS C at either end of my 300ft tether.
It is controlled by a single joystick so a turn slows or reverses a side thruster and speeds up the one on the other side, as well as turning the rudder. Diving rotates the side thrusters up and the elevator down.
This is why I cannot use the BlueRobotics controls but I can use other features if I can get to them. I am using the BlueRobotics camera and Ping Sonar displayed on a Lenovo Tiny at the surface. I intend to add the scanning sonar.
I can try “Communicating with Raspberry Pi via MAVLink” per your link.
Will QGround Control work to set up the Flight Controller? I need to study this.

If I were to buy the new “Navigator Flight Controller” (I have a Pi 4) would it make it easier to get the compass and attitude data?
Has anyone considered making the data easy to access on the Navigator?
My system has a Gyro/Compass module that I access by I2C. It would be less for me to cope with if I could use the BlueRobotics data. But it has to be easy for me.

The Zero does not seem to be available,
Will a Pico W or H or Pico without WiFi work. I can start with an extra Pi 2 or 3 on a power supply.

Edit:
I don’t think a Pico will work, I just looked at the description.
It seems a bit clumsy to have a PIC ask a Zero on I2C to get data from a Pixhawk on a serial port.
Can I not ask the Pi Companion directly on I2C?
I will wait for your reply as to whether the Navigator would be easier than the PixHawk.
My ROV presently gets data from a MPU9250 9-DOF MEMS Sensor Module on I2C.
It seems easier to just have both running together with the PixHawk displaying on the QGround Control screen and my ROV getting heading and pitch, for auto steer and auto dive angle, from the 9250.
Peter

I’m not entirely clear on what you’re asking here. The onboard computer (Raspberry Pi) acts as a proxy between the flight controller (e.g. Pixhawk, running the autopilot firmware) and the control station (topside) computer. There are also some services running on the onboard computer that make use of the telemetry information from the autopilot, and/or send it commands / messages via the MAVLink protocol.

Our old Companion Software is Pixhawk only, and does not work with our Navigator board. The newer BlueOS currently has support for Navigator, Pixhawk, and a couple of other flight controller boards.

In the case of a Pixhawk, the Raspberry Pi communicates with it via a USB connection.

The Companion Software includes a program called mavproxy that manages the communication to and from the autopilot. BlueOS runs a different (but functionally similar) program, called mavlink-routerd. Those programs act as a proxy that allows other programs and services (on the onboard computer and/or the topside) to communicate with the autopilot.

Flight controller boards also generally have serial ports which can be set to allow MAVLink communication, which may be of interest if you’re trying to communicate with the autopilot without going via the Raspberry Pi (e.g. from a microcontroller or similar).

What kind of setup are you talking? QGroundControl can configure the autopilot’s parameters, which for ArduSub includes the vehicle frame, joystick button functions, failsafes, controller tuning parameters, etc.

ArduSub does not currently have support for control surfaces or thrust vectoring built into its motion controls, but if they’re controlled via servo-style PWM signals you may be able to set them up as manually controlled servo outputs.

If you’re running ArduPilot as your autopilot firmware then accessing the sensor data is possible in largely the same ways (via MAVLink) regardless of the flight controller board you happen to be running.

If you’re not running an autopilot firmware then a Pixhawk will be pretty much useless, but you could access the sensors of a Navigator from the Raspberry Pi it’s mounted to. That said, while we have plans to provide self-contained and nice to use libraries for accessing the Navigator sensors for arbitrary projects, those libraries have not yet been written, so it would likely be a fair amount of work to interface with the sensors (although that’s perhaps also the kind of programming and electronics integration you’re most familiar with, with the added bonus of some reference implementations in the ArduPilot codebase). Not using an ArduPilot firmware would mean that telemetry does not automatically get sent to the topside though.

Neither our old Companion Software nor BlueOS is set up to have telemetry values streamed over I2C by default. It should be possible to do by writing a program that talks MAVLink to the relevant proxy program, and provides whatever communication you’re interested in over I2C (the messages and protocol would be up to you).

Personally I would be inclined to do that with Python, with the MAVLink communications handled via Pymavlink, and the I2C handled via a library like smbus2. Python is not a requirement though - there are various other MAVLink libraries available if you’d prefer a different language (and same for I2C), you’ll just have fewer references available from our existing codebases.

Thanks Eliot; I would like to access compass and attitude data from either the PixHawk or the Pi3 Companion Computer to a PIC in my ROV.
In the link Cameron sent, click on ‘show original’ in the github window above in Cameron’s reply:

Most of my comments were concerning this method using a PiZero.
This link shows using a RPi Zero and various adjustments to get it working to access PixHawk data.
I was hoping for a simple way to get the data into my ROV PIC. If it is not simple then I will leave my MPU9250 9-DOF MEMS Sensor Module in because it is simple to access on I2C and is working.
I am not against buying the new Navigator Flight Controller if it would make it easier to get the data. You said " while we have plans to provide self-contained and nice to use libraries for accessing the Navigator sensors…" but will MAVLink still be necessary? This would eliminate many other systems.
Right now I have duplicated systems but not worth weeks of work to change.
I have no idea how to access the source code for the Pixhawk system and what I did find convinces me that I am not prepared to invest months on learning it. I printed 30 pages of the software and could guess what it was doing and what language it was written in, but modifying it is beyond my abilities or interest.
The BlueRobotics camera and Ping Sonar work fine and I am about to connect and test the battery monitoring and Bar 30. I already have my own versions working in my PIC system but I cannot display them on the surface computer monitor the way BlueRobotics does (they are on LCD screens on my Console in my system). I have good reasons to use the PixHawk for some features.
I am considering replacing my thrusters with T200s and would use the Blue Robotics servo drivers if I could, but their control is not compatible with my 3 thruster design.
You said
“Flight controller boards also generally have serial ports which can be set to allow MAVLink communication, which may be of interest if you’re trying to communicate with the autopilot without going via the Raspberry Pi (e.g. from a microcontroller or similar).”
This is what I’m interested in and I will see how difficult it is to use the MAVLink C libraries with a PIC. Otherwise I could use the PiZero which I can talk to on I2C. It would be a very complicated way to do a simple task.
I will ask the CCS forum if they have MAVLink libraries, or can use the MAVLink C libraries.
Even though I’m not running autopilot firmware the Pixhawk is not totally useless. It is needed to give compass, attitude, battery, Bar30 and other data on the Surface Monitor. The Companion Pi3 is needed for the Camera and Ping Sonars. QGround Control is required for all of these. I am not smart enough to do these things. They were not available, or I was not aware of them, 12 years ago when I built my ROV or things may have evolved differently.