It would be valuable to think about several of the most common things that nuke the performance on these relatively small processors resources.
When you run ‘top’ you will get a display like this:
top - 02:11:10 up 2:45, 1 user, load average: 0.63, 0.70, 0.63
Tasks: 151 total, 1 running, 102 sleeping, 0 stopped, 0 zombie
%Cpu(s): 5.6 us, 4.9 sy, 0.0 ni, 88.9 id, 0.0 wa, 0.0 hi, 0.6 si, 0.0 st
KiB Mem : 895508 total, 278716 free, 334504 used, 282288 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 478852 avail Mem
It (sadly) does not take a whole lot to overwelm the Pi3. More recently we now ship the Pi4 but to run that properly you must have an MCB board of revision 5.2 or greater (due to some changes in power supply partly to support the Pi4).
The Pi4 did not exist as we made MCB 5.0 and we are not clairvoyant (sadly).
Nowdays we run Pi4 with 4GB and there is plenty of memory in that case.
But before jumping all the way to the conclusion that ram is the issue I think the thing to do is look at the performance and then find ways to lower the loading by easing up on the speed of gmapping. The larger the map (sadly) the more the load is on gmapping. As I stated, your map is ‘rather large and complex’ for a Pi3.
I have not had to optimize gmapping so far but think there are ways and perhaps people explaining how to do things to help. things like slowing down rate of lidar data and also of slowing down map publication speed from gmapping both help.
You have identified it is capping out on cpu loading. Also look to see if the ‘top’ display shows that your are just about out of memory. When the poor Pi runs out of memory (as in any linux system) it starts to spend a HUGE amount of its time swapping in and out memory using what is called virtual memory. If it hits that then the processor will drop to it’s knees and ‘cry’. So we must avoid that.
So in general we try to be sure that the Pi has swap memory available in the first place by creation of a swap file but frankly what you really want if you get in a mode of using virtual memory is more memory. We have recently started to support Pi4 but only on current MCB boards (rev 5.2 and 5.3). On older images we may not have had swap setup. So run ‘top’
3rd line down shows load but 4th line shows if you have available memory.
If the ‘free’ memory number is really low you are likely swaping
Example: KiB Mem : 895508 total, 277904 free, 334012 used,
Above line is good because a high percentage is still free.
The 5th line down starts with ‘KiB Swap:’ and a lot of the time this may be 0.
That means not attempt to setup a swap file has happened.
Setting up swap allows processors to not get bottlenecked and flat out stop cold
but it will not solve your problem. Once swap gets used all the time things will bog down major slow so we want more to avoid use of swap than optimize swap.
But you may want to look at setup of a swap file by searching web for ‘setup raspberry pi swap on ubuntu’ or something, you may find it interesting.