Dissecting RoboOS

I did not know where to put this topic since it fits both the R2 and C2 and can be used with the R1/R1+. But since there is such a lack of information related to what is and isn't included in RoboOS, I thought it might be wise to have a place where we as a community can add information as we get it for the betterment of every Robo owner.

Feel free to add any and all information you can determine about RoboOS.

 

So far I am on my thrid copy of the original SD card trying certain things and breaking its functionality. When I figure things out I will post them here. So far my main goal has been to try to change the installation of OctoPrint from the Robo modified version in their own github repository into the standard github repository from foosel.

So far I have found that there are actually two complete installations of OctoPrint on the SD card, one functional and the other not. The working one seems to be installed in oprint which is similar to the way that OctoPi is built, there is a non working version in Octoprint which in linux is different than the wiki suggesting OctoPrint as the default directory.

We will see if moving the installation to the wiki default installation directory will work.

 

Moving things around on the Raspian distribution has broken my images three times now, I am going to see if it can't be built from scratch and still mimic all the functionality of the original RoboOS.

 

I am going to approach this from a different angle. I am recreating the RoboOS distribution from Raspbian Stretch and the GITHUB repositories that Robo has published. The goal is to make the build as small as possible to facilitate uploading here. If there is anyone that can add to the conversation, please do as I may not either find or get all the parts working myself. I think this would felp clean up a lot of issues that people might have with the RoboOS build.

So far I have Raspbian Stretch on a 4GB µSD card and OctoPrint installed.

 

I have only JUST started experimenting with stretch.
I like it, but other than that... not much practical experience in migrating stuff -- yet.
I suspect it is a bit more complicated than previous releases -- you couldn't go from an older release to Stretch with an in-place update.
Probably just a bit more work.

 

I have most of the plugins installed with appropriate ones that snoop too much or send information about your printer to places unknown currently disabled.

 

I have it booting and OctoPrint runs, but so far no RoboOS screen output, need to check a few things, it all fits on a 2 GB µSD Card.

 

I have it booting on the rPi but it only boots to the Raspbian login prompt, I need to search through all the scattered Robo repositories to see if I can determine how they put it all together.

Some things I noticed about RoboOS, it appears to be built on OctoPi and has two physical implementations of OctoPrint on it, one functional the other just taking up space. RoboLCD forces you to pull all the required addons and OctoPrint from repositories maintained by Robo3D even if nwer version of those plugins exist on the original authjjors repositories. Robo's Octoprint is two releases behind the Foosel (actual developer github) version.

 

I already know where all the parts are located, some are in Robo3D GITHUB repositories and some are still in other repositories. Since Robo used OctoPi as a base it is running in a venv. The other Octoprint (notice the case) appears to be superfluous and not necessary. There are a few other oddball things with RoboOS, I can't find a single instance where any changes they have made to their forked repositories has been made into pull requests to the original source providers. I could have missed one, but I certainly could not find any instance where Robo has contributed to the OSS projects they have relied on to complete RoboOS.

There are also some plugins that send information to other servers that are still undocumented and apparently at least one broken one that will not enable.

 

The big issue left to solve would be getting kivy to run on startup (the ROBOLCD is based on kivy) and the boot logo. Unfortunately there are several ways all incompatible with one another on how to get the boot logo on the rPi, there is Plymouth (which is think has been depricated) and there are packages that can be used, it is just a matter of figuring out which one they used to replicate that functionality. All this is on hold at the moment while I get a replacement screen for the R2 as the touchscreen is now dead. I have a spare rPi3 and an rPi2 I have a 3.5" screen and a 4" IPS screen, but both require drivers and doesn't appear to work very well with RoboOS. I have the 5" Waveshare HDMI screen coming from Amazon so I can test without crippling the R2 in the process.

 

Hey Guru the stuff from chickenchuck040 is where the original RoboOS code came from, Investigated that a long time ago. Also RoboTheme came from Voxel8, they have made quite a few changes since then. Still all on hold at the moment.

 

That would be true if there weren't examples the prove the opposite, that do contribute to the OSS community. I am all for companies modifying code to make things work better and in that you are correct a lot of small companies do borrow code from OSS projects but companies like Prusa Research, Aleph Objects, Ultimaker to a smaller extent, all small companies trying to survive do contribute.

I have studied a lot of the code Robo uses and there is a lot of stuff I wouldn't want in the upstream repos, that doesn't mean you don't even attempt to contribute.

 

con....con....contribute?