I’m trying to control the BlueROV2 thrusters autonomously with PWM values it receives via serial from a Raspberry Pi 3. I’ve referenced Pymavlink · GitBook and Pymavlink- heartbeat. What happens is that the thrusters don’t respond at the same rate as the data coming in from the Raspberry Pi.
The Raspberry Pi communicates through MAVLink (master = mavutil.mavlink_connection(“/dev/ttyS0”, baud=57600))
I know that all system components that communicate via MAVLink are expected to send a HEARTBEAT message at a constant rate of at least 1 Hz. Is there a method to ensure that Raspberry Pi sends a message at a rate of at least 1 Hz? Or other ideas?
Another issue I’m having is that waiting a heartbeat (master.wait_heartbeat()) takes 5 minutes or more to respond. I give up waiting for a response if it takes over 5 minutes. It shouldn’t take over 5 minutes for a response to occur. I’ve tried restarting the Pixhawk and Raspberry Pi and that doesn’t solve the problem. Any ideas how to fix this response issue?
Are you using our companion computer image, or just a plain Raspbian image with pymavlink installed? If you’re using our companion computer I’d suggest you try our run pyMavlink on companion computer example, unless you’re turning off mavproxy so you can fully replace it, in which case I’d suggest at least using 115200 baud for your serial connection, as recommended in our connecting via serial example, and you can use '/dev/autopilot' as the port, which gets auto-registered on startup.
If you’re using a companion computer and haven’t disabled or turned off mavproxy but are still trying to connect via serial then I would expect that shouldn’t work, since mavproxy will be using the relevant serial port. To disable it in a live session you can run screen -S mavproxy -X quit, and to stop it from auto-running on startup you can comment out or remove this line from ~/companion/.companion.rc. More generally, it’s likely also worth commenting out/removing several of the other services if you’re not using them (e.g. video streaming, audio streaming, the webui, etc).
I’m not sure if it’s best in this case to extend mavproxy to do what you want to achieve, or if it’s sufficient to set up a thread which sends a heartbeat (master.mav.heartbeat_send(...)) every 0.9 seconds or something (you may need a threading.Lock that you set up around any master operations for that to be thread-safe, which may slow things down a bit).
This depends very much on your setup. If you’re not sending any heartbeats then it may not be sending any back. I’d suggest you see how the above ideas fit into your process, and once you’ve tried those we can revisit this if it’s still an issue
Thank you for responding! I’m using a Raspbian image with pymavlink installed. I’ll try out the ideas you suggested and let you know if there’s any issues.
I referenced the BlueRobotics example “Run pyMavlink on the surface computer” and solved my issues with the timing of BlueROV2 thruster responses and “heartbeat()”. First, I added a new UDP output port in http:192.168.2.2:2770/mavproxy. I then utilized that port to route the PWM values from my Raspberry Pi (one with a Raspbian image file and Pymavlink installed) through my Topside (Surface) computer to the BlueROV2 Companion computer. I figured the issue was that I was trying to control the BlueROV2 not with the BlueRobotics Companion computer image file.
I also understand better what your setup is now - when you originally said you were “using a Raspbian image with pymavlink installed” I assumed you were making an autonomous vehicle with possibly no direct connection back up to the surface.
Well! I had a connection to the Raspberry Pi from the surface. I was trying to route PWM values from my Raspberry Pi mounted within an acrylic enclosure on the payload skid via serial directly to a BlueROV2 Pixhawk serial port. It’s clear now that I shouldn’t try to control BlueROV2 thrusters with a Raspberry Pi that doesn’t have the BlueRobotics Companion computer image file installed.
Yes! The purpose of the Raspberry Pi in my payload skid is to collect sensory and computed data from two Arduino microcontrollers mounted on the payload skid. Some of that data is computed PWM values for the BlueROV2 to use. Trying to modify the companion computer with additional functionality was out of the question because it wasn’t in the design process for the payload systems I built. Following that, I’m still a beginner in Pymavlink, MAVLink and ArduSub. At first I managed to get thruster responses using a Raspbian image with pymavlink installed and connecting it to a Pixhawk serial port, but further testing revealed it was a faulty setup. It’s clear that there was more to learn, but I needed a faster solution.
