I have upgraded my Pixhawk to a 6X running PX4 while using the original raspberry pi companion. I was looking how to make sure the mavlink bi directional forwarding still works. It appears as:
/dev/serial/by-id/usb-Auterion_PX4_FMU_v6X.x_0-if00
I see a list of supported devices under tools/query-udevadm.py. Is this the appropriate place to add the new autopilot?
Hi @rdehart,
Interesting, I wasn’t even aware that PX4 has (some) underwater vehicle support. Out of interest, why have you chosen PX4 over ArduSub? 
It’s been a while since I looked around in our old Companion Software codebase - do you have a particular reason not to use BlueOS? Granted it also doesn’t currently have Pixhawk 6X detection, but that’s something we could add if you can provide us with the relevant information, or you could submit a pull request with the relevant changes
I believe query-udevadm.py is only used for showing the Detected Devices on the web interface. You can add the information there if you want, but it won’t enable the MAVLink connection.
By default the MAVLink connection is configured to /dev/autopilot. If you’re ok with it being manual, you should be able to just put your own device path there if you want - the MAVProxy settings are accessible via the web interface.
If you’d prefer to have it automatically detected then you can add a line to the udev rules, and then copy the file over (like is done in setup.sh).
Thanks, the mavlink connection change did the trick. Were there any other items I needed to change?
Interesting, I wasn’t even aware that PX4 has (some) underwater vehicle support. Out of interest, why have you chosen PX4 over ArduSub?
Direct control of each thruster, ROS compatibility and use of the PXFlow camera
if you can provide us with the relevant information
To complicate matters, it only starts communicating when I have it both connected through a regular USB AND a USB to JST-GH coming out of Telem1 on the 6X. It wont work without both. See attached screenshot…
Otherwise, QGC seems to not see it
My main concern here is that I dont want to create some sort of weird network loop due to having in plugged in twice
Great to hear
It should work fine as is, but as mentioned if you want the name to show up nicely in the “Detected Devices” on the web interface then you could also add it to the query_udevadm.py file
Are you controlling the individual thrusters via MAVLink messages then? I’m curious how that’s handled.
In case it’s relevant, it’s technically possible to control individual thrusters in ArduSub as well, just generally not recommended because doing so is somewhat hacky at the moment, and because control generally works best with high frequency sensor data and minimal latency, which is only really possible within the autopilot firmware. That said, not every situation requires precise/minimal-latency control, and if you’re testing custom control algorithms then that can be a bit simpler to do in a higher level language program that then talks to the vehicle.
I’m told ArduSub has ROS support, via the mavlink package.
That seems to be supported in ArduPilot firmwares, although I don’t believe we’ve tried it with ArduSub.
Regardless, thanks for the info
Huh, interesting… Any chance one of your USB cables is power only?
Thanks for the info! I’ve raised an issue for it
Huh, interesting… Any chance one of your USB cables is power only?
Definitely not, I was plugging it in via the same USB-C cable to my computer earlier to upload firmware. I might ask the PX4 side of the house if they have ever seen something similar.
@rdehart, @EliotBR reached out to me, and I’ve added Pixhawk 6X support in BlueOS. It should be merged in the next hours.
Since I don’t have this board on hands, could you test BlueOS with it to see if it works? Thanks in advance!
edit: Roddy, you can test the integration before merging going to Version Chooser, setting rafaellehmkuhl/blueos-core on the remote-repository field and downloading the add-support-pixhawk-6x image.
I fear I am not running BlueOS.
Follow up question:
If I were to create a custom Mavlink message, would I need to recompile and reupload a new version of mavproxy on to the raspberry pi?
From the ArduPilot “Adding a MAVLink message” docs it seems like you can add a new MAVLink message to mavproxy by re-installing pymavlink using the setup script (once you’ve added the new message to the relevant xml file), which presumably you should be able to do via terminal access to the Raspberry Pi.
So telemetry is forwarded by the Pi fine, but Ive still been having issues with the actuators using the actuator test. I bypassed the Pi and it worked. There must be some issue in either the current version of mavproxy on the Pi or something else. Additionally, QGC had very different actuator configurations when using the companion and when it is bypassed. I would still like to use the Pi for video, additional sensors, but can you verify whether an old version of mavproxy would affect QGC in this way?
OK, so I updated the companion to the latest (0.0.31, I was at 0.0.15) and now QGC doesnt see anything. I used wireshark to look for traffic on udp:14550 and dont see anything either. Any suggestions?
Current mavproxy settings
That’s a positive start
I’m not particularly sure what’s likely to be going wrong there.
I don’t really know, but given the MAVProxy version in Companion was seemingly last updated 5 years ago, and the Pixhawk 6X was released this year, it wouldn’t be overly surprising to me if there’s some kind of incompatibility there, especially given you’re using PX4 firmware (which I don’t believe we would have had reason to test with).
Our old Companion software is no longer being developed, and we don’t actively support it other than for customers who need to use the limited set of features that are not yet available in BlueOS (which I believe is about to be negligible), so there’s only so much digging around for information I can do here before it ends up in the “too hard” basket.
That’s further complicated by Companion only being designed and tested to work with the Pixhawk 1, and a single H264-encoded video stream, etc, so information about how to do custom modifications and integrations may not even be known by our software team.
I don’t see anything obviously wrong with your mavproxy settings (although maybe there shouldn’t be an extra newline at the end, if that’s what your cursor is indicating?), so if it was making a connection before then it’s somewhat surprising that it isn’t after the update.
Did you update via the web interface, or just flash the new version onto the SD card? It may be worth flashing a fresh version if you haven’t already, just to rule out any potential issues with the updating process.
It may also be worth checking that the autopilot is still showing up the same way - maybe it’s showing up differently after the update, or maybe there’s a different service that’s trying to connect to it before mavproxy is able to.
You can join running services with screen -r session_name (e.g. screen -r mavproxy) to see the logs, in case there are any errors showing up (then press ctrl-a then ctrl-d to detach from the session without quitting it, or ctrl+c to quit it - quit sessions will restart when the vehicle does). It may be relevant to try commenting out the ping services in .companion.rc, especially if you’re not using any Ping sonar devices.
Thanks for the suggestions. I understand about the level of support you can provide. I re-imaged the flash drive itself rather than going via the website. Do you have an archive of previous companion images? perhaps an in-between one will partially work and give me more information.
Yep - the download URL structure is described here
It may be worth referring to the release notes for what was supposed to be included/changed in each version.
So I got telemetry for the newest version working again (stupid mistake) and I attempted to upgrade mavproxy. It had trouble updating numpy because the lastest mavproxy wants 1.24 but the highest supported for python 2.7 is 1.16.
I noticed that it says here that the companion image can support a newer Raspberry Pi (v3B). Is that true?
https://www.ardusub.com/resources/downloads.html#companion-computer-images
Good to hear
If I’m remembering correctly, the latest Companion Software images should have Python 2.7 and 3.4 available by default. If you’re wanting to install a more recent Python version there are some instructions here. That said, adapting existing services/programs to successfully use a different Python version may not be trivial, especially if they were written without Python 3 compatibility in mind.
The Companion Software supports Raspberry Pi 3B hardware, yes - I wasn’t even aware there had been earlier hardware versions supported previously.
If it’s relevant, BlueOS is supported on Raspberry Pi 3B, 3B+, and 4B, and the base operating system for the images we build is Raspberry Pi OS Bullseye, which comes with Python 3.9 by default. The BlueOS-core docker image (which most of the services run in) also currently uses Python 3.9, although that may be upgraded soon.
