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…
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.
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?
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.
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?
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.