Mirek and AB give an introduction/primer on ROS – the Robot Operating System – an open-source framework for developing robotic applications.

We cover ROS’s modular design, which allows for the separation of tasks and communication between different nodes or components. We touch on topics such as ROS’s messaging system, simulation tools, robot description formats, and the importance of Docker for containerization.

We touch on the steep learning curve associated with ROS, the availability of tutorials and community support, and the decision-making process for companies considering whether to adopt ROS or develop their own solutions.

Mirek hares his personal journey with ROS, his work on developing a tool for remote robot control and data visualization, and the potential for scaling ROS to handle swarm robotics scenarios.

Towards the end, we discuss the recent developments at Boston Dynamics, including the unveiling of the new Atlas robot, and the company’s use of ROS in their projects.

We’re also publishing this episode on YouTube, if you’d like to watch along in full living colour: https://youtu.be/Wsw8mDnMGnY

Chapters

01:22 Introduction to ROS

We introduce ROS (Robot Operating System) as a framework and messaging system for enabling communication between different components of a robot. We highlight that ROS is not a traditional operating system but rather a middleware that facilitates the integration of various hardware and software components. ROS is described as a powerful tool for complex robotic systems, but it comes with a steep learning curve.

04:35 ROS Architecture and Components

The discussion delves into the modular architecture of ROS, which allows for the separation of tasks and communication between different nodes or components. Each node can be responsible for a specific functionality, such as reading sensor data, controlling motors, or performing navigation calculations. ROS provides tools for describing the robot’s geometry, simulating environments, and handling communication between nodes using protocols like WebRTC and UDP.

15:57 Learning and Using ROS

We talk about the challenges involved in learning and using ROS effectively, including the availability of tutorials, documentation, and community support, but also highlight the variability in the quality of these resources. Mirek shares his personal experience of spending a significant amount of time learning ROS and developing a tool for remote robot control and data visualization using WebRTC and Docker.

34:19 Adoption and Alternatives to ROS

The discussion touches on the decision-making process for companies considering whether to adopt ROS or develop their own solutions. While some companies may find ROS too complex and opt for custom solutions, the participants argue that ROS can be beneficial for projects involving iterative hardware changes or complex tasks like navigation and computer vision. We also mention the availability of commercial ROS-like operating systems and the option of writing software from scratch using libraries.

40:18 Boston Dynamics and ROS

Towards the end of the discussion, talk turns to the recent developments at Boston Dynamics, including the unveiling of the new Atlas robot with its impressive capabilities. Mirek confirms that Boston Dynamics uses ROS in their projects and provides access to robot models and descriptions for use in simulations.

Transcript and Links

AB
Well, g’day and welcome to SPAITIAL. This is Episode 18 – coming to you from the early part of May. Yes, it’s just been Star Wars Day. Yes, I did wear my Chewbacca suit. That’s a story for a different day.

Welcome again. I’m joined here by Mirek Burkon, our robotic expert, mechanical expert. Hey, Mirek, you good?

Mirek
Hello, how’s everybody doing?

AB
Good to see you. Look at that background for those who are listening only.

Yes, this will also be a YouTube episode. It’s also a readable on our blog. So any medium that you wish, in fact, it might well be on Medium as well. Doing the classic thing of “you can choose your format”.

Today’s episode is actually going to be a one-on-one. We get the absolute pleasure of picking Mirek’s home topic. If you’ve already seen the episode title on the icon, we’re going to talk about ROS.

ROS is the robot operating system. It’s a relatively standard staple. It really is the go-to for a lot of robotic open source projects. But here’s the complicated part… It’s complicated. That’s probably the one liner of the whole thing.

It’s powerful. It’s phenomenal. It’s used in a lot of places. But let’s just say that the first step is quite a doozy. There’s a lot to learn. We were just having a chat as we were getting our mics tested.

Remember those old board games of, you know, “a minute to learn and a lifetime to master”? ROS tends to be a little bit more in the “a fairly long time to learn and a few lifetimes to master”. No slight on the devs and the team trying to put it in place.

It’s not overly simple and they’re not trying to do it in a simplistic fashion. It is quite a powerful tool set, but it needs some explaining. And that’s why we’re here. Mirek has been well, he’s actually been quite quiet on the Internet for about 12 months, even two years.

Mirek 02:32
That’s because I’ve been learning ROS. That’s why.

AB
Gotcha. Before I knew it, you were a 21-year-old and you had, yeah, gray hairs with paint on every morning. To be serious though, I’ve known you for definitely two years plus, but you’ve probably spent 12 months kind of in self -imposed hibernation slash isolation.

You’ve got head down and you’ve been really going through this knowledge that we’re gonna pick apart now. So, Merrick, what’s your summary of the ROS system? First of all, is it, it is ROS, I take it, not ROS. There’s only one S? That’s what the community is happy to call it?

Mirek 03:08
It’s ROS, people call it operating system. That’s what it’s kind of coming into it. That’s what you expect, but it’s not really an operating system in terms of Android or iOS or anything like that. It’s more of a framework and a messaging system and the middleware to have multiple parts of your robot talk to each other.

Mirek
And it’s really complicated. The learning curve is very steep. I think I mentioned this on this podcast quite a few times. There’s a bunch of reasons why you wouldn’t use ROS. And that’s where you, say, have a simple machine that, you know, everything you program happens on, say, Raspberry Pi.

And, you know, that one board is perfectly fine to read some sensors and drive some motors. And if that’s all that you’re doing, then you’re fine. And you would completely pass over the name. You wouldn’t make your life easier with ROS if you’re doing this sort of thing.

ROS is more of a design infrastructure and lots of code and lots of best practices for systems that are slightly more complicated than that. Say you have multiple boards or even multiple configurations of a machine, different parts of hardware, different versions you’re iterating on something.

And instead of one monolithic piece of code, you have nodes that do specialized things. Say you have one node, piece of code, piece of application that reads your battery level and broadcast that information.

And then you can have another node that reads instructions for how to drive the motors and sends those signals to your motors. And there’s bits of logic behind this that sort of takes into account maybe a battery status, but maybe most importantly where you are in the scene, we’re trying to get and translate that into signals or data for these particular nodes.

And this is handy when you then replace your motor. You don’t need to rewrite the application. You have this isolated piece of code, say a driver, that just comes and goes. And in terms of ROS, it’s pretty much something that is supposed to run on any hardware configuration, any machine.

Mirek 05:37
In actuality, it runs on specific flavors of Ubuntu and specific distros. So you sort of begin this whole process by setting up an environment for ROS, which could be running on Linux or it could be running on a microcontroller.

And then talk to the rest of the system through this other subsystem. That makes it easier. Believe it or not, it’s actually much easier than to not have this. Okay, so there are some guidelines.

AB 06:08
there are some there are some please do’s there are some suggestions but essentially it starts with a cookie cutter of here’s a bare bones roars install you get a VM you get a package or you start on bare metal

Mirek
You usually start with the tutorials that get you so far as driving a simulated robot Like the simplest form of a robot that you know in this universe is usually a turtle bot It has two wheels, some sensors and you can drive this robot around to click on somewhere on the scene which is giving coordinates to your simulated robot and then it responds to simulated sensory input This can be also done on real metal, but it’s just much easier to start a simulation So you start with that and usually you watch tons and tons of videos and re -instants and tons of Documentations and most of the time people trying to show you what this is about go into great details installing something and configuring something for 40 minutes, which is tedious to watch but that’s Mainly your experience like you get tons of code and instructions and best practices and how to’s But then there’s code that sometimes is documented really well Sometimes the only documentation is the code itself Okay, but it’s still so useful to you then, you know starting from from a blank page that it’s Really useful to just dive into it take the time and then figure out how to configure this particular piece of logic to work with your Hardware, which is what you’re doing most of the time and as you dig into it you figure out that Oh, this code does almost what I need But you need to be ready to to modify that to dig into it and just you know, follow Where the other person left off because this is an open source Open source ecosystem.

Yeah, the people come from into it and expect the Polish product But it’s it’s a community of people and sometimes somebody shows you, you know, this is how I do it and it’s

AB 08:19
Yeah, it got you half handy, but actually you can also take you off track because it goes down their solution. Excuse me. The entry, the bar for entry, so the Hello World is completely virtual. I take it you don’t need hardware until you need to actually go and purchase hardware.

You can still do a lot with driving virtual boxes on virtual screens. That’s still valid, is it? Or is it really starting to get gnarly when you do start to get into the interfaces with physical hardware and drivers and sensors?

Mirek 08:50
It’s definitely valid, and there’s a bunch of things that come with this packaging. One of them is the way you describe the robot to your environment, which is something you need to do if you want to do some inverse kinematics, right?

Or if you have joints on the robot that move in a certain way, or if you’re just reading some sensor data and you want your robot to prevent from bumping into things, you need to have at least some scale of how big the robot is.

So the description in the ROS ecosystem happens in a format called urdf, universal robot descriptor file, which is an XML file that you use to pretty much describe your machine in terms of joints and frames of reference.

This is where my sensor is, and then this helps you to do the translation of that reference frame to where you actually want to have your information sort of projected. ROS also comes with a simulator engine, or two that I know of that are widely used.

So it helps you to sort of get things done faster than you would have to when you’re also iterating on hardware that sort of introduces even more complexity. But it helps you to keep things separate, and as you’re digging into this universe, you’re discovering topics that you didn’t know existed, but in ROS, it’s a whole separate sub -operating system, you might call it, the sub -system, yeah, there are separate initiatives that are, say, the control system, that you want to drive your robot, and so you need to translate your desired velocity into the model of the robot.

Say your robot has two wheels, one on each side, and some coaster wheel, that’s what the turtlebot is, that’s the simplest form that we use. So even that, you need to do some simple math to translate the velocity vector into speed of each individual motor.

So there’s a driver for that, and you don’t need to think about it, you just tell this particular node that your wheels are this diameter and this far apart, and then it does all that for you.

Mirek 11:19
But, you know, there’s not drivers for all geometries. You can have a legged robot and there’s a driver for that. Or you can have, you know, something slightly more of a balancing robot, right? But yeah, it doesn’t come optimized for your hardware.

That’s that sort of your job to do that.

AB 11:37
And we can see in the background of your screen, and we’ll have a link in the show notes, that’s actually a Rosbot, which is ironically and correctly named. That’s a small four -wheeled buggy, which is basically a lovely platform, excuse me, which is perfect for the Ros operating system, you know, entry -level pre -board to find, while it’s a step up from the turtle bot.

It also has a lovely hardware attachment at the top for all sorts of cameras, LIDAR sensors, a whole lot, which I can see you’ve pretty much pulled apart and you’ve got your own stack. Is that Rosbot, is that well -known, and that’s like described with plug -and -play files, and there are some plug -and -plays for other known robotic platforms, or is it pretty much everyone will be bespoke different and have to roll your own?

Mirek 12:33
So this is just one example of what you can get as the next step if you don’t want to build your hardware because it might be a little too much really. So you might want to get something, that’s what I did, just learn everything about it and take it from there.

It helps if you know a little bit of electronics and it definitely helps if you understand software and Linux because this is, you know, that’s most of what it is. There’s few machines like this, development kits that you can get.

This one was US$2700. It’s from this Polish company Husarian. This is their dev kit that you write your software for and then you can upgrade to their, you know, much bigger machine that’s ready for industrial use or you can just just customize the thing and build the next robot yourself because you’ve learned enough.

The internal workings when it comes to ROS tend to be pretty standardized but each machine is different and pretty much what each company does is this wiring. They either, you know, this comes with a lidar that is a product of another company that packages packages it with a ROS driver.

So that ROS driver comes included in this machine and it’s configured to, you know, work together. Everything’s wired properly both in terms of hardware and software but if you’re building your machine on ROS this is exactly what you what you need to do.

So it helps to start by following somebody else’s examples and best practices and maybe worst practices but it helps you to sort of get some sense of how this works because then you pretty much get some compute modules, some actuators, battery, you know, wireless module and you’re good to go when you can start building your own version of whatever you want to work on.

AB 14:35
Now this is open source completely. Is this any of the model of other open source software platforms where there’s the open source version and a premium supported version or this is purely community driven?

Mirek
This is all open source and it’s open source like I mentioned to an extent that you kind of expect it to read the code and write the code and modify the code.

AB
right okay so it the expectation is that you’ll actually give back your solutions back into the fold that probably I think you’ve actually mentioned it before a few minutes ago but that also means that the let’s say the variability of tutorials and code is pretty high is there a core set or are there some leading lights who you would almost always follow that some tutorials by certain users are just gold they’re the ones everyone flocks to or there’s just smatterings of goodness and badness across a wide variety of users

Mirek
There’s a bunch of good stuff on YouTube, definitely, and other places, I’m sure. It tends to be when it comes to long sessions of somebody showing you how to install a package and compile it with another package and, you know, all that…

Which some people may hear it. Yeah, so it’s little… You really need to take the time to sort of… absorb this kind of stuff. Because most of the time the person is just showing you their best practices and…

Oh man.

AB
Yeah. Now, winding all the way back to one of your first comments, this is a modular framework. Now, modular is obviously, you know, compared to the example of if you just need a gate moving or a latch or something, a Raspberry Pi has enough IO, enough inputs, outputs to be able to wire it up to many things and it can be used for things that get a bit more complex, but the ROS system implies modularity which is basically ready for upgrading your robot or switching out something for something else or is that modularity, obviously, that’s almost one of the central patterns, that’s one of the central things about it, that it’s supremely powerful, but you distribute that logic in so many places, that’s quite a large task to even just get started.

Is that the vibe that it takes a long time to get everything in alignment, but once you are, wow, you can really code fast or it’s always a sort of a slow step -by -step, a bit of a slog. Do you reach a plateau where suddenly all the doors are open, everything’s wired up, connected and suddenly you can just be coding and things magically happen beautifully or is it always a little bit of a shuffling and struggling.

Mirek 17:30
I’ve heard of companies who decided to not use ROS and the reason was that it’s just too difficult and they want to go fast and and this is just just too slow but I as as I dived into it I learned to and I came to believe that it actually helps you to separate tasks and you only really need maybe one strong ROS engineer or you know guru in your team and it helps to actually split tasks within you know in a group of developers okay and sort of isolate them and communicate in a sort of standardized way that’s you don’t have to invent your wheel there…

AB
This is the integration between other traders doing perhaps logic and sensing and drivers? This is the comms between all those modular units?

Mirek
Yeah and it goes even you know it touches things like coding style which is an issue when you collaborate with more people. So in ROS you can write code in C sharp sorry C++ and or Python these days and since your bits of functionality are isolated you can have a person writing Python code that then talks to something that’s in C++ and it’s not an issue and it runs on the same machine there’s even sorry I’m thinking of Docker now because I wanted to mention Docker.

Docker is you might it’s really hard to you might need to edit this

AB
That’s right. There’s a translation engine so that Python and C can live literally side by side.

Mirek
So you can have multiple people work in isolation on their respective tasks. And be sure that these bits will talk to each other. And a big help with this is Docker. It’s quite common in the Rust universe also.

Docker is this container engine that allows you to sort of isolate pieces of logic within its own environment, say in one Linux host machine. And you would achieve this with virtualization, but this is not, this performs much better if you’re not simulating, you know, virtualizing different kind of architectures.

So there’s a very little cost in terms of performance, but it allows you to ship your code in terms of these individually isolated building blocks that still talk to each other. And we can live on one piece of hardware, say, you know, one Raspberry Pi that drives a robot, or they can be distributed over this local network that consists your robot.

If you have one board that does video processing or some AI stuff, and another board that does your navigation, and you still want these to talk to each other, you can do this in Rust very easily. And that’s pretty much the biggest benefit of this kind of architecture.

And you definitely get a lot of overhead in terms of, you know, this wouldn’t have to be this crazy complicated from day one, but you will appreciate it if you iterate on your hardware, and then your robot’s brain isn’t on this huge number of things, spaghetti monster, it’s more like, you know, little spaghetti monsters and everything in principle talks to each other.

AB
Gotcha. Now to go the other extreme and asking a suggestive question, is Ross a bit too purist? Is it a little bit too over elegant or actually is it architecturally? Is it actually a perfect theory just the practice does kind of hurt a bit?

Are they doing lofty and correct goals and it’s just hard work to get there?

Mirek
Yeah, I’ve been thinking about it a lot, and I don’t know, I think that there’s definitely some cost in that complexity, but also I think on this level, being this close to metal, I think is justified.

Coming into this ecosystem, you’ll read about how Ross should run on anything, and then it doesn’t. Or it should work with any Linux distro, and then it doesn’t, and it’s just complicated. But that’s not the point.

That’s not the point. Just grab the best example you can get and follow those recommendations. It’s not one product that would come in a box. It’s this amorphous blob of useful tools. I think there’s this complexity, and also there are some, I would say, like you might

AB 23:19
But that tension between purest, elegant, beautiful theory, and gnarly, painful, but it feels good at the end. Is that the intent of the ROS core coders? To keep you on a good track, even though this pain is actually worthwhile, there’s no other ways I know of apart from, and I’ll go dead simple, the Lego operating system for playing with robotics.

Beyond toys, you actually do need some level of rigor. This feels like the first step of hammering that rigor into you is well worth it, asterisk. But gee, it hurts.

Mirek
I don’t think it’s purist versus not purist. I think it’s just what it is, given where we are, with Rust development in time. And most tools, and that was quite shocking to me, that come in this ecosystem, are very difficult to use, like way more difficult.

And that’s a different thing from this whole concept, or architecture of Rust. And there’s tools that come with it. And most of the time, your mileage will vary. And I think that can improve. And better tools can give you better insight in what’s happening in your system.

And all this pain of, like I keep mentioning that in theory, Rust should run on anything. It kind of does, but it kind of doesn’t. So if I’m moving to the industry, do I need to drop everything and start working on Ubuntu Linux, because that’s what it runs on.

Or maybe you don’t have to. We just need slightly different tools, and it’s going to be much less painful. Anyway, I’m rumbling.

AB
All good. Easy question for you. A softball and a way to be cathartic if I need to for you. How are you using ROS now? What’s been your journey and your struggle and your end goal? Is the end in sight?

I know you’re hesitant to even talk about ROS because I’m not a master. Well, that’s perfectly fine. Everyone stands on the shoulders of giants and we’re going to pick on your shoulders now to give us that first lift too.

But yeah, your journey, what’s your goal for ROS and how far are you? Is there a completion or is there always one more thing to be done?

Mirek 25:55
Oh, there’s many things to be done, but there’s also some light at the end of the tunnel. So I came into this by looking at how I can interact with robots using augmented reality, which means seeing all sorts of data, producing all sorts of data, sort of communicating with the machine in some standardized way.

And so how do you do that? I can’t plug my tool into just anything. It needs to be some communication protocol. So I chose ROS because, like you mentioned in the beginning, it’s pretty much an industry standard, but there’s plenty of good reasons for not using it.

But if you’re trying to cover as much of the industry as possible with something that you just want to plug into a machine, no matter what the machine does, that’s why I chose ROS. And it works with robotic arms as well as self -driving delivery bots and drones and all sorts of things.

So also, it covers a really colorful variety of machines, but the underlying principles are kind of the same. And the code you can often also reuse. And once you understand how to do this particular thing, then doing something slightly different on a different machine is just a little bit different.

It’s not, you know, you’re not starting from scratch. Yeah, gotcha, gotcha. And yeah, my first idea was that I would just take this messaging system that ROS is and connect it to a headset. But that turned out to be rather difficult.

That was the first six months. Oh, yeah, well, yeah, it took a while. Because ROS can run on various machines, but the discovery of the nodes is kind of… I mean, it happens, it does it automatically, but you don’t want to do that on a public network, which is where you are when you’re, you know, connected to a Wi-Fi and your robot’s connected to a Wi-Fi.

Mirek 28:12
You don’t want to just publicly stream everything and open your robot to just anything. And also, what I’ve encountered is that just using the network protocols that people use on local networks doesn’t really use when you want to, you know, talk to some other system that is not necessarily part of your robot.

So what I’ve done is I’ve made this ROS node that sits on your robot and provides this streaming capability via WebRTC, which is what we’re using to stream video and audio. It can also stream data and it does it using UDP.

Which means you’re purposefully losing packets in favor of speed. And you can stream video, you can stream data. And what I’m doing also is, you know, pre sort of optimizing the data before I send it to you.

And it works both ways. It can also receive packages real fast. So I’m driving the robot remotely using the very same system. It’s going to be a product. I think it helps people to even… Like I mentioned it, I’m pretty much building what wasn’t there.

So there’s a bunch of features that help you understand the data flows within a complicated system like this. You can see the nodes and what data they produce. You can subscribe to each channel and see what’s going on.

You can have, you know, data visualized. If you have LiDAR streaming or some data, you can see in real time what that’s producing and, you know, mesh it with other data and drive your robots remotely.

How cool is that?

AB 29:59
very cool. That’s something we definitely would love to follow up on. We might need to do a YouTube only episode where we actually get a working demo and is this the kind of thing that, you know, drive the Smithsonian robotic arm from a distance kind of thing or are those more hard coded and bespoke?

This is a kind of an over the air internet is handy, but I’d say that networking and the security protocols would be coming into play somewhere about now.

Mirek
Oh, yeah. Well, security is one thing I’m leaving for later. Then there was. No, no, no, it’s pretty secure. But yeah, it’s pretty universal. Like you can drive a robot on wheels or you could in theory drive an arm with that.

You know, it’s sort of I’ve been using this tool. I don’t want to brag about it right now because it’s like I’d rather present it when it’s when it’s done easy. But it’s a pretty universal tool that sort of takes rows for what it is and sort of takes the scope of it and builds on top of that and, you know, add some features like the interface that you can connect Bluetooth, connect controller to and then drive your robot without doing anything to the robot itself.

Like it’s it’s that compatible with this whole ecosystem.

AB 31:28
I take it scale is possible because of this. We’re talking swarms, we’re talking streams, we’re talking masses of robots is doable or that actually has to be coded, networked and organised and optimised when you get into beyond one or two.

Is that a built -in factor of the ROS system that it natively can handle any number or that is another decision that you have to do some work over the top of?

Mirek
You need to do that separately, if you want any kind of swarm behavior. Because there was pretty much deals with your hardware. And this high level logic is, you know, if it’s going from navigation, if it’s coming from some state machine, is there, if it’s coming from yet some other place, you might want to stream it via web RTC, maybe into the machine.

Like you would, like you would.

AB
The concept of a ROS module that is the brain, that is the central logic unit, or that itself is your own code elsewhere that just connects into ROS, is that you get it into a module? I would consider.

Mirek
like philosophically this whole thing to be the robot’s brain.

AB
Yeah. You were not going to grab out the scalpel. But yeah, gotcha. So there’s no direct module ready for this is the place where everything comes to you. It’s just a stateless modular framework of comms.

And then you can join them in any which way you want. And many people would join them in ways that might have similar patterns like you you’ve you’ve been saying you’ve got the module that is your central hub, which obviously then is probably the place where you’d want to then bounce in your heads up displays, your augmented reality overlays and data back and forth and controlling back and forth.

That’s where the human would sit in that particular loop.

Mirek 33:26
I mean, your central brain could be a simple Python program that sort of takes into account what’s going on and on some simple level decides what needs to happen, or even it could be a distributed thing.

You can have a robot that sort of, I don’t know, has wheels and an arm, and at some point, you may want to switch control, you may want to switch control.

AB
go there yeah gotcha so it can you can go down the hierarchy and figure out yeah there’s not one

Mirek
the same time and sort of, you know, taking into account what’s going on in a different place and…

AB
Now, when you said that some companies actually take a good hard look at ROS and then decide in Australian terminology, ‘yeah-nah’, and just no bad of that, if they’re building their own thing or if they’re choosing a different thing, are there?

We can name names and we can throw links in the show notes. Are there commercial ROS -like operating systems out there or is it just if you want your own thing, it’s because you’ve got your own hardware, you just do bare metal logic, like you bind the software to the hardware.

All this elegance, purity of modular and making it extensible is lovely, but if you know what hardware you’ve got, you just code for that hardware. Is that the delineation that some of the commercial companies are making or are they running to another platform or platform?

Mirek 34:54
Sometimes you choose hardware because of the software it comes with in this world. And I think the most prevalent other solution would be to just write it from scratch and use whatever libraries you can position them and just put things together as you go.

AB
So it’s a traditional software project, based on range of hardware. Gotcha. And companies make that choice based on how bespoke they’re going to be, the strength of their software teams. But then on the flip side, a solo developer like yourself or small teams or people who know they’re gonna be iterating, that’s where ROS really starts to shine.

Mirek
I think it’s worth it to go that route and I think people don’t do it quite often. I’m not arguing for Ross, I totally feel like that it’s overwhelming and I’m still overwhelmed and I’ve been for a while, but quite often what happens is that you’re dealing with a problem that, you know, is, I don’t know, as simple as differential driving, right?

A robot with two wheels, whatever, and you need to figure it out. You go to Wikipedia and you study the math and, you know, then produce an algorithm while it’s been sitting there on, and it’s been done in the Ross, you know, history forever.

So this can get much more complicated, like when you start dealing with navigation and autonomy and, you know, all sorts of computer vision topics, then you simply can’t reinvent everything that you can’t start from scratch.

It’s just too much. So I believe what’s often the issue with Ross is that it’s just so overwhelming that people don’t have the patience. And then, you know, when you kind of know what you’re doing with your product, you come back and, you know, maybe you rewrite everything you have because most of it is done somewhere else and you just need to reorganize your code and configure a bunch of other stuff.

AB 37:07
It’s that age -old question of if something is off the shelf, even Ros or not, what benefit is it giving me? If it gives you 80 -90% for free and just the last 20% is your own blood, sweat and tears, that’s a victory.

That’s great. But if you get only 10% for free and the rest is your blood, sweat and tears, that 10% head start might actually cost you in time and effort to refactor and comment out and sort through.

So trying to find that inflection point where it’s going to give you enough of a naught and a head start once you overcome that steep learning curve versus is there a … I love the fact that there’s the hello world, the virtual tutorials, which is really good, means you can just walk up to it, download it, install it.

That sounds like that’s a good evening anyway. But get started without buying hardware. But is there a logical next step? Is there then the number two thing, the hello world two that people tend to do, the Rosbot, the physical track, the four -wheel buggy there in the background, or is this pretty much the thing that a university academic might do that I have built my own robot, I don’t want to do the software, I’ll only spend 50 evenings trying to figure out the Ros operating software so that then I can bolt on the software to what really is my thing, which is the hardware.

Is it the go -to default operating system if you’re a hardware specialist versus is it a software tool for software people who happen to be into hardware?

Mirek 38:44
oh that’s very philosophical i know sorry sorry is it good

AB
It seems to me it’s the correct software tool for most applications and it solves people’s hardware problems when inevitably the hardware gets better every alternate year and you change your mind and you get a better this and a bigger that.

Mirek
Here we’re kind of in the process of integrating hardware and software together, so it’s on you really, if you’re in robotics I assume you want to build some hardware or maybe write software for robotics and in both cases I think it’s useful to go the the ROS way simply because other people who know ROS and spend the time can help you with that.

It becomes even simpler, easier to work on more complex projects. I don’t think it’s just an academic thing, it started as that, but it has a real -world benefit for a practical engineer.

AB
Yeah, definitely can’t end this episode without getting your thoughts on the amazing bit of video that happened, yeah, probably about two weeks ago now. Well, it actually happened over, of course, about three days.

AB 40:18
Boston Dynamics released a video saying that Atlas was retiring. That is the one that does all the yoga, the dancing. It’s the humanoid size and shape robot built on hydraulics. Phenomenal. Its progress from DARPA four legged into, or granted that was spot, but watching the progress of these robots over many years.

And ironically, about two days after they said we’re announcing the retirement of our Atlas robot, hey, we’re going to show you the first demo of our new Atlas robot. Love your thoughts on the electric motor version 360 degree bending Pixar face looking like robot.

Mirek
I love the design and I love the presentation. I think they did that. You’re referring to when the robot stands up. Stands up / pivots the hips differently to the head and yeah the whole torso rotates.

Mirek
I see how some people could be disturbed by that. I love it. I don’t think that you know robots need to look exactly like a puny human. So that’s exactly what they’re doing. They just want to be like this little…

Yeah, showing off its strengths immediately. Just a little bit unsettling. But I love the design.

AB
Are they, does Boston Dynamics use ROS anywhere in their stack?

Mirek 41:51
Absolutely. And I mentioned URDF, you know, it’s the description of the model. You can get all of that from Boston Dynamics for free and use it in your simulations. And then, you know, just get the hardware if you so desire.

Oh, right.

ABsure just yeah let it be known that a project that we were both working on I did get a price list for spot dogs with all the trimmings from Boston Dynamics sadly it was had a few extra zero or zero that was a bit too much but that’s okay it’s the same

Mirek
with the with the cheaper dogs with unitary also runs Ross about their little particular about their license policies so they don’t want to open everything to you unless you pay them more than what you expected okay it’s Ross it’s Ross underneath last

AB
gotcha customized or just with some proprietary or just under a layer of protection so that you can’t directly tinker.

Mirek
It’s all kind of customized, like never, never ends up in a product as you would just download something from the internet, you know. Gotcha. Yeah. Gotcha.

AB 42:59
this is the framework versus, as you said at the very start, it’s called an operating system, but it’s not what anyone would actually call an operating system if they had the chance. In fact, ROS with the OS at the end, I think more people would also just think about as being the OS standing for open source.

So it maybe is like a recursive. Isn’t PHP stand for the PHP hypertext protocol, which is a recursive acronym? ROS is more known for being open source than, I guess, an operating system. But an ad or a one -liner for what you’ve been working on for many years, you are actually working on, and I’ll call it always, an operating system, a way for a human to walk up to a robot and, hey, you go here, do this, that kind of thing.

That’s more the mouse point click folder system that we know and love of our current systems.

Mirek 43:50
Yeah, but even that, you know, can be only so abstract. Thank you.

AB
Gotcha. It has to hit the ground at some point. It has to reach out to reality at some point. Yeah. No, I love it. Meric, thank you. Great intro. There are people who probably have taken a look and turned away.

I know I have not needed to get into it, but I’ve delved around the edges enough to know that that’s for a cold long weekend in the middle of winter. Actually, I tend to do a, in this part of the world, the Tour de France goes for three weeks in the middle of winter.

Perfect for doing a few coding projects on the couch while you’re half watching the cycling race and watching everyone else in high summer. It has been on my radar to do one day, but I must say there’s never been a hardware project.

But I love the fact that it can start with completely virtual in the simulators. And that’s enough without having to spend big dollars on big hardware batteries, motors, a whole lot. So I must say I might actually open up one of those VMs, spend the evening downloading it, configuring it and see if I can get a turtle to walk across the screen, he says, as I have a turtle behind me making noise.

It’s something that’s on my radar, but it is something that I think a lot of people have had on their radar, had a look at like me and decided, oh, that’s not for me. So as I said, great to have a set of tutorials that is there for starters.

I’d love to take you up on the offer one day of actually exploring your code, running through your hello world in your scenario. Sure. When your code is full of less expletives and more comments and, you know, the demo is guaranteed to run rather than fingers crossed and hope for the best.

That’s cool. That’d be great. All good. All good. Also really for anyone coming up, learning students, programmers who are wanting to get into the field by the sound of it, it is the industry standard by which others are compared in that regard.

AB 45:51
As a de facto standard, it’s good to know, even if you don’t have any illusions of I want to be in it forever, like most software tools that are predominant, you want to have assessed them to kind of get a feel for how hard it is, where some strengths are.

So even if you are completely passive and you just watch many of those, we’ll put some links here in the show notes. Just absorbing things is actually a great start. It’s good to get over that first hump as fast as possible, even if your fingers don’t start typing brand new code.

Just absorb where it can shine and where it’s a little bit less adequate where that line is between Raspberry Pi and Ros. Parting thoughts. I take it the community of Ros is very strong, but highly variable.

There’s a lot of there’s back channels, there’s discords, there’s forums, there’s the whole kit. There’s always someone up who’s having the same problem as you. Is that always an option?

Mirek 46:56
Most likely, yes, and people are very helpful and friendly, which is not so common on the other parts of the internet, but it’s very no -nonsense and, like, you know… Brilliant.

AB
helpful community. Having a positive start is good when the software hurts your brain anyway. It starts to have real people who can help you. I take it their help stops at a certain line because it’s like, I don’t know what you’re trying to do, but I think you’ve probably got some problems in this area.

It’s probably always nonspecific advice. It’s general advice. Is that the normal trend? or people can actually read your code verbatim and give you some better guidance.

Mirek 47:45
Nobody’s gonna read thousands and thousands of lines of your code, like don’t expect that, but if you can describe your problem, people will help you and point you in the right direction. And yeah, I wouldn’t be afraid to ask because it can be overwhelming and most of the people who are, you know, part of the community went through the same process and know how overwhelming it is.

AB
seat exactly apart from what’s the is there a core who does the development or as you say you’re expected to push back and pass a bit code to the to the next releases is it by all means I love the alphabetized release versions is it seriously progressive or is it regular cadence is it a little bit leading edge bleeding edge what’s the actual code release

Mirek
All the time, but only now and every now and then it gets packaged to a distribution it’s like pretty pretty similar to your the next distribution cycles and It’s pretty much the same process in how the code comes together So you can contribute with your own code It’s not gonna be probably Retractively applied to the whole history of Rust because there is a lot of history There’s different versions that sometimes work together sometimes don’t specific breaks

AB
you need to push forward and never go back if that’s the case. Yeah, yeah.

Mirek
There’s an organization that sort of maintains the code base and you can read all about that and be part of that. But that’s where you seek help also is these community forums and you know, people sometimes get paid for their work, sometimes they don’t and they just engineer like you trying to figure something out.

AB 49:38
Thank you for letting us stand on the shoulder of the giant that is you, so thank you for that. Great to get the brain dump. I really do wish we ever had the matrix style injection of everything we need to know by what the technology was, cartridge I think it was, and it looked like a zip disk back in the day, probably was.

Until then, it really is getting those insights is quite invaluable, so thank you for that. Struggle on, power on, we definitely look forward to some serious demos and look forward to an update on how the operating system over the top of the operating system is going.

We’ll definitely hold you to a workable demo whenever you’re all ready for it, but I know you’ve been in the weeds of this for a fairly long time, so it’s great to hear that there are some lights in the tunnel and it’s not just, what is it, the freight train about to hit you, so well done for punching through.

Mirek
Yeah, we’ll definitely do that.

AB
Well, thank you all. Cheers for that. We’ll leave it there for episode 18. Say this is beyond all channels. You’re either listening, watching or reading. Transcript has always been a bit funky. And now there’s…

Ooh, in fact, the podcast channels are offering their own transcripts. So we’ll let the competing AIs figure out what we’re saying. Good, clean fun. Thanks for that. We’ll catch you on the next episode of Spatial.

But for now, bye -bye. Bye.

HOSTS

AB – Andrew Ballard
Spatial AI Specialist at Leidos.
Robotics & AI defence research.
Creator of SPAITIAL

Mirek Burkon
CEO at Phantom Cybernetics.
Creator of Augmented Robotality AR-OS.
 

_{To absent friends.}