I was thinking that the Pi-5 might have the chops to run the whole show itself?
WiFi interference won’t be a problem if:
The channels are exactly the same.
The channels are far enough apart so that there is no overlap at all.
Using the 2.5ghz band as an example, the only three channels that don’t interfere are 1, 6, and 11, and if you want to be absolutely sure you pick 1 and 11.
If the channels are the same, the protocol handles collisions. If they don’t overlap at all, it’s all good too.
The big problem is when a channel partially overlaps another, because WiFi channels aren’t cleanly separated groups of frequencies, and all the channels overlap except channels 01, 06, and 11. In that case, speed drops dramatically.
Of course - if someone is willing to build one from scratch or break their existing bot down and rebuild with a Pi5. In my case, and at this time, Dave needs too many personalities.
The great topics continue @cyclicalobsessive! I have been trying to understand the use cases for containers such as Docker and compare them with VMs. The operation and use cases for VMs are more understandable to me but I don’t grok containers yet. I have seen containers used for ROS but I don’t yet “get” what the advantages are. In your case, what do you believe the container will provide? I gather that the container has Ubuntu/ROS2 inside so it can run on the Raspberry Pi OS and that would certainly be an advantage but are there other advantages? On the flip side, how “contained” is the ROS2 inside the Docker container. Is there anything it cannot do or does it really have full access to the resources of the host OS to get at all of the robotics hardware?
I’m right there with you, exactly the same questions. I have read only the headlines and post titles. I use a virtual machine on my Mac to run an Ubuntu/ROS 2 Desktop for visualization (rViz, rqt_graph, view image topics).
I didn’t even read anything about what a Docker container is - I just followed the ROS installation guide and then had to search Google how to get out / quit the container. That is often the way I do things - do it first, then read enough to understand what I did. I learn by doing, and best by tutorials that I can skip the theory until I know it works. Just show me how, I’ll learn the why later.
This reminds me of what originally was called the “VCR” question.
Back in the day (not saying when or even if I personally was there, mind you), one could understand a lot about a person by asking then how they first learned to use a VCR.
If they said they just started pressing buttons to see what happened, you knew they learned “kinesthetically”. If they said they read the manual, you knew they learned “liguistically”. If they asked their kids, you knew they learned “intrapersonally”. And so forth, with combinations possible of course… (My catagorization is based on the “Gardner’s Theory of Multiple Intelligences” BTW but there are other ways to categorize).
I mention this, because [1] these “VCR” type questions keeps coming up, [2] I wanted to explain that I am definitely less kinesthetic and more liguiistic and [3] between the different approaches, maybe we can all figure out the pros and cons of containers!
This is the coolest thing I have read this year!
(Explains why I have reached the 1 year mark five times on the piano, and will never be able to play my flute with feeling. No “music smart”.)
Only advantage is allowing any version of ROS to be installed on nearly any version of PiOS.
Disadvantages I read are
configuration nightmare
two environments to keep updated
backup nightmare
complicates access to hardware
It is the ROS equivalent of Python virtual environments - complications I have figured how to avoid so far.
I found only one disadvantage of running Ubuntu 22.04 and ROS (non-containerized) on the Pi3B+/Pi4 - generating the picamera image topic, and smart folks solved that one since I coded my work-around.
Very cursory test does not show any detectable extra load from containerized ROS, and the Docker ROS nodes have full communication to and from ROS on the GoPiGo3 and on my ROS VM running visualization on my Mac
And a major, major PITA is that everytime you restart the container, there is no bash terminal history…
Thanks for the update - what aspects of the container are persistant vs non-persistant. In particular, have you moved your node code into the container or do you leave it outside. Is it better one way or the other?
NOTHING IS PERSISTENT as far as I can see. I started trying to figure out how to “mount” local (host) directories into the container so I can run existing nodes and save node changes, but have not succeeded yet.
My tests of running nodes in the container has only been
the demo_nodes_cpp listener in the container seeing topics from other hosts talker node ,
other hosts seeing topics from demo_nodes_cpp talker in the container
Agreed. There is a quick and (very) dirty short cuts approach or the serious fix the issues approach.
And it should be possible for us to add a ROS for handsonros dockerfile and a ROS2 dockerfile to GoPiGo OS - an approach I did not know enough about when I created the GoPiGo3/Ubuntu 22.04/ROS2 Humble sdCard image.
My impression of such containers is that the do “read-only” really well - practically a virtue - and that the things that change (are persistent) have to be outside the container. That impression may be “incomplete” though, hence my question. I guess we’ll find out; well you will first, anyway! We are right behind you mate (hiding behind that large rock… ).
Got the /home/pi/ directory mounted for read/write from the container, but Ouch - there are no editors in the container, so I have to edit in a host terminal, then build and run inside the container. build error - fix it outside and rebuild inside.
A google excursion may be warranted here to find out how folks do development work in these containers. Do they bake an IDE into the container or is there another trick we don’t know about?
I have to install the GoPiGo3 software in the Docker env everytime I start Docker, since I don’t know what I’m doing… but the GoPiGo3 Python Example Servo.py and my systest spin360.py worked…
But its just too much for me - I tried building just my ros2_gogpigo3_node - missing tf-transformations - how do I get that - use pip - xcept there is no pip installed. Got pip installed but still no tf-transformations. Now I remember what this is all about. My ros2 gopigo3 node needed to emit the new heading as a quarternion and used a ROS1 package tf-transformations that is not available on ROS2, but I don’t remember how I got it built for ROS 2.
I didn’t understand Euler and quarternions then and I sure don’t now. My node built with no errors on my humble/Ubuntu image, but has to be rewritten for Humble Docker. I’m really not liking Docker.
What little I’ve read/heard about “containers” has kept me far away as it appears to add a layer of complexity that (IMHO) offers little value-add.
If there was a way to use a container in the way I’ve used virtual machines on Windows, it might be worthwhile.
In my case, I find it easier to install multiple OS’s in a multi-boot arrangement1, and use them as my “containers”.
====================
Footnotes:
You can use PINN or my dip-switch arrangement. PINN has the advantage of easier backups of the images. My dip-switch arrangement allows easier selection at boot-time without needing a monitor to know what you’re doing.
Indeed, this PiOS Bookworm GoPiGo3 investigation was not planned to include any ROS. Way back, way back in 2019, my first ROS on Raspberry Pi investigation started by installing ROS (1) Kinetic **from sources" over the then latest Raspberry Pi OS “Raspbian (32-bit) Lite Stretch”.
Today there are four ways to install ROS
from source over your choice of OS - you figure it out - you support it
from a) “certified packages over a certified OS with long term support” or b) “community built packages installed over a recommended OS with minimal support”
build your own (minimal) ROS Dockerfile following the ROS tutorial - good luck and please RTFM (The entire Internet wisdom before you ask a question)
sign up for formal ROS education and support to use the company’s Dockerfile
After I proved the new PiOS Bookworm could be used on the GoPiGo3, knowing there will not soon be any method 2) community packaged ROS for PiOS Bookworm (and PiOS will never be a "certified ROS platform), I decided to try method 1) install ROS (2) from sources over PiOS Bookworm like I did four years ago for Raspbian on RPi. That did not get far before blowing up.
Having heard but never played with Docker, (with all the crying about Docker this and that in the back of my mind), I decided to venture into method 3 - and indeed I got “ROS running in Docker”, and even got the GoPiGo3 API running in Docker on Bookworm PiOS.
The next step was to bring my ROS 2 GoPiGo3 code (which runs really great in ROS 2 over the recommended Ubuntu 22.04) to the Bookworm Docker world. Ouch - I only need to be a total ROS guru and certified Docker builder/configurator - I am neither.
At this point, I understand the limits of the Pi5 as a GoPiGo3 processor:
no software I2C with Pi OS bookworm ATM
(my “doesn’t need clock stretching” MPU9250 IMU arrives tomorrow)
bleeding edge for PiOS Bookworm remote desktop (but who needs desktop really?)
).