OpenSim + Raspian hard-float = What was once broken now works!
A while ago we decided to go on a journey with OpenSim. For those who are new to metaverse software; OpenSim (Or OpenSimulator) is a program that emulates the back-end resources of a commercial metaverse known as “Second Life”. The client or front-end that connects to OpenSim are third-party clients such as firestorm and singularity. We liked working offline from SecondLife and keeping a backup of my stuff. What better way to do this than to keep it on something low-powered like a Raspberry Pi? Read on to learn more.
“Note: If you get a black screen but the audio is playing. Or you got a potato PC and it’s studdering. We have fallback Links below.”
Video tutorial fallback mirrors:
In case you have no-script enabled or for some reason cannot see the title video on this website. We have provided direct links for these videos. For more information about the standards we use on this site click here if you would like to know more.
AV1 - Link WebM VP9 - Link OGV - Link MP4/.h264 - Link
In my last blog about the Raspberry Pi we initially thought we fired out the pi due to overclocking but later on found it was just power issues (USB cables too thin to carry the current). Instead of doing high-end gaming, we’re going to use it for headless applications like the web and OpenSim. Because I do not know the learning curve of the average Pi or OpenSim User; It should be noted that this guide is going to be a bit long. This tutorial covers installing OpenSim as well as compiling all of the sources needed to get OpenSim functioning properly. We broke down compiling this way so that these instructions can work on any ARM processor and not just the Raspberry Pi.
As always, please refer to our FAQ for general questions. We are not responsible for any damages caused by this tutorial either physically, mentally, or financially. This will require a considerable level of time in a Linux shell. If you are not comfortable with that then you may stop right now. I should also note to please PLEASE PLEASE DO NOT bother the OpenSim dev team by submitting a mantis bug report about OpenSim and the Raspberry Pi. The dev team is primarily focused on the X86 platform. They simply lack the manpower to chase bugs on other platforms. Everything in this tutorial is bleeding edge beta and subject to change.
When you look at the server specs for OpenSim and what they suggest would be a good server for OpenSim. You would be quick to notice that your average spec for a island sim is about 2Ghz of CPU power and 1GB of ram! We later found out that the programming language “MONO” which OpenSim is based around really likes multi-core processors! Suddenly a raspberry Pi 2 becomes a very workable unit. To those who are still rocking the single-core Raspberry Pi A or B+, you’ll find that running OpenSim works. But will be very slow as physics/scripting/assets are all being bounced off of just that one armv6 700Mhz processor.
My Raspberry Pi operating in semi-headless mode.
When I first tried OpenSim a long time ago. I ran into roadblock after roadblock. Eventually finding out that you cannot install MONO onto a Raspberry Pi that is running hard-float from the Debian libraries. You either had to run Wheezy or Pidora in soft-float mode. In soft-float, everything feels like your running on a 300Mhz Pentium II desktop! It’s painfully slow.
But First! Let’s do the basics and update your Pi!
sudo apt-get update
sudo apt-get upgrade sudo ldconfig sudo apt-get install libgdiplus
Use MySQL instead of OpenSim SQL-Lite!
After a bit of usage on my Pi, We noticed a lot of files not found errors flying on my console just by simply camera panning in and out on my phoenix/firestorm viewer. It seemed like the hyper-experimental Mono compile is simply having issues looking up null table references. It didn’t affect moving around the sim. Once again this was an annoyance. So understanding that the build of Mono I have is experimental. The goal is to take as much as you can out of the hands of the Mono development language so that OpenSim runs smoothly and is stable.
sudo apt-get install mysql-server
It’s going to queue you for the root password for MySQL. This is really important to write this down! We will need it later in the chapter! We’re going to create the initial OpenSim database for it to use and generate a userid “opensimuser” within MySQL with the password “opensimpassword”. I pray you use something slightly more original than this user / pass.
$ mysql -u root -p Enter password: mysql> create database opensim; Query OK, 1 row affected (0.00 sec) mysql> use opensim; Database changed mysql> create user 'opensimuser'@'localhost' identified by 'opensimpassword'; Query OK, 0 rows affected (0.01 sec) mysql> grant all on opensim.* to 'opensimuser'@'localhost'; Query OK, 0 rows affected (0.01 sec) mysql> quit
Mono Language installation onto your Pi.
Pass the following commands to merge the mono-project repositories into your Pi:
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF echo "deb http://download.mono-project.com/repo/debian wheezy main" | sudo tee /etc/apt/sources.list.d/mono-xamarin.list sudo apt-get update sudo apt-get upgrade
If you are getting the following errors stating that Mono 4.0 packages are being “held back” if you are using an older Linux kernel like Debian wheezy. Then WITH EXTREME CAUTION pass the following command. If no errors happen after passing the apt-get upgrade you don’t need to do a full dist-upgrade then.
sudo apt-get dist-upgrade
Pinning/Downloading to a more stable version of Mono for OpenSim
Update 8/19/2016 Since mono development is rather fluid in its upgrades there will be times when downgrading to a more stable version of mono is preferred for OpenSim. At the time of this update, Mono version 22.214.171.124 is released and although it takes less memory to run OpenSim it increases its idle processor to %50 and crashes every few hours. This is not cool. If you have any previous and/or newer versions of MONO then we are going to blow up any previous versions of Mono that exist on our pi.
sudo apt-get remove mono-complete sudo apt-get purge mono-complete sudo apt-get autoremove
Next, we will take an earlier snapshot from the repo tree index. We prefer version 126.96.36.199 as it was the version that was released at the time of this blog but you may try others.
sudo echo "deb https://download.mono-project.com/repo/debian/dists/wheezy/snapshots/188.8.131.52/. main" | sudo tee /etc/apt/sources.list.d/mono-xamarin.list
Finally, install mono onto this unit.
sudo apt-get update sudo apt-get mono-complet
Note: If you are receiving an error as follows:
W: Conflicting distribution: http://download.mono-project.com wheezy/snapshots/4.2.3 Release (expected wheezy/snapshots but got wheezy)
You can try the following:
sudo echo "deb http://download.mono-project.com/repo/debian wheezy/snapshots/184.108.40.206 main" | sudo tee /etc/apt/sources.list.d/mono-xamarin.list
sudo echo "deb http://download.mono-project.com/repo/debian wheezy/snapshots 220.127.116.11/main" | sudo tee /etc/apt/sources.list.d/mono-xamarin.list
It really depends on the flavor of Linux that is running on your Pi. To confirm you have version 4.x or better, type in the following.
and it should respond with something like this.
Mono JIT compiler version 4.0.4 (Stable 18.104.22.168/5ab4c0d Tue Aug 25 23:45:14 UTC 2015) Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com TLS: __thread SIGSEGV: normal Notifications: epoll Architecture: armel,vfp+hard Disabled: none Misc: softdebug LLVM: supported, not enabled. GC: sgen
Congratulations! The mono language is now up to date and sets up properly.
Continuing on we do the basics such as setup the OpenSim.ini to operate in standalone mode by default. And then we have to modify the StandAlone.ini file to switch database control over to MySQL
wget http://opensimulator.org/dist/opensim-0.7.6.tar.gz sudo tar zxvf ./opensim-0.7.6.tar.gz cd opensim-0.7.6 cd bin cp OpenSim.ini.example OpenSim.ini nano OpenSim.ini
Now go to cursor position 1064 where it says the following:
; Include-Architecture = "config-include/Standalone.ini"
Include-Architecture = "config-include/Standalone.ini"
Ctrl-X and ‘y’ to save changes then:
cd config-include nano StandaloneCommon.ini
Then Change the following lines so it shows like this.
; SQLite ;Include-Storage = "config-include/storage/SQLiteStandalone.ini"; ; MySql ; Uncomment these lines if you want to use mysql storage ; Change the connection string to your db details StorageProvider = "OpenSim.Data.MySQL.dll" ConnectionString = "Data Source=localhost;Database=opensim;User ID=opensimuser;Password=opensimpassword;Old Guids=true;"
Effectively, you are turning off the built-in SQLite that is handled poorly by the experimental MONO package. By commenting out SQLlite and un-commenting the Storage Provider and Connection String for MySQL. We can then fill out your database name, username, and password. Save this file Ctrl-X and “y”
Now it’s important that when executing mono files it is case-sensitive. In this case, “OpenSim.exe” is the file we need to launch.
Choose your physics engine:
The stock version of OpenSim for Mono is expecting an X86 physics library. This will of course crash your raspberry pi as we are running upon an ARM-based architecture. Now if you want to simply test if OpenSim even loads on your Raspberry Pi you may edit the following line 250 in OpenSim.ini:
physics = basicphysics
Un-comment basic physics and add a semi-colon to comment out any of the others and save. Basic physics only pays attention to the land itself and your avatar will clip through all objects. It is however handy to know this in the event you are troubleshooting if it is a physics library that is crashing OpenSim or if there is something major going on.
Click here to learn how to install BulletXNA onto your Pi (This is currently the default physics engine for OpenSim Regions.)
If you want your Pi to run physics natively which means more faster collisions. You may want to choose the legacy ubODE/ODE physics. Click here to learn how to install it onto your Pi.
The LibOpenJpeg module:
This library is responsible for generating map tiles of your Region so that users can see you on the world map. It may be responsible for other functions within the OpenSim engine.
OpenSim System.DllNotFoundException libopenjpeg errors!
After you’ve installed and configured your estate and parcel for the first time, you’ll see these annoying errors that pop up 3 times every few minutes talking about how it cannot take a snapshot of your terrain because you missing libopenjpeg now! Following the Troubleshooting section it says to do the following:
git clone git://github.com/openmetaversefoundation/libopenmetaverse.git libopenmetaverse cd ./libopenmetaverse/openjpeg-dotnet/
I should note that the address on my site and the address in OpenSim troubleshooting is different. OpenMetaverse Foundation changed its file structure without telling anyone! So I updated my link. Before we continue any further! We’re going to pass the command:
The reason why is we have to strip the -m32 flag out or else when we pass the “Make” command it will get pissed off because we’re not on an X86 processor. go to line 37 where it says the following
and change it to:
save the file and continue to compile the library
make cp -p libopenjpeg-dotnet-2-1.5.0-dotnet-1-i686.so /opensim/bin/lib32/libopenjpeg.so
Finally, we have to tell OpenSim where our new library is which means editing the OpenMetaverse.dll.config in the OpenSim-0.7.6/bin with nano so “nano OpenMetaverse.dll.config” to get there. This is the original file.
<configuration> <dllmap os="osx" dll="openjpeg-dotnet.dll" target="lib64/libopenjpeg-dotnet-22.214.171.124-dotnet-1.dylib" /> <dllmap os="!windows,osx" cpu="x86-64,ia64" dll="openjpeg-dotnet.dll" target="lib32/libopenjpeg-dotnet-126.96.36.199-dotnet-1-x86_64" /> <dllmap os="!windows,osx" cpu="x86-64,ia64" dll="openjpeg-dotnet-x86_64.dll" target="lib64/libopenjpeg-dotnet-188.8.131.52-dotnet-1-x86_64" /> <dllmap os="!windows,osx" cpu="x86" dll="openjpeg-dotnet.dll" target="lib32/libopenjpeg-dotnet-184.108.40.206-dotnet-1-i686" /> <dllmap os="!windows,osx" cpu="x86" dll="openjpeg-dotnet-x86_64.dll" target="lib64/libopenjpeg-dotnet-220.127.116.11-dotnet-1-i686" /> </configuration>
And this is what mine is:
<configuration> <dllmap dll="openjpeg-dotnet.dll" target="lib32/libopenjpeg.so" /> </configuration>
Once again, stripping out the OS detection flag and pointing it to the right folder. save your file and restart OpenSim.exe
Finishing touches on OpenSim configuration files
from the /opensim/installation/directory/bin/ folder wherever you installed it to. We are going to edit “nano /config-include/StandaloneCommon.ini” So that when we configure our viewer it will auto-populate with the correct login information and not give us any crap in terms of connection issues to it.
[LoginService] WelcomeMessage = "Welcome, Avatar!" ;; If you have Gatekeeper set under [Hypergrid], no need to set it here, le$ ; GatekeeperURI = "http://127.0.0.1:9000" SRV_HomeURI = "http://opensimpi:9000" SRV_InventoryServerURI = "http://opensimpi:9000" SRV_AssetServerURI = "http://opensimpi:9000" SRV_ProfileServerURI = "http://opensimpi:9000" SRV_FriendsServerURI = "http://opensimpi:9000" SRV_IMServerURI = "http://opensimpi:9000" ;; For Viewer 2 MapTileURL = "http://opensimpi:9000/"
You’re going to want to find the [LoginService] in StandaloneCommon.ini around line 110. We are going to change it from localhost to whatever the logical DNS that your Raspberry Pi is. If you have a Domain Name for your Pi web server that automatically resolves the IP to you that is even better. In this example I am using the UNIX hostname ‘opensimpi’ that I configured in the advanced options in “sudo raspi-config” this will give the SecondLife client all of the information it needs when connecting to your Pi.
[GridInfoService] ; These settings are used to return information on a get_grid_info call. ; Client launcher scripts and third-party clients make use of this to ; auto-configure the client and to provide a nice user experience. If you ; want to facilitate that, you should configure the settings here according ; to your grid or standalone setup. ; ; See http://opensimulator.org/wiki/GridInfo ; login uri: for grid this is the login server URI login = http://opensimpi:9000/ ; long grid name: the long name of your grid gridname = "Raspberry Pi OpenSim Default Load" ; short grid name: the short name of your grid gridnick = "opensimpi"
Next, go to [GridInfoService] and do the same down here which is around line 190 on my configuration. Give it a unique grid name and gridnick so that you can easily see it when you configure your SecondLife Client.
Configuration of OpenSim complete launch it!
Which after all of this, go back into your /opensim/bin folder and mono OpenSim.exe . it should launch nice and cleanly like the window below.
The binary download of OpenSim libraries.
All of this compiling libraries and modifying configuration files sucks! Don’t you have binaries for my Pi?
For those who want a snap-shot of the configuration files that I have altered above. you may download this file and unzip it into your /opensim/bin folder to replace the .config files and add the proper .so files into your /opensim/bin/lib/ folder. We will however give you the lecture that most in the Linux community will do when it comes to binary files.
Which is binary files are typically compiled for a specific environment (in our case that environment is Debian Jessie Raspberry Pi Armv7.) The results may be unstable and unpredictable if you attempt to install these binary libraries onto another Linux kernel. It should also be noted that you are trusting this website to provide the binaries instead of compiling from the source yourself which could prove dangerous. Trust no one online and whenever possible always compile your own code.
In this example, I am using an older FireStorm v2 viewer so that I get mesh support and can build within the sim with something I already like on SecondLife. Click on Viewer and Preferences or simply hit Ctrl+P to open the FireStorm preferences menu.
As a note the beta versions of FireStorm do not have the Opensim tab in the preferences section of their client. I really don’t know why! So download the older final release and install it (Installing the final release while using the beta releases on Second Life does not conflict with each other. So you can have one configured for your Pi and the other that logs in normally.) Under Add new grid type in opensimpi:9000 or whatever YOUR hostname that you defined in the StandaloneCommon.ini file.
Once you have that typed in, you can hit the Apply button and it will disappear with an entry being added to your Manage Grids second. simply choose your new Pi and click Apply and OK.
The Log into Grid section will change to your Raspberry Pi and from there you simply type your username and password. hit Login and be patient as your OpenSim console on your Pi creates all of the assets of your new user for the first time logging in!
Performance of OpenSim
If you are expecting lightning-quick action of OpenSim out of an arm7 processor that only eats a few watts of power. Well, we’re simply not up to the task! You can tell just by how long it takes to make a map file. On my dual-core Pentium E6300 unit, it takes about 5ms, on the Pi 47ms. Perhaps you can run this in something like OSGrid since the number of people that visit your Sim may be only a handful at a time. But for the person that wants a DIY Metaverse and to work offline peacefully or with just a few people connecting for group projects. Then the Raspberry Pi is a great alternative to making your 24-hour OpenSim station. Building and working with prims is fast.
Using scripts is average but it really depends on the complexity of your SLscripts. Physics and Terra-forming is SLOW. it’s really better off to modify your sims parcel on a Linux box and then port it over later to your Pi. You click on one section of the land and it takes a second for it to respond. The ODE Physics although it works could potentially lag out your entire sim by rezzing about 32 cubes and turning physics on to watch them collide with each other. You will not only find it painful to move around, but your console will start to send you warnings about latency issues between the server and the client.
Performance Update with Banana Pi
Update note 12/24/2014: I have now upgraded to a Banana Pi which is made by LeMaker. It is a dual-core ARMv7 processor that runs at 1Ghz and has a gig of ram. Which falls in line with OpenSim specifications much better than the Raspberry Pi. Terra-forming is almost real-time. Scripts now work as if I was on a low-end dual-core Pentium.
Because of the Dual-Core action as well as the DDR3 ram on the Banana Pi which is separate from the On-chip ram of the Raspberry Pi, I would say performance is about 4-5 times faster than the Pi. As for power consumption, it’s actually better than my classic B pi because it uses a switching power supply similar to the Raspberry Pi B+. This means during idle it takes 320ma and when I hammer on the Sim with physics you are looking at 420-500ma which is better than the 700ma idle of the old Raspberry Pi.
For $20 extra you simply cannot beat that kind of price. I will be running my OpenSim on a Banana Pi until I can find something else. OpenSim will probably run great on the Raspberry Pi 2/3. Anything with multi-core processing helps out mono and therefore helps out OpenSim with all of its physics and processing needs. It should be noted that you really only need two cores unless you plan on running multiple regions on one ARM-based Pi.
Raspian vs. Pidora in OpenSim
I tried Pidora (Fedora for Raspberry Pi) for this procedure and the experimental mono package got even more unstable! Although it lets me log in just fine. If you shift-clicked on a prim to make a clone of a pre-existing prim in OpenSim. It would crash giving null database errors even when switching to MySQL. Although I love Pidora for its firewall features which Raspian does not have. And it DID seem to run a little faster under Pidora. The stability issues were just too much. I also tried to follow the instructions to hand-compile mono hard float and it didn’t work.
The screenshot above as to the world that is inside my Pi upon launch. We have since linked it to OpenSim as you could see my progress in this blog entry.
Some final touches to the background OpenSim so you can log off of your headless server
You probably don’t want to keep an SSH connection going all of the time on another computer. You want to run your Raspberry Pi in a headless state like I am doing. Well, there’s a very old Unix command that can help you with this.
sudo apt-get install screen
Screen command is a great tool allowing you to background processes so that even when you log out the process continues to perpetually run to get this started. type the following:
It will just go back to a blank shell prompt then cd into your OpenSim directory and launch your application:
Once that is done simply hit control+A and then control+d to detach this screen session. You can type ‘top’ to verify that mono is still running in the background before you log off. To restore your detached session simply type in:
And you are right at your OpenSim console! You may want to have a script that automatically reloads OpenSim in the event of a crash (Since depending on the version of MONO Installed it may happen often) follow this script:
until mono OpenSim.exe ; do EXIT_CODE=$? echo "`date +%Y-%m-%d\ \ %T` # OpenSim crashed with exit code $EXIT_CODE. Restart in 10 seconds." >> crash.log sleep 10 done
Save this file as “opensim.sh” and then give it execution permission:
chmod 777 ./opensim.sh
Finally, you can run ./opensim.sh and it will go into a loop if there is an error or gracefully shut down if you tell it to simply shut down.
Regardless of what Pi you choose, Raspberry, Orange, or Banana, it’s truly amazing that we live in the age where we can have single-chip devices powerful enough to host our own private virtual realities that people can log into. All without having to suck immense levels of power such as keeping a desktop running 24/7. There are also educational benefits of the system that Linden Labs have laid down years ago in the respect that a lot of the building and design of the world is focused around game design. By running your own personal world, you control said world. To control your information is of the up-most importance to all of us here. Hope this has helped you!
Take care and server protect you!
END OF LINE+++
50 thoughts on “OpenSIM + Raspberry Pi + Rasbian Hard-Float= WORKs!”
Have you tried this on the Raspberry Pi 4b yet?
Not as of yet.. I tried it on my 3 and it’s almost to system spec.. a little slow with bullet. but i’m still on ODE because i like how my avatar moved around similar to old school second life with ODE..
As a matter of curiosity, would it be possible to offload some of the functions to a second Pi? I know that the MySql server could be remotely hosted. How about the physics engine, for example, the tree module, etc. etc.?
I’m thinking maybe spreading the load for a single estate, multi-region sim across multiple Pis without having to engineer separate estates to line up on separate servers.
Although I haven’t messed with such a thing.. There was a demo that IBM put up dealing with hosting several hundred avatars on the same region with distributive computing. Something that not even linden labs could do. http://opensimulator.org/wiki/Distributed_Scene_Graph talks about it with distributed scene graphing. I never played with it because to be honest i was happy that the mono-project stabilized mono enough to run OpenSim.
Anyhow. hope that helps answer what you may be looking for.