 Thank you, Renee, and thanks for everyone for showing up. My name is Trenton Schultz, and I'm actually a PhD candidate at the University of Oslo, and I'm looking at human-robot interaction. And this is kind of a story that's based on the side path of what I was doing in my research. So when we got a laptop at the University of... or when you get a laptop as part of a PhD candidate, they're kind of okay with you can install whatever sort of operating system you want on it as long as you're willing to take care of it. So I installed FreeBSD, and that worked pretty well for a year or so. But then I eventually had to start working with robots, with robots, and I needed to use the robot operating system, or ROS as it is called. And, well, it really needed to work run on an Ubuntu system to work very well. And I was thinking, well, maybe I could try to port this. And so this is kind of a story of porting and how it works. We'll see how well it kind of works out at the end. So first I'll talk a little bit about why you would actually need some sort of robot operating system. So if we take a look at a robot, a robot has kind of this interesting combination of a physical presence and software. So this is a Turtlebot 3. It's a robot that kind of just moves around and can be used for kind of sensing its environment. And it has several parts that we need to kind of, that a robot needs to do its things. So first it has a sensor, which here's a LiDAR sensor, which it uses to kind of figure out where it's going. It also has these motors and wheels that it can use to move around and turn. It of course has a microcontroller that controls these different wheels and the sensor. And of course you have a CPU that would be the brain of the robot. But of course this is all software or hardware that's just running by itself. So you actually need something else to, you need software that kind of like works and deals with all these things. There's something that'll be reading data from this LiDAR sensor. You need to be able to start and stop your motors and like for example turn them. You need something to drive the controls hardware that will actually tell it to do that. And then on the CPU you need to be running navigation to be able to figure out where you want to go. You need something called odometry which is basically telling you where you are at the moment. And then you also need to be able to send commands to these things so everything works like that the LiDAR sensor is on, like what is the current value from the LiDAR sensor so I can figure out where I am and all that. So this is kind of, you know, there's a lot of software that you need to do to work with this. And this is kind of where Ross can come in. So calling it an operating system is a bit of a misnomer. It's not really an operating system but it's a bunch of things that you can get that will help you run a robot. So how Ross likes to describe it even on their own website is that the first part is plumbing and that's this middleware layer. So it's this middleware network that you create nodes that can either publish or subscribe to information and then you have messages that you define and these are well-defined messages that all the robots or all the nodes in the network know about. So you can publish, for example, picture information, you can publish sensor information and another node can pick up that information and do its processing on it. Of course there's also a need for tooling around working with robots. So you need ways of being able to check what these nodes are saying. You need to be able to see probably simulation environments to be able to test robots before you have a robot built. You also might want to actually capture data and replay it back multiple times so you can refine algorithms or other things. So these are things that you need to do a lot when you're building the robot and getting things to work adjusting your algorithms. The other nice thing about this is kind of the other two parts are kind of built into that. So once you have this plumbing layer you can design these capabilities. You can basically build nodes on top of each other and build libraries so that you can do things like navigate around. So you can build a navigation stack and then, for example, if you wanted to do something like take out the way that a robot speeds up and slows down, like I was doing in my research, then you just have to build that little section and you don't have to build an entire navigation stack, which is really nice instead of having to, like, learn a whole new navigation stack and do it for every single time. And then the thing is that there's this community that kind of springs up about it because everybody wants to kind of share these libraries and have it work with different robots. And that's kind of the other side of this. At the end of the day, you know, it's great to do it for one robot but eventually you're going to want to be able to do it with lots of different robots and Roth kind of enables you to do that. So on the Roth's website, they have a list of all the robots that are currently available that can run Roth. And in general, most of the robots that you're probably familiar with that are, like, not science fiction robots are probably listed on there and have a sort of Roth interface. And then the final thing that they do to kind of make this work easily is that they have kind of standardized on an Ubuntu distribution and they basically have releases that follow that are similar to the Ubuntu releases. So right now there's these two here that are in green and these are basically following the long-term releases, the Ubuntu long-term release thing. So you have the... And they all have these wonderful animal names so based on sea turtles, of course. So you have the kinetic Kame and the melodic Mourinia. And yeah, so these will be there until the end of life and then they have some little incremental releases that happen that are tied to other Ubuntu releases. So in general, they've kind of, like, standardized on Ubuntu and this kind of comes back to where I was. Like, I kind of wanted to see if we could run this on FreeBSD and the main reason I kind of wanted to do that was that I felt that this was a way because most of the software was open-source that we would keep, like, putting it on FreeBSD helps keep Roth honest about it being open-source and actually running on multiple platforms. I also thought, like, it was weird to kind of have this weird... have a monoculture of operating systems for robots. I mean, there are other security issues with Roth that I won't get into in this talk but it would seem that having multiple operating systems might be a good thing when you're dealing with robots. And then the other side of it is that Roth, in general, is kind of all... it's not dealing with hardware directly. All that hardware stuff is kind of you have to build that yourself in whatever operating system but Roth itself is offering communication nodes which is based on networking so it's assuming you have a networking stack working, you have that working. All the tools are basically cross-platform. There are no system-specific things in those tools. Yeah, and so all of that stuff was cross-platform by nature. I looked at what most of the stuff was built out of. It was built out of C++, Boost, and Python. And I was like, well, most of this stuff is already available on FreeBSD, so why don't we try to do this? Now, of course, the first thing you're going to do when you want to port something to FreeBSD is you go to Freshports and double-check if it is there. And there was a version of Roth already. And Renee, who just introduced me, actually was the person who did it back in the day. But you might notice here that it says that it's been deprecated because it's unsupported upstream and it expired back in 2015. And the version is 1.4.10, and this corresponds back to this diamondback version, which came out in 2011. So there's been nine years of changes that have happened with Roth. And you can see even back then that this version of Roth didn't have an end-of-life date and it did not have this sort of more coherent distribution way of doing stuff. So I was like, well, maybe we can try to do this. Maybe we can try to get this to work. I went to the website and saw that they even had a way of building it from source. So I was like, okay, there is a source infrastructure. I could probably build this myself. And I also saw that it had a Mac OS X homebrew instruction. So then I thought like, well, maybe some of these shell script Linux-isms have probably fallen out a little bit too because there's a free BSD user land in OS X. So that was kind of the thing that I tried to do. And I kind of wanted to follow the source instructions and do it sort of the Roth's way with trying to blend it a bit with free BSD. So if you're going to build from source for Roth, they basically divide it up into three big steps. The first step is installing the prerequisites, which is Roth step and its friends. The second step is you use those prerequisites to create a source checkout of Roth. And then finally at the end you build Roth. And then hopefully you have a working system. That's of course the final step that they don't mention. Of course, for doing this thing, which I found jails to be extremely helpful in this because there were times where you actually had to install a lot of things and maybe you didn't want all those things on your system that you would probably forget about and just they'd sit there forever taking up space. And then you didn't want extra dependencies kind of like affecting your build. So the jails were a really good way of helping out, making sure things were sane. So step one is to get the prerequisites installed. So we already have quite a few of the things already in the system and in the ports tree. And there's just a couple of things that are very Roth-specific that aren't in the system already. So claying, boost, cmake, ninja, and then a lot of Python libraries. There's a little side note that Roth at the moment works best with Python 2.7. They claim that, like they've been claiming since 2015 that like all maintainers and everything should make sure that it's running at least Python 3.5 or whatever. But when I tried it out here with Python 3, it did not quite work right. So I just went back to Python 2.7 and went there. There's, and looking at other things in there, there's a bit of work that needs to happen before Roth can truly be a Python 3 thing. So that's outside the scope of this talk. But there are some missing bits here which I'll talk about. So there's Roth install generator and this WS tool thing and then several small Python dependencies. So what are these things? Well, Roth has this enhancement proposal thing, which is of course very similar to the Python enhancement proposals and I guess to some extent the FreeBSD community proposals. And they've documented, when they started going into this whole way of making it following Ubuntu, they were very good at documenting how things should work and how things would be built up. So there's of course lots of reps here. Rep 3 of course is just talking about how they're targeting Ubuntu and what is important for them. Rep 125 is this Roth step 2, which I'll be talking about in a moment, and then Roth step 2 is also very dependent on these Roth distribution files. So I'll talk about the Roth distribution files and then talk about Roth step 2. Roth distribution files, they are basically just a set of YAML files that explain how... explain first dependencies for the operating system or for components for Roth. And then it also explains like, okay, this melodic distribution has all these components. So if you want to say that you have a melodic distribution, all these bits need to be here. So here's an example I took of Bzip2 because it's an easy example to point out and you can just see that this has these different architectures here. So you can even see they have a Sigwin stuff, they have Debian, Fedora, and then a FreeBSD bit that's in there. So this Roth distribution file is used by Roth step. So Roth step is basically a small little program that will update your distribution information and install dependencies. So how it works is that first it will find and download the Roth distro files from Roth or from the Roth GitHub repository. So it downloads those YAML files. Then later you can say, I want the dependencies for stuff and it will actually go and call the local package manager on your operating system and install the things. So Roth step, yeah, so there's backends for pip, yum, apt, and there was one for FreeBSD, I guess Renee did some of that. There was one for FreeBSD that was using package, but it was using the older package tools. So using package underscore add, package underscore remove. But that was actually very, very straightforward to just update to use package. So then it basically will be using package. I mean, one could in theory also write just a straight ports back end if you really wanted to do that, but you're going to be spending a while building Roth anyway, so maybe you want to cut down on compile time and actually get to building Roth instead of building all the dependencies. So the other programs we need are this Roth install generator. That basically will also use the Roth distro file to pull out all the names of the components that we need, and that will be stored in a little tar file that you can then feed to this WS tool program, which will then, which basically is just a cross source code control mechanism for downloading shallow clones or whatever of a source code repository into something called catkin to a catkin workspace. So catkin is a Cmake and Python macros. And then finally there's something called Roth console bridge, which is just a way of bridging information from one program into the Roth logging system. So those are all the prerequisites. And most of them, as I said, were Python libraries or Python ports. So it was actually pretty straightforward to create ports for all of these. And so I did that. Now, once those are installed, then you can actually try to build Roth or get the components. So this has several steps as well. So first of all, you initialize Roth step. That will download those distribution files. You do that as root because you want to write it to the user local Etsy directory. Once you've done that, you run Roth's update as a normal user. That will then update all the files, make sure it has the latest version of everything. You make a catkin workspace directory, CD into it. Run this Roth install generator thing. Roth, of course, has several different levels of distributions. You can have one where you're just dealing with communications. You have one where it's getting all the desktop tools and then you can have a full desktop, which also includes all these different simulators that are included. For this talk, I'll just have the desktop here. I've tested desktop and the communication tools. These steps here are going to be pretty much the same. The full desktop will not work at the moment because we need to port simulators over, and that's not in the ports tree. So that's something for future fun stuff. So once you've generated this Roth install file, you pass it to this workspace tool to download all these files. So this will download, in the case of a desktop, about 190 projects that are specific to just Roth. And then you have to build the dependencies. No, you don't have to build the dependencies because you use Roth step to just install all these dependencies. So Roth step then will go through its files, find the free BSD dependencies, and install them. So it just will call package for you. Of course, it's assumed here, well, since it's coming from an Ubuntu world, that it will use sudo to install. So of course, your user needs to be in the... The user building needs to be in the sudoers file. Then you run a little patch. Most of this patch is actually fairly straightforward. A lot of it is that the minimum version of GCC is not as strict on C++ as the clang is. So most of the changes in here were changing a zero to an... or using a null where they were passing null and then actually using it as an integer. So you just actually change it to a zero instead. And there was one other small change where... One of the packages has its own copy of G-tests. And of course, the include paths get messed up because you have the Google tests that get installed as its own thing. So you just kind of move that to a... what do you could say, a G-test 1.7 and link to that instead. Once all that's ready, you just run this cat can make isolated. And then you pass it... you tell it to use ninja and it just builds. The reason you tell it to use ninja is that since this is coming from Ubuntu, it will generate GNU make files. And it will just call make, which of course will call the BSD make, and then it will fail eventually in one of the make files because there's a disparity between GNU make files and BSD make files. And at the same time as like, well, if I have to install another build tool to make this work, I may as well use ninja because in free BSD in the port's tree, anything that's CMake-based is set up by default to use ninja at the moment. So I just used ninja and it made life slightly easier. Then you just sit around, wait, have a cup of coffee and stuff, and everything should build, right? Until it doesn't. And there's one issue here that I couldn't fix all ahead of time. And it's basically... Ross uses Qt for a lot of its graphical tools. And they have, of course, Python bindings that they create for all their items. And what they did there, and so that, of course, means they need to call SIP or PySide to do this. And what happens, of course, it generates a make file and the sipconfig.py has some sort of issue and it's one of its patches that passes bad path information in and bad names for libraries. It says it should link against QtCore instead of Qt5Core. And I don't know how to fix that yet, so I will probably send a thing to the KDE people at FreeBSD.org and see if there's a way that we can fix it. Because it seems like it's just a patch that happens in sipconfig that just goes a bit wrong. But anyway, so I had to fix that make file manually. But once that's done, it's done and it's built. So I'll show you a demonstration of that and see how well this actually works. So a live demo. Yeah, I know. Yeah, I was gonna say... Ideally, I would have liked to have had a robot here that I could have shown off. But the problem was that... Well, yeah, there just wasn't time to get a... to test this out with a real robot. So I'm going to show you a... This is going to be an example that's like all locally on the computer. So the example I'm going to show you is the... is a example for transformations. So the idea here is that... I will try to point this out. I've run a node already. And then... or run a program. And this creates several nodes. So we have a simulator node, which is this turtle simulator here. We have a tele-operation node. So I'll be using that in a moment. And then you have two turtle broadcaster nodes and a turtle pointer. The idea of this is that... To show... It's a tutorial to just show how these... I have to... The user interface isn't perfect for this. So the idea is that you're supposed to be able to move this turtle around. And it's putting out transforms. And the other turtle is figuring out its transforms. And so it's basically just... You know, you have a world transform. And it's just like trying to show that you can figure out all this in pretty quick time. And the other turtle is able to follow you and get close to you. And everything like that. So that's kind of the main point of that. It's showing that there's several different nodes that are running here. These nodes didn't have to run on one computer. I mean, ideally these two turtles would be different robots that would all be connected onto the same network. So what I'll also show here, just to kind of show that it's not just a fluke, is... So when everything is built in Roth, you get this Rothcatkin workspace. And it all ends up in this install isolated directory. Now, I was playing around trying to get my... Trying to do this all from inside the jail. And I couldn't get the X display to show correctly. So the nice thing is that this install isolated directory really is isolated. So there's just like a little setup script here that you can set up all your environment variables. So I can also do a Roth topic list. And so that'll actually go through and list all the topics that are available. And just to kind of show an example here, I'll just do a Roth topic echo. This is the example of Turtle1's poses. So this should... So it's just basically printing out all these poses. But if I start moving, you can see that all these values are changing. Now, of course, this is fine when you're doing some debugging, but maybe for other cases, you actually want to store that topic. You want to graph that topic and stuff. And all these tools are working. I can also show there's a visualization program. Let's see if I can get that working. But for this thing, it doesn't show something very amazing. And, of course, it crashed. So that's why you don't do too much on demos. But it's basically a visualization program used for visualizing different values. And you can also use it to kind of do mapping and navigation. But apparently, it crashed. So I'll let that one go for now. So that was my demonstration. And basically... So what's next, so as to speak? So I've created a bunch of bug reports for all these ports here. So I put them in. I recently updated them all this last week to make sure that they're running the latest version that's available from the Roth upstream. For example, Roth step, I was actually able to push the package changes up to them. And they were actually very willing to accept them. They said, like, we'd have no specific rules that we don't want wanted to run on other operating systems. We're happy to have it run on other operating systems. But they aren't going to provide much infrastructure for testing, at least at the moment. But all these work... A couple of them are a bit hairy. This Devel Collada DOM program, or library is a very old library that doesn't seem to be maintained much, but it's a requirement inside the thing. So I got it to build. That was probably more difficult than most everything else in this. The other thing that needs to happen is I need to push up more of these Roth distro things that have more of the free BSD items in there. I did this very ad hoc. So I basically would go through, run Roth step update, or Roth step install, and it'd be like, oh, I don't know how to install this package. And then you would go look up with the packages and put it in. There could be a way of actually probably going through and being a bit more correct in making this a bit more complete. And then I'm positive that this can also be pushed up. I got some version of this pushed up, but they were also like, well, yeah, but you're missing some, like some of these things don't actually exist in fresh ports, so do these things actually exist? And I'm like, well, it's kind of a chicken and egg problem. So you have to put that up there, so there's a reason to put it into fresh ports, I was thinking, or into the ports tree. So in the meantime, I have created two sort of sort of GitHub things, the FreeBSD MyPorts has MyPorts, but it also has a Roth thing, and that's set up to use the Portshaker thing, so you can actually just mix that in with your other stuff. There's a couple other things in there too. If you're a big fan of running Zotero, you can actually build a port of that too, but that's a whole another story. And then there's a Roth distro, and then I have a copy of the Roth distro, which is basically up to date as of earlier this week. That file does not change much. So you have that, you're basically ready to go. Oh yeah, there's this thing called Roth 2. So all the stuff I talked about is Roth 1. You could say if you've been in the Roth community, people are aware of several issues with the current version of Roth. Two that I can name off the top of my head are, one, the network design is not very secure. You're basically recommended not to run it with a firewall because it creates all these UDP ports that there's no range. It just picks one, and it's like, we're going to use this now. The other thing is that the current Roth architecture with its nodes and everything is too slow to do things in real time. So in the robotics community, there's a thing called RoboCup where you build your robots to play soccer, sorry, football, we're in Europe, to, yeah, and all that is built custom because Roth is too slow, but Roth 2 is an attempt to actually have a bit more real time, and they actually have sort of a real time controller that's actually included, and you can add your own as well. Good news, most of the tools that I just talked about, Roth DEP, the Roth install files, you use those as well in Roth 2. So the fact that they're already there, you just probably need to build a different Roth install file, and instead of using Catkin, it uses a different build system, but it's the same thing, it's a bunch of Python and CMake macros that are inside the Roth distribution. So that's basically it. I would kind of like to say that my take-home is that Roth can be brought to FreeBSD. It's going to need some work. I would say the lowest-hanging fruit is adding the ports and then pushing the Roth distro stuff upstream, and as I said, the Roth group seems to be pretty willing to accept these new changes. In the longer term, creating perhaps these Roth desktop meta ports and then building all these other little bits in, but the thing is with these ports, you can actually build your own Roth distribution on your own, which is nice. So that's kind of good to have. The other thing that should be done is looking at the gazebo simulator. So this is like a full-blown kind of physics simulator where you can take a model of your robot and put it in a simulator and see how it works. It's very nice. It's very GPU-intensive, but it would be good to have. And it's also open source, but I don't think anybody has bothered building it for FreeBSD. And then finally, also Roth 2. But after taking a look at what the basics are with Roth 2, I think it actually is a fairly low threshold to actually get it working on FreeBSD. With that, I'll say thank you, and I'll take any questions. Thanks very much for the talk. It's not my main question, but I wanted to know a little bit more about your GitHub account name. That's a long... It's a very inside joke. In Norway, there are these forest cats. They're actually called Norwegian forest cats in English. And... Oh, sorry. Oh, 10 minutes. Okay, good. But how could you say my mom mistaked a forest cat for a rock cat, and so it's just a kind of inside joke. So there you go. And my main question is... So I'm trying to work out how you would actually get this on a robot. Presumably, you want to install FreeBSD onto the robot and then just package and install ROS or something like that. But how do you get FreeBSD onto the robot in the first place? Right. Well, for example, that Turtlebot 3 that I showed you, all it is... The main CPU is just basically a Raspberry Pi that they've used, and they actually just use a Ubuntu distribution or Raspberry Pi and put it on. And it's a full distribution. They include... They tell you for that robot, they're like, oh, just plug in the HDMI cable and load up X and then do the rest of the ROS configuration in there and then unplug, which really kind of frightens me. But ideally, yes. I think what you could do is just do the ROS bare calms, and that would get you sort of the basic stuff to create a core, a ROS core node, and then you would basically build your own things and just kind of install them. So it's... How could I say? The weird thing is that since it's built on Ubuntu, every robot thing is kind of built on this idea of like, oh, well, you have a natural, complete Linux distribution, so you have all that stuff, right? Just secure shell in and copy it over and all that. So, yeah. Anyway. We have this company called Sparkfun that sells lots of tinker toys like this. They do an autonomous vehicle challenge every year, and they've since stopped doing the airborne version, but they had a group drive like a Jeep around a track and they have different sizes from like, it's really fun to watch. They have like the pint size and so anything under, you know, a pound smaller than four inches tall and then they have different sizes all the way up to the jug entry category, which is the Jeep. It's competing by itself around their parking lot. Right. But they used to also do an airborne version and that was really fun to watch because, you know, they're quadcopters in various things and it was around a lake and they had to drop tennis balls like in a... a rough part of the lake and then they had to... you get points for anything you do and you have a time limit and so every second it goes by you lose a point. And they... So any of the challenges you do give you points. So it was really fun to watch but occasionally you see interesting things like someone did it with a gas helicopter and so that was really fast. You could get a lot of points quickly but it also like crashed into the side of a hill and caught on... started a little fire next to a group of people watching and one of the quadcopters we don't know what happened but it was flying along just flying over the lake and then all of a sudden just straight into the lake and gone. So check that out if you're interested in watching some of the videos. I will say Ross2 is also that was part of the reason for Ross2 is that quadcopters and stuff Ross1 is too slow for that. So, yeah. Anyway, yes. Maybe I missed this but so the robots that run Linux how do they do the hardware control for motors and sensors moving around? They're usually like the Turtlebot 3 there is using something called OpenCR which is basically their version of Arduino. So as far as I know they just have a thing that connects to it and then they just run they have a driver for that. So it's called OpenCR it kind of has an open specification. So they hand off all the work to a microcontroller to do the stuff in your time. So it's not so basically the CPU does all this communication or all the calculations and then it just basically sends like these other messages off those messages will then tell a microcontroller to do the feed. So there was a talk at BSDCAN a few years ago where there was a bigger one black hexapod that walked around and that used the real time units on the system on a chip to do the drive so you wouldn't have a microcontroller. But that would be a lot of stuff to port to free BSD. Probably. It would be. The other thing that's kind of nice about this is that you can also still use free BSD as your daily driver and run all these tools in kind of the other part of it. I mean the robot that's on the main picture on the front page of the thing is running a version of ROS on a Linux distribution. Ideally I wouldn't but the idea with ROS is that all that stuff is like platform neutral. So I can still run my tools I can run my calculations on my own computer. If I have a stronger computer and a good enough network I might be able to do better than the thing that's on the robot. So that's the other kind of advantage with it. Anything else? No? Well thank you very much and enjoy the rest of the day.