Hiya, not sure if this is the right place to ask this question but I thought I’d give it a go.
I am building an auv with just the raspberry pi and navigator flight controller as the computer within the robot. I want to use ROS2 and wanted to avoid docker if I can, so I was thinking if it’s possible to use normal Ubuntu on the pi instead of the blueos wrapper and still be able to run ardusub along with ROS2 with mavos as normal.
I will lose the nice blueos functionality but it would be a setup I’m more comfortable with. My main concerns though are
Will the pi have enough compute for this? I plan on using pretty basic code for Ros, no ml but I will have some image processing so not sure if the pi will be able to handle it while also running ardusub.
Fcu_url and gcs_url in mavros. Will these both point to localhost now?
Qgroundcontrol. While the robot is not submerged can I still connect to qgroundcontrol over WiFi for general maintenance stuff since I won’t have blueos?
Hi @kushion
While you could take the approach you describe, it’s going to vastly complicate the process to reach your goals! It’s kind of like being presented a free car and preferring to build your own, from scratch, because you don’t like the color of the interior, or it’s an automatic transmission and you prefer manual? Haha
BlueOS has a ROS2 extension- what has you wary of docker? What type of pi are you planning to use?
There are instructions for manual setup that may be helpful.
ArduSub takes pretty minimal resources…
While you’d lose connection the moment the vehicle submerged, it is possible to connect QGC , or Cockpit, via the Wi-Fi hotspot. Doing this without BlueOS is possible but you’d be building it yourself rather than relying on this functionality that is already provided…
What are the goals for your AUV? While great four prototyping, most AUVs run low power microcontrollers rather than SBCs, as they consume dramatically less power - a pi is only particularly helpful when it comes to video streaming/recording tho!
I see, I thought it would be rather straightforward to set up ardusub and mavros on the same pi, I have done it before with a jetson and pi, but not sure how much blueos was contributing to that so glad I asked.
I’m using a pi 4b, with the navigator fc. The extension still seems fairly new and I don’t have much experience with the setup, and considering I am currently on a time constraint, I was hoping for a hacky workaround. If the extension is the quickest way to go about it then happy to give it a go.
For the ros2 extension, it says a 64-bit version of blueos is required. I’m assuming I will have to reflash the provided (with the navigator fc) sd card with a 64-bit version? what would be the most appropriate to use here?
what would be the difference here with setting up blueos on a different operating system (like ubuntu 22.04) where I can directly use ros2, as opposed to flashing the sd card directly with blueos?
I see, it seems I‘ve underestimated how much blueos has actually streamlined the workflow haha.
I just want computer vision and navigation capabilities (w ros2) really, and I have the pi 4b with navigator fc so it made sense to set it up on there with rcoverride in mavros.
I wrote most of this yesterday, but got distracted before posting it. Perhaps less relevant now, but could also provide some more concreteness to what Tony has explained so far.
That’s highly dependent on your performance requirements, and the hardware you’re running on/with. I wouldn’t say it’s impossible, but you may need to stick to low resolution images at low framerates, and avoid expensive decoding operations (e.g. use a raw encoding if possible, not one like H264 that’s heavily compressed for transport).
I’m unfamiliar with ROS, so have no idea - hopefully someone else can chime in on this.
You can try the provided ARMv8 image from the installation page, just be aware it has had limited testing, and is currently expected to be less stable for Raspberry Pi 4B than the 32-bit image.
Flashing is typically easier for most setups, and it’s possible a different operating system doesn’t provide the same access to the hardware. You can of course try it, just understand that we can only fully support setups that we’re familiar with, so pushing the boundaries means you’ll get more theoretical responses and "I don’t know"s - but such is always the nature of doing new things.
