Suggest using Ubuntu MATE with the Raspberry Pi SBCs

[TCIII]

@chrisl8,

I have used both the Ubuntu MATE (focal 20.04) desktop and the Ubuntu focal server/gnome desktop and have found that the combination of the Ubuntu focal server/gnome desktop is a clunky compromise compared to the Ubuntu MATE desktop. The Ubuntu server/gnome desktop startup is long compared to the Ubuntu MATE desktop startup and there is no logon requirement with the Ubuntu MATE desktop like there is with the Ubuntu server/gnome desktop.

For some reason the Ubuntu server/gnome desktop will hiccup and display graphic artifacts until I move the mouse pointer around and then the display recovers. In contrast the Ubuntu MATE desktop is stable and artifact free.

The only drawback with using the Ubuntu MATE desktop OS with the Rpi SBCs is the lack of a built-in VNC app like vino in the gnome desktop. There are guides to install a VNC like TigerVNC on the MATE desktop, but the process involves a lot of flag waving and can be tricky for even intermediate programmers/users.

Comments?

[TCIII]

@chrisl8,

I am willing to work with you to integrate a suitable VNC app into the Ubuntu MATE desktop OS and create a Raspberry Pi 'setup-Noetic.sh' for users like me.

[chrisl8]

My main comment is that most of my robots don't have a screen, so I use Ubuntu server to save on SD space, memory, and CPU cycles.

Do you have a screen on your robot?

I do on one of mine, but it isn't something I intend to add to most of them.

Thoughts?

[TCIII]

@chrisl8,

SD cards are getting cheaper and cheaper. You can buy an Extreme Sandisk 128GB micro SD for less than $22.

Also, SBCs are getting faster and faster. As you have seen the Rpi 4B/4GB can run rviz without issues.

You appear to have a 7 inch screen on the Arlobot in your your Arlobot video besides the video display on your control laptop.

Without a desktop, I assume that you use rviz on a separate SBC/PC running Ubuntu/Noetic to view the RPLidar scan and robot movement and control the robot remotely with the Web Controller and not use VNC?

Tom C

[TCIII]

@chrisl8,

So your process for installing Arlobot software on the Rpi 4B/4GB would be as follows:

1. Burn a micro SD card with Ubuntu focal 20.04 server.
2. Install Ubuntu focal 20.04 server on an Rpi using only an ethernet connection and CLI on a video display.
3. Install Arlobot/ROS Noetic software using the CLI.
4. Add WiFi to the server by appropriately editing "/etc/netplan/50-cloud-init.yaml" and then disconnect the ethernet.
5. Control the Arlobot headlessly using rviz and the Arlobot Web Controller on a PC/SBC running Ubuntu/Noetic.

Therefore you don't need VNC to control the robot and view the Lidar scan?

Comments?

[TCIII]

@chrisl8,

I think that I can make the Ubuntu MATE OS work for me using this scenario:

1. Install Ubuntu MATE (focal 20.02) on Rpi 4B/4GB.
2. Install Arlobot/ROS Noetic software package.
3. Setup Rpi to bootup with or without a monitor attached.
4. Use NVIDIA Nano 4GB setup as a workstation via X11docker (works great on JP 4.6/Ubuntu 18.04).
5. Use the Nano with a 15 inch monitor to display both the Arlobot Web Controller and rviz via "docker-view-navigation.sh"

This scenario should negate the need for a VNC connection to Ubuntu MATE desktop on the Arlobot Rpi on the Arlobot.

Comments?

[chrisl8]

@TCIII

Yes, I have tiny screen on my robot. it runs at a pretty low resolution, so it isn't a great place to do much. I added it some years ago because I was getting in situations when going to remote locations where I needed local screen access to fix things and the robot wasn't already on the WiFi there.

I certainly may be overestimating how much of a drag a desktop puts on a Pi 4. I haven't actually tried making a map yet with a Pi 4 that was also running Rviz. I need to try that to see how the load is.

My typical workflow is:

1. Image the SD card with Ubuntu Server 20.04 using the Pi installer app.
2. Edit the boot config file on the SD card card to set up WiFi so that when the Pi boots it loads wifi. (I can point you to the instructions for this if you don't have them.)
3. Put the SD card in the Pi, let it power on, do first boot, etc.
4. There is a bug where the boot config set WiFi doesn't work on first boot, so once it seems done, I pull the plug and plug it back.
5. At this point the Pi is now on WiFi, with SSH working. Notice I never had a screen, keyboard, or mouse connected to it.
6. At this point I SSH to it, run the setup-noetic.sh file, and do everything via SSH, then use SSH or the web interface to start/stop ROS and the mapping.
7. I use Rviz from another Unix box or now, Windows to control the map making.

In short, my typical workflow is to never use a screen, keyboard, or mouse on the Pi.

That said, IF MATE is great, and having a Desktop doesn't cause any problem for mapping as far as CPU usage, I'm willing to try it out.

To recap, the concerns I have with MATE are:

1. System resource usage. Primarily CPU, secondarily Memory and finally space.
2. Support. With Ubuntu Server and ROS I'm relying on two organizations to keep their stuff working. Adding MATE means I'm relying on a 3rd one, MATE. That said, if MATE is generally a good reliable Ubuntu mix, it might not be a problem.

Personally, if I do switch to MATE, I'm actually confident that I could sort out some way to remote control it. I'm shocked that it isn't built in, and there must be some way. But, again, if RViz works well, we really don't need it.

The biggest benefit I see to have a desktop running on the robot is making it easy to get WiFi connected when at remote locations. Doing it via the command line is a pain and not reliable. This of course requires a screen, but even if I had to just carry a portable screen and plug it in "as needed", having a Desktop on the robot would make that easier.

It also obviously makes it easier for other users, like yourself, who aren't as comfortable working on "headless" Linux systems as I am. I've been working on headless Unix/Linux systems since the mid 90's, so I'm pretty used to it, but that doesn't mean that it is something that I should expect everyone to do.

Again, I have a lot of experience with ROS running low on CPU cycles or memory, but it is 2022, and maybe the modern SBC equipment is more that capable. Remember that this time last year I was still using a full blow laptop to do this, because in 2016, nothing but a laptop could run ROS reliably without being highly tuned and honestly, giving poor results. I may just be living in the past still.

This is all good stuff to think out loud about.

Currently I'm down one Pi because of the one that is crashing. I'm mailing it back to CanaKit now. It doesn't help that we have a chip shortage, so I can't just run out and buy a temporary replacement. So I won't be easily able to experiment for a bit. Fortunately, my robot IS running better than ever now, so we can keep focusing on the core features.

P.S. I am also messing with Roboclaw controllers. I have another thing that is using a Roboclaw now. I don't have ROS on it yet, but I am using similar "twist" message type controls and using the exact same data format that the ROS Nodes for Roboclaw use, so I'm confident that adding ROS won't be an enormous effort. Just one thing at a time, and it takes a bit of time.

[TCIII]

@chrisl8

I fully understand your position.

I have gone back to using the Ubuntu MATE desktop in place of the Ubuntu focal server/gnome desktop configuration.

At first I struggled to add a reliable VNC server to the Ubuntu MATE desktop OS until I stumbled upon this very easy guide for installing vino on the Ubuntu MATE desktop OS and it actually worked first time out.

Tom C

[chrisl8]

Cool, I felt pretty confident that there must be some way to get vino or rdp or vnc or remote x11 working on MATE, because one of those has always worked in the past on Ubuntu. I'm pretty sure vino is what vanilla Ubuntu is using under the hood for desktop sharing.

Once I get a test Pi working again I'll experiment with using MATE to see if I run into any issues with it.

[TCIII]

@chrisl8,

Before I installed the Arlobot/Noetic software package, I used the MATE System Monitor to see what the processors loading looked like. The MATE desktop and associated apps were only using two processors and then at a very low level. RAM memory usage was under .25 GB.

It will be interesting to see what the processors usage is when running your Arlobot/Noetic software.

Tom C

[chrisl8]

I got my "other" project going on Ubuntu MATE, and so far it is nice. I feel like it may even be faster?

It is nice to be able to set up Wifi and Bluetooth from the GUI.

I'm torn now between starting to convert more of this project over to a different platform or starting a new one. I'm also torn on whether to try to start transitioning to ROS 2, or keep working with ROS 1.

[TCIII]

@chrisl8,

What do you mean by "a different platform"?

Hardware or Software wise?

Regards, TCIII

[chrisl8]

@TCIII Good point. I mean Raspberry Pi 4 and Ubuntu Mate.

This repository was built for Ubuntu on an x86 system.

It seems that we did basically make it work on Pi already and jumping to MATE wasn't a big ask.

I just wonder at what point should I kind of start to build up from scratch and copy over "the good parts" rather than continuing to iterate on this. It might be a good moment to transition. If nothing else, I don't want to keep using the "ArloBot" name if the goal is to work on a generic platform.

[TCIII]

@chrisl8,

If you want to continue with the PAB, then you are going to have a problem using a non-x86 SBC.

The solution would be to have a user setup either a dual boot laptop or use a x86 SBC like the Lattepanda that is similar in size to the Rpi. I think that it is smart to retain the PAB to control the RoboClaw motor controller as it helps to reduce the SBC processor loading.

Regards, TCIII

[chrisl8]

@TCIII

I was not planning on using the Propeller Activity Board in the future. Both the x86 and the Raspberry Pi have no problem communicating directly with the Roboclaw controllers. I have two other projects already doing this. They just don't use ROS (they are essentially remote control devices, not robots per se.), but they are entirely Raspberry Pi based and work well with the Roboclaw.

I think that the Pi 4 has the CPU power to deal with the Roboclaw's output and also do the rest of the chores, but testing will find out. The Propeller Activity Board is already streaming an enormous amount of data to the Pi, and it appears to handle it.

I'm not sure how or even if to continue to allow use of the PING sensors on a new platform without the PAB, but they could also just be on their own board, unrelated to the motor controlling, or use the GPIO pins on a Pi.

That is my current view of things anyway. New information or experimental results can always change my mind.

[TCIII]

@chrisl8,

Due to the high processor demands of ROS and rviz, I suggest that you offload as much low-level motor control/sensor processing as possible by using either a PAB or an equivalent to the PAB.

TCIII

[vatbrain]

@TCIII Have you been using 32 or 64 bit mate on your raspberry pi? Thanks!

[TCIII]

@vatbrain,

I am running the 64 bit version on my 4B/4GB, but I would recommend a 8GB version. Also, Ubuntu MATE 20.04 has reached EOL support.

TCIII

[chrisl8]

These have all been great ideas and I wish everyone the best in their endeavors to customize their own code or my code to whatever platform you enjoy. I think this conversation was valuable to all of us at the time, but it doesn't need to stay open. Again, thank you all for your contributions.