Talk Python to Me, episode number seven, with guest Dirk Thomas, recorded Monday, April 27th, 2015.
Hello and welcome to Talk Python to Me, a weekly podcast on Python.
The language, the libraries, the ecosystem, and the personalities.
This is your host, Michael Kennedy.
Follow me on Twitter where I'm @mkennedy and keep up with the show and listen to past episodes at talkpythontome.com.
This episode, we'll be talking to Dirk Thomas about the robot operating system ROS and ROSPi.
Before we get to Dirk, I have a couple of news items.
Top of the queue is a huge show announcement.
We have our first long-term sponsor of the show.
I'm happy to tell you that Codeship is now the premier sponsor of Talk Python.
Codeship is a platform for powerful continuous integration and continuous delivery as a service.
I'll talk more about them later in the show, but please take a moment and check them out at codeship.com
or follow them on Twitter where they're at codeship, C-O-D-E-S-H-I-P.
And if you love this podcast, please send Codeship a message to say thank you.
Jump on Twitter and say something like,
Thank you, at Codeship, for sponsoring the Talk Python podcast.
You rock!
Or however you want to say it.
Next up, timestamps.
Several listeners have asked for something like an outline with timestamps so they can go back into the show and look up topics.
It's a great idea, but I'm taking that to the next level.
I intend to have full-text, searchable transcripts for the shows, which of course include timestamps.
Only a couple of shows have transcripts so far, and I'm adding them as fast as I can.
Check out episode number four on Enterprise Python or episode number five on SQLAlchemy
and click the full transcript button to the right to see what I'm talking about.
I think you'll find it really useful.
Special thanks to Mark Weimer for recommending a show on RossPi.
We probably wouldn't have this show that you're listening to right now without you, Mark, so thanks a bunch.
There are comments everywhere.
I've added a comment section to every show on our site.
So now, in addition to using @talkpython on Twitter or just emailing us,
you can send us feedback via the Discus comment area at the bottom of each show,
and I've already received some great comments that way.
Finally, I have created a Twitter list aggregating all the tweets from all the guests who have been on our show.
Visit Talk Python on Twitter, choose the View Lists option, and subscribe to the show underscore guest list.
There you'll find the Twitter stream from all the guests who have been on the show, and of course, that list will be growing over time.
You can also find the link to the list on our homepage.
Wow, what a week.
Now, let's get on to the interview with Dirk Thomas.
Hello, Dirk.
Welcome to the show.
Thank you for having me.
Yeah, I'm really excited to have you as a guest.
We've had some what I would consider mainstream developer topics so far, and we have more coming up.
Of course, they're mainstream, so we'll probably have a lot of them throughout the show.
But I'm thinking of things like web frameworks, data access libraries, Pyramid.
We're going to do a show on Flask.
A show on SQLAlchemy is coming out pretty soon.
And what we're going to talk about today is a little bit different.
It's a little more edgy, and I think it's something that so many people that go into software development,
maybe it's the reason they got into software, and then they got drug over to the financial section
where they're building reports out of databases or something like that, which is robotics.
Yeah, that's a very great project because robotics in general is, I think, more interesting than classic software engineering
because it's just much more hands-on, and you have real results which you can try
instead of the big business projects.
Absolutely.
And I think one of the things that is sort of representative of that is I do a lot of work with schools and training.
I do professional training for real developers, but I also help my kids' schools out with after-school projects and stuff,
and they very rarely want to write a financial trading system.
They're more like, how do we build a robot?
How do we build a game?
And so you're really involved with this thing called ROS, the Robotic Operating System,
and we're going to talk about that for this show.
Before we get to it, though, I think the listeners are really interested to hear
kind of how everyone who's gotten to some really cool place contributed to some great project.
Well, how did you get started?
What's your background?
How did you get into Python?
So basically my background is I started computer science at the university
because I liked computer.
I liked programming.
Of course, I liked games at that time.
So I thought computer science, that's like a nice thing to do.
And at the university, you learn a lot about languages and algorithms
and a lot of like technical background.
But we also had projects at the university which were more hands-on.
And one of the big ones was RoboCup where you play like soccer with the robot.
And you try to make the robot play soccer on its own.
So you're not like steering him with a joystick but make him like autonomous.
And that was a really interesting project.
And that's how I got into robotics in the first place.
And what languages did you use to teach the robot to be autonomous?
Yeah.
So usually a lot of things in robotics, if they're like the algorithms which do like C objects in the camera and make decisions,
a lot of those things are like in C++ classically.
Of course.
But C++ is like a good language for doing like the lower level languages where you need a lot of libraries
which are only available in that language potentially.
Or you need like things which need to be really fast.
But for other things, when you do like put things together, like the glue making the overall system work,
that might not even require like really fast code or something.
And then something like Python comes in more handy because you're just much more efficient in writing code and putting things together.
Right.
It's more about understanding what you build than it is building, you know, shaving that millisecond or microsecond off there.
Exactly.
Yeah.
Especially if you think about like user interfaces or when you start the robot to determine which parts to start and how to configure them.
Those are not time critical.
So you want to be like as fast as possible developing them.
And it doesn't need to be like that fast at runtime.
Perfect.
So you started working on these robotics projects.
And they were in C++.
And somewhere along the way, you're like, all right, enough C++, Python.
Where did that happen?
Yeah, that was actually an interesting project.
We had like a graphical user interface to like do all the controlling of the robot and look into the state of the robot to see what it's currently doing and changing like plans.
And we started because the rest of the software was in C++.
We're all familiar with it.
So we started with C++, of course.
And then we figured out that like for a graphical user interface, you want to be really fast and developing new things to interact with the robot.
And I tried to like look at different languages.
And with some coworkers, we looked into Python.
And I tried first, actually, a C++ user interface, which was able to run like parts of it in Python.
So that was my first contact with Python.
Very nice.
So maybe you could give us a little bit of an overview of what the robotics, the sort of where Python is being used throughout the robotics industry.
Oh, yeah.
So especially in the robot operating system, which we work on at the Open Source Robotic Foundation, it is usually like twofold that you have a lot of code in C++ on one hand.
And on the other side, you have a lot of code in Python.
And usually you decide like which one is better for the part of the work you're doing.
And while there are many language bindings for different languages, those are the two common ones.
And Python especially is used for, for example, writing command line tools because they are very easy to write.
They are really fast to develop.
And you don't need like features which are specific to C++ at that point.
And also on the user interfaces, a lot of user interfaces are mostly based on Python.
Sometimes you use some C libraries if you need to access some other libraries which are not available in Python.
But, yeah, all those kinds of like glue code to put things together to make a bigger system, those are usually relying on Python in our cases.
Sure, that makes perfect sense.
Like when you're down talking to the serial port or the hardware interrupt, maybe Python is not the right choice.
But once you have that in place, you do the higher level logic, the sort of orchestration with Python, right?
That's actually a really interesting problem.
If you think about like serial communication, you would think like serial communication, very low level.
Like C, C++ is the most fitting language for that.
Sure.
But if you try like implementing a little communication over USB or like a serial link, actually in C++ that gets really tedious.
It's like a lot of work, a lot of cases to consider, and you have to do a lot manually.
Python is really well suited for that because you're not dealing with a lot of data because serial is usually like low bandwidth.
And the latency is also usually not an issue.
So actually writing data to a serial port or reading from a serial port, I probably would choose Python for that.
That's really interesting.
I wouldn't have guessed that, but I guess it makes sense.
That's cool.
So you're associated with the ROS project, the robotic operating system at ROS.org, ROS.org.
Maybe we should talk about that for a little while.
Yeah.
So when I first started at the university, we were just working on our own little software, you know, like you want to develop it yourself to learn.
But in the near future, we noticed that, well, it just is better to reuse something which already exists.
And the robot operating system has been started like seven years ago at Willow Garage.
And they developed it for a very huge humanoid-like robot.
It's like a robot on a mobile platform with two very complex arms and a head with like different camera systems.
And ROS was basically just the outcome of trying to use this robot and make it usable for different researchers.
So it was not the first goal to develop the software, but first they developed the robot, and then they developed the software for the robot, basically.
That's interesting.
So it was almost, you know, extracted from the construction of the robot and the needs that they had.
Yes.
So basically, that was the first application.
And seven years later, we still have like things in the software which are like basically designed and evolved based on that robot.
So later on, more robots came into the game, and we tried to support more of them and different variety of things.
But you see a lot of design decisions in the system are just based because they were like developed for that first robot.
So you're also working on this thing called ROSPi, which is part of the ROSCon or communication project on GitHub.
What's the relationship between those two?
So basically, ROSPi is like many things at the same time.
On the one hand, you have the communication system, which provides you like communication patterns like publish, subscribe, or service response, which are very common ways to communicate between components.
This is like the low-level like communication functionality of ROS.
But then there is like, and ROSPi is one of those.
So ROSPi is basically the Python implementation of this communication primitives.
But ROS provides more than just the bare communication.
There's on the one hand a lot of tooling.
So you have a lot of tools to help you develop software for robots.
You can introspect the state of a robot.
You can change things at one time.
Additionally, besides these tools, you have a lot of visualization.
Developers around the world write applications and functional components, capabilities, for example, to make a robot be able to navigate, make a robot be able to recognize objects with a camera.
Excellent.
So there's like a simulator or something.
Is that right?
Oh, yeah.
There's also the option for a simulator.
You can actually use different ones.
But one of the most common ones is Gazebo, which is used to try your software with a simulated robot before you actually run it on the real robot.
Okay.
So could I actually build and have a virtual robot before I even touch a piece of hardware and then decide, okay, now I'm ready to go in and actually get the hardware?
Yeah, absolutely.
And that's the big advantage because you don't want to spend the cost of the hardware first.
And then you figure out, oh, well, that's actually not good for a certain use case.
So you want to try that out before.
So the simulation allows you to rapidly prototype a certain design of your robot and iterate on that one.
You can make it run the same kind of code to drive around and pick up objects.
And if you're not happy with the geometry of your robot, you can change it and iterate on it over time.
And when you're happy with it, you actually go to the hardware.
Now let me take a minute and tell you about our sponsor for the show, CodeChip.
CodeChip is a hosted continuous delivery service focused on speed, security, and customizability.
You can set up continuous integration in a matter of seconds and automatically deploy when your tests have passed.
CodeChip supports your GitHub and Bitbucket projects.
You can get started with CodeChip's free plan today.
Should you decide to go with a premium plan, Talk Python listeners can save 20% off any plan for the next three months by using the code TALKPYTHON.
That's T-A-L-K-P-Y-T-H-O-N, all caps, no spaces.
Thanks to CodeChip for sponsoring the show, and I encourage you to check them out right now at CodeChip.com and thank them on Twitter where they're at CodeChip.
So you mentioned some other tools.
Like when I was looking through the project, I noticed there's one called RViz and one called RQT.
Oh, yeah.
So these are the two most commonly used user interfaces to interact and look into a robot and control it.
RViz is the older software.
It's like the more mature one.
It has more features.
It provides you basically with a 3D scene of the environment, and your robot can move in this 3D scene.
So you have a CAD model, for example, which you can import as like a mesh of the robot.
And the robot can actually drive through an environment which you can render.
And, for example, if you see a camera image from the robot's head, it can project this image into the scene as the robot sees it.
So it's very, very good for the user to get a feel what the robot currently sees and what his information about his world is.
That's really cool.
So it's like a 3D environment, and it basically sets the viewport of the 3D simulator to be where the camera would be?
Exactly.
And you can actually put multiple viewports in there where you have multiple views on the same scene.
Or you can render all the sensor information the robot has.
So if he has a laser in the base, you can render the laser scan itself, and you see how good does it fit with the walls where they actually are.
And you can, for example, render a path where the robot plans to go next.
It's very good for you to get a sense of why the robot is doing something, because the more complex it gets, the more difficult it is for the developer to follow what's actually going on in the system.
Yeah, and you said there's some debugging capabilities that can let you capture those messages and that data flowing in and replay it and stuff, right?
Yeah, so that's another feature for us in general, that since you try to decouple your logic into different components which communicate over messages,
you can record all those messages and later look at them or play them back.
And that helps to figure out problems which happened on a robot like yesterday.
But if you have the information written down to the log file, you can actually introspect the problem from yesterday and actually try to reproduce it, for example, in simulation.
And that helps you, like, actually fixing things which are really hard to debug otherwise.
Yeah, it sounds like it'd be really hard to set a breakpoint on, like, a live robot moving around.
But maybe you could do that on the simulator if it was, you know, getting the same sort of inputs or something, right?
Exactly.
With a simulator, you're able to reproduce it.
And you're not even able to do a breakpoint, actually pause the simulator and then change something in the debugging code and continue.
But you're actually able to, like, change your code and run it against the same laser information, for example.
And you can ensure that now with your changes, it's fixed.
With a live system, you have a hard time doing that.
Yeah, the reproducibility part of it sounds really hard.
So that's fantastic.
Yeah.
And the second part you asked about, that was RQT.
It's basically a different approach than Arvis.
So they are both, like, serving a little bit different needs.
And RQT is where a lot of Python comes in, actually.
Because Arvis is mostly based in C++.
It has some ability to run Python plugins.
And RQT is the other way around.
RQT is like a Python application, which has the option to run, like, C++ plugins if you really need, like, the logic, the power of C++.
And RQT is not built around, like, a 3D environment.
It's more like a, I would say, like a development environment where you can add different things.
So we have plugins which visualize, for example, just single numeric values over time, like a function, like a controller or a distance to an object.
Or you can visualize images just as a plain 2D image.
And you can look into all the communication which is going on.
So it's more like a kind of tool set the developer can use to look into certain things and have that all in one powerful environment.
Very nice.
So Arvis is kind of the simulation bit.
And RQT is more like setting it up and debugging it, maybe.
Yeah, almost.
The Arvis thing, though, does not do real simulation.
It only shows you the current 3D state.
It does not, it doesn't do, like, physics-based simulation or something.
That would be, like, a similar external tool then.
Right.
Okay.
Fantastic.
You know, mostly I touch computers through software.
So the hardware parts are a little unknown to me.
Like, if I've got servos and hydraulics and stuff, like, what do I put together to put ROS on?
Do I have, like, an embedded Linux in my robot?
Does it run on other types of things?
Where do I install the robot operation system?
It completely depends on the use case.
There's such a variety.
For example, the PR2 robot from Willow Garage I mentioned earlier is, like, this huge robot.
It has, like, two I7 multicore machines.
It's, like, a heavy beast, I would say.
It does a lot of things, but it's, like, it's very powerful.
On the other end, you have, like, really small, like, Adreno-based ones or Raspberry Pi-based computers, which just have a connector to, like, motors or sensors.
And that's totally enough to do, like, smaller projects.
So it all depends on your use case.
And some of the microcontrollers, depending on what you use, very common is the Linux version, the Linux distribution Ubuntu.
But people have run it on various different other systems.
So we are very flexible in that term.
That's really cool.
There's a lot of functionality here.
Is this something I would consider using for, like, a toy, or is it only really for, like, professional use, or is it kind of more general?
Would it make sense in a lot of places?
So that's actually the difficulty of the project, I would say, since it's an open-source project and many people contribute to it.
You have a large variety of people trying to use the system.
So on the one hand, we have the hobbyist who tries to, like, just put his, like, Raspberry Pi and a couple of motors and sensors into a small robot, like a toy,
which just, as, like, kids or teenagers, just trying to, like, make it, like, drive around, avoid obstacles, and that's, like, a great project.
And on the other hand, you have developers which really use that on, like, product-level, like, robots, which are, like, car-sized robots,
which drive around, for example, on a field for farming.
And they have to drive reliable.
They have to drive autonomously.
They have to be, like, if something goes wrong, they have to, like, have fail-safes.
So you have the whole spectrum of, like, kind of users which use the system.
Wow.
I suspect that presents some design challenges architecturally in the software, right?
Like, on one hand, you want to make it so kids can, like, build little fun robots.
But the requirements for a real thing that could run someone over, those are different.
So what's the tension like there?
Oh, the tension is definitely that it's really difficult to, like, satisfy, like, everybody in the community.
So you have, like, very different demands in terms of, like, the people who want, like, that for a hobby project.
They want a very lower entry barrier.
They want, like, really easy tutorials.
A lot of people are not software engineers which, like, look at those things and try to build, like, their small robot at home.
They're, like, eventually mechanical engineers or probably even not that, but might be teenagers just trying to play with it, right?
So it's really difficult to bridge that whole area of users.
And I would say there are a lot of design challenges.
So one example is when it was originally developed for the PR2, it was meant for, like, researchers, for, like, developers who knew, like, what they tried to achieve.
And if it didn't work, it was fine to just, like, restart, right?
So if the experiment didn't work, you just, like, control C everything and restart, restart the camera for the video for your presentation.
And you try again.
That was totally feasible at that time.
But if you have a robot, for example, Ross also runs on the Robonaut 2, which is on the ISS space station.
That's amazing.
So at that point, you probably have a harder time, like, retrying things over and over.
You want some kind of deterministic behavior.
And these are still things where Ross needs to improve in the future.
So we're always working on, like, making it more suitable for, like, production-level software that you can actually rely on it and can sell the product and don't have to worry about it ever going wrong.
But that's definitely an ongoing effort to make it more solid in these domains.
That's really cool.
I'm sure it's a challenge, but it probably also makes it a better thing in the end.
Oh, yeah.
I mean, the more use cases your software has, the more flexible it gets.
We often get, like, you know, a totally different operating system, which we don't even have in our office.
We can't even test it.
So we rely on external people, which use it on their systems to contribute back and make it more usable in different scenarios.
Wow, that's amazing.
So maybe we should talk a little bit about the core components.
Like, what is Ross meta before we talk about more how PyOnton's working there?
Yeah, so the core components for the communication.
So first of all, the system encourages the developer to split functional components in separate pieces.
So if you think about something which, a component which reads the camera image, and then a component which extracts from the camera image a certain feature where it wants to drive to,
and then the actual planning where to drive to, and then the component which talks to the motors and actually maps the drive command to a real action in the world.
And the system tries to, like, keep those things separate.
And this abstraction on the first level allows the developer later to swap out a certain thing with a new implementation and try them out.
And that's where all this communication infrastructure comes in, that every component talks to other components by exchanging messages.
It's like a data-centric approach.
Right, and these are asynchronous messages.
You kick them off, and then eventually maybe a new message comes back for you or something like that.
Yeah, so most of the times they are asynchronous.
There are times when you can do synchronous request response and you wait for the answer.
But this is something you usually want to avoid because maybe the answer comes in, like, two minutes.
That's probably not how long you want to wait.
So writing your code in an asynchronous fashion is usually the preferred style, yes.
Excellent, and Ross really encourages that with its APIs and so on, right?
Yes, so if you look at the PR2 robot,
it runs, I think, roughly 150 processes in parallel, and they all talk to each other.
And as long as you remove one of the components, which has a certain interface on a message level,
it receives certain messages on a so-called topic, basically a named bus,
and it responds on another topic.
If you replace it with a different component which has the same kind of interface,
nobody will notice as long as you, like, produce similar results.
That's really excellent.
I'm sure it's good for, you know, testing or adapting or maybe even trying different pieces of hardware in your robot, right?
Yeah, exactly.
So that's another big strength of the size of the community because so many people use the software,
that if you have, like, a set of cameras, for example, or motors,
then somebody very likely has, if it's used in other robots,
then somebody very likely has already implemented the driver's side of it
and make it a ROS component that you can just send it a ROS message,
you drive forward with that speed, and the motor will do it,
and you don't have to take care about how it actually maps to the protocol of that motor
and how it communicates over serial.
It's all hidden and abstracted from you.
So these nice little building blocks are kind of there,
so you're almost ready to start using the Python stuff to just orchestrate that.
Exactly.
And that's where Python is very strong at, the orchestration part.
For example, we have a tool which is called ROS Lounge,
and it's basically a description in an XML file which tells you what kind of software
and programs you want to run at the same time and how they talk to each other.
And all this, like, orchestration happens in Python because it's just,
it's way easier and faster to write, and you have the power of, like, dynamic language
where you don't need to know all the types at compile time.
It gives you a lot of, like, power over, like, static and compile languages.
So another strength of the core building blocks seems to be around geometry, right?
Like, that's got to be a real hard problem.
I've got all these moving parts to my robot.
Maybe it's got an arm and it's got wheels and it's moving around.
That's hard.
So there's support for modeling, that kind of stuff, right?
Yeah, exactly.
So if you think that you receive a camera image and in the image you see a certain object you want to grasp,
then you don't really know yet where that object is because you don't know without any further information
where your camera was when it took the picture.
So one thing which the robots usually keep track of is, like, first, their location in a known environment.
So it's usually, like, the base where your robot stands or where your wheels are.
But then you know all your joints and your arms and your head and neck, how all these, like, joints are oriented.
And then you can build up a transformation to where your camera is.
And to do that, like, in a very easy way, there's, like, packages which support you with that.
Like, geometry is one.
There's another one called TF for transform.
It can basically transform, if you see in your camera, in the middle of the camera, in a meter away, a certain object.
You can transform how far is that away from my left hand, for example.
So you can do all these computations very nicely.
That's cool.
I bet there's a lot of matrix multiplication going on in there, right?
Oh, yeah, for sure.
And that can get really difficult.
And depending on how complex your robot is,
you have to be careful setting up the kinematic and the computation
that it's, like, actually, like, fast.
Because you probably are not interested in every joint of your robot.
It's probably fast, fine enough if you only know a certain amount of them.
That's math you want to just put into a library and forget.
Exactly.
Because not everybody wants to write and see that stuff.
That's right.
So I actually have a couple of questions from some listeners
who sent in some messages or questions for you.
So one of them was,
what's the process of writing and deploying your own packages using Rospy?
Oh, so that's another interesting question for Ross in general,
because we don't only provide the software.
There's a lot of infrastructure because we have this federated approach.
Everybody contributes a package.
And I think the latest Ross release has, like, about 1,500 packages,
which we build for people into Debian packages,
because also nobody wants to deal with, like, creating a Debian package manually,
if you can avoid it, because you really don't care how the internals work.
And so we also make this packaging process very easy.
So if you want to write, for example, a simple package which does a certain task,
you just create a repository somewhere.
You want to share your code.
A lot of our code is on GitHub, but that's not, like, the only platform.
You can put it, like, anywhere else.
You have to be able to build your package.
Usually, if it's Python, you have a setup.py file.
Additionally, we have an XML file describing, like, meta information,
like what's your package's name, what's the license,
because people want to know if they can use your code or not.
What's the maintainer?
Does he have an email address which I can, like, talk to?
Is there a website which contains more information?
And also very important, what kind of other packages do you depend on?
And then, besides those meta information, it's all about your code.
So you put your Python code in there.
And after that one, you just go to our, like, website.
And there is a process how you can tell us that there is a repository with a ROS package.
And if you give us the location and we can access it, so it must be publicly readable,
then we can actually, like, provide that information to others.
And we can potentially even build, like, packages out of that.
And people can easily reuse it.
That's cool.
Is there, like, a central repository, kind of like PyPI with Python packages?
Yeah, that's kind of it.
But we don't separate them by language.
But there is a so-called repository called ROS Distro.
And that one defines repositories, external ones, where ROS packages are.
And there's, like, basically, I would say, like, two classes of packages.
There are the ones which are, like, released in terms of that we build, like, Debian packages out of them.
Or Fedora RPM packages.
Or whatever platform you want to imagine.
OS X is also one thing where we actively support people to build their code on.
And, yeah, you just have to register in this, like, it's basically a huge YAML file.
And you register your repository with a name and the URL.
And you can specify which branch it's coming from.
And after that one, anybody can use on his computer, like, a command similar to PyPI.
But it's a ROS-specific one which says, like, hey, give me the repository for the repository foo.
And it pulls down the information.
You can just either build it, if it's C++ code, if it's Python code, you can basically just run it.
So you talked about licensing.
And some of this, I'm sure, is open source, probably a lot of it.
Is there, like, a commercial ecosystem?
Are there companies that, like, build these packages and sell them?
That's a very good question.
I can't say for sure because the community is so big.
But I'm not aware of companies which sell, like, packages.
But there are definitely companies which use, like, the open source core packages, which are available.
And they build their own proprietary software on top, which they are free to do because most of the packages is licensed under BSD.
So we actually encourage people to build, like, commercial software on top.
And then they use these proprietary packages either to sell their products or use it only for their in-house robots, depending on their use case.
So another listener question is, says, is there a time where we can build ROS nodes without Katkin make?
When using ROSPy, they don't really feel that it's super Pythonic.
Oh, that's a good one.
So classically, in the very beginning, we had a tool called ROSMake, which was basically a make file, and it built the whole process.
And, like, two years ago, two and a half years ago, we introduced a new build system, which is called Katkin, which is based on CMake.
So CMake calls Python setup.py install, which is definitely not very native for a Python developer.
So for the current system, what I would call ROS1, which is currently ROS Indigo, we name them, like, in alphabetic order, like a lot of other projects.
There will be ROS Jade soon.
But for those things, we might not touch that because a lot of these changes will affect a lot of users.
And updating our tutorials and teaching the whole community to change their workflow is really difficult.
We learned that when we deployed the new build system, Katkin, like, two and a half years ago.
And we would not go for a change in the new future again, I would say.
Yeah, it's too much infrastructure and support knowledge around it to change it, right?
Exactly.
But we always work on, like, new stuff.
And that's currently one thing we focus on.
It's called ROS2.
It's basically we have learned a lot in the last seven years.
And we know that there are certain things where we have to make the system more flexible and more capable,
especially if you think about, like, really small systems like microcontrollers.
That's something we currently don't support very well.
Because of early design decisions, we use XML for some RPCs.
And generating XML on a microcontroller is really, like, not something you want to do.
That made sense, you know, seven years ago, probably, when XML was the thing, right?
Yeah.
And you had two i7s in the first robot, so they didn't care.
But now you have, like, Raspberry Pis and really smaller microcontrollers where you want to run stuff on.
And on the other hand, you have people who want to ship their robot, like the vacuum robot or their lawnmower,
which just works 100% of the time out of the box without ever a developer touching it.
The user can just use the product.
And for those things, the requirements are very different than the first systems ROS was built for.
And so we currently work on the next thing called ROS2.
And for this one, we actually think about and have some prototyping which have a pure, what you would call pure Python package.
It contains of the meta information, an XML file, because you still need, like, a coherent way to, like, describe your package.
Like, I don't know, like, other languages have the same thing, like manifest file, basically.
And beside that, you only have to set up the Py file, what you would expect.
And there's no, like, CMake around because you don't want to have, like, you don't need CMake to build a Python package.
Absolutely.
And then you also gain back features which the previous system didn't have.
For example, you could only use a very limited set of the setup.py functionality.
For example, like a C extension was really difficult to do because our system just, like, didn't allow you to do that.
But with a pure setup.py file, you can use the full power of whatever, for example, setup tools gives you to build your package.
That sounds fantastic.
So when's ROS2 planned?
That's always a good question.
Of course.
I would say it's going to be shipped when it's ready.
But we aim to release a first version in this summer.
But due to the scope of the project, it might not be something every user wants to switch over immediately.
It will be something which developers are interested in to see the new features.
And if they want to try it out and see how it fits their applications.
But it will take a long time for the majority of the user base to migrate.
So we don't plan to replace the original system with a new one.
It will be more a coexistence.
You can still use the old system.
It will be maintained.
And the new system will give you changes, but also more features and functionality.
And it's your choice when you want to adopt the new thing.
That's cool.
What kind of features are coming?
So that's actually a lot of things.
All right.
What are the highlights?
The highlights.
Let me think about it.
So the first thing is the new system uses a completely different communication system under the hood.
For the first version of ROS, we developed everything from serialization,
messages to the TCP transfer, UDP transfer, everything from scratch.
Because seven years ago, there was not that great library support for that.
But, yeah, time has changed.
And for the new thing, we actually rely on a standard from the OMG, which is called DDS,
the Data Distribution Services.
And relying on that gives us a lot of functionality without having to reimplement it from scratch.
And built on that system, we can provide you with much better support for,
for example, deterministic startup, reliable delivery of a message.
We can tell you your message got delivered, or we will give you an event like a callback and tell you that it has not.
And you can tune how often you want to retry it and things like this, which matter in a bigger system.
I could probably fill a whole podcast about the features of ROS 2, which will hopefully be better than ROS 1.
For example, one of the interesting things is ROS 1 always focused on Linux support, so Ubuntu.
There are a lot of versions where you can build it on Fedora and Pure Debian and OS X.
But one thing which it is not good at is building it on Windows.
And this is something we have fixed for the ROS 2 prototypes very early on.
So ROS 2 will just build natively in Visual Studio on Windows, the same as on other platforms.
So it's really like from day one to support it well.
And once you support it, it will be supported in the future.
But adding the support later is really difficult.
Yeah, because you've got to go back and fix a thousand errors and you've got to rewrite this and that.
That's great that you're supporting Windows as well.
It's nice to just say, yes, we support everything.
There's still a lot of people using Windows for this kind of stuff.
Exactly.
And currently, they have a really hard time using it.
Either they use virtual machines inside of Windows or they try it with Segwin.
And there are some tutorials where people make it work.
But it's everything but a smooth process.
It takes a lot of effort.
That's right.
Let's see.
So I have a couple of sort of larger scale pictures for you.
First of all, what kind of robots or automation have you seen using ROS?
You said something about the International Space Station, which is just amazing.
Oh, yeah.
That was actually a really interesting project.
The first, Robonaut, which is like a humanoid robot.
The first one had only torso and arms and the head.
That was not yet running ROS.
But the second iteration, which was launched last year, now has legs.
So it's more like four arms if you look at it.
And that one has a new computer system.
And the computer system is completely ROS-based.
And I think they made the choice to use ROS because it allows them to really fast prototype new functionality,
try them out.
And then if that goes well, focus on something they want to make more detailed.
And sure, our communication protocol is not the best one to communicate with a space station because that's definitely not designed for.
But they just wrapped the whole communication in the VPN tunnel.
And that's good enough for them because it's like it's isolated, it's secure.
And if our protocol has like 15 seconds or something latency to talk to the space station, that was totally fine for their use case.
Probably part of the benefit of the async message passing, not waiting on things and all that kind of stuff.
Exactly, yeah.
You have to be a little bit more defensive when you write your component to like not embed assumptions in your code, which don't hold in those scenarios.
But if you're careful about your code, obviously you can make it work for those cases.
Other notable use cases that you can talk about?
There are a lot of references of robots.
For example, there are a lot of industrial arms where they try to use ROS to do the higher level planning.
So classically, the robot in an industrial setting has like this really like tailored embedded controller, which is very robust and has to fulfill a lot of safety requirements.
But then you have the really complex behavior to plan a path around obstacles, probably in a dynamic environment.
And that's where ROS is very good at.
And so a lot of these use cases, they use like the industrial controllers on the lower level and then put ROS on top to do the more sophisticated dynamic environment planning.
And of course, there's a variety of vehicles from like small autonomous cars to like platforms in like warehouses to drive around and deliver things, which all rely on like localizing yourself and then autonomously navigating in an environment.
How do you see the future of robotics and what role do you think Python and ROS are playing in it?
I think ROS has a very bright future in robotics because the community is just very big.
A lot of people use it and that makes it grow very well.
So it addresses a lot of use cases and makes the things that people want to do achieve more easy.
So I think that will continue to grow and just spread into more use cases.
For example, quadrotors or things which are currently evolving.
The people, when they start these projects, look at what's out there.
And a lot of people just choose ROS because it helps them to like get there faster and prototype faster and get their product ready faster.
And usually that's to a very big amount due to Python because they can just like rapidly prototype what they have in mind.
And later on, if they figure out something is not fast enough or they can still like migrate code to C++ if there's need.
But a lot of stuff is not that critical.
Yeah, it seems like there's maybe two ways to go faster.
One hand is to write something in C++ and ROS directly.
And the other is maybe write a C extension for your Python code.
Is that a thing that would actually work?
Yeah, that's definitely something which works.
It's always a matter of like first you have to identify what's really the bottleneck.
And in a lot of cases, it's not the Python code.
It's like it's more like you have an algorithm which is just like not well structured.
And even if you restructure that in Python, you will be already good to go.
So it's really like finding the knob which you have to tune and not like just merge your code to C++ and then are not even better because your algorithm has a flaw.
Yeah.
Sometimes choosing the right data structure like a dictionary instead of a list or something would make all the difference.
Oh, yeah.
Lookups, right?
Exactly.
And especially in Python, a lot of things where you like sometimes unintentionally duplicate lists which are big instead of just mutating the list in place.
Those things can matter a lot.
So before moving code from one language to another, I would always suggest spending a good amount of like debugging and profiling before like making something like that because it's a lot of effort.
So it sounds like you guys are taking contributions for your projects and people are working on it.
They can find it at github.com/ROS, R-O-S.
And then the ROS pie is really in the ROS underscore com repository, right?
Yes, correct.
And probably the easiest entry point is usually wiki.ros.org because that gives you like the documentation like front end.
And from there, you find a lot of links to the repositories with the code.
And also a lot of tutorials, especially for the Python part.
So that sort of answers one of my other questions is if I've got, you know, a motor and I've got a Raspberry Pi and I've got some servos and I just want to make this thing.
I want to build a robot and I have some parts.
How do I get started?
I think the best thing for something like that is always like, I mean, depending if you want to like get there fast or if you just want the full learning experience, I would expect first like, of course, Googling.
We also have a platform where people ask questions.
It's answers.ros.org.
And just like, look if other people have done something similar.
And I'm pretty much sure that for this specific use case, people have tried that.
So you will see people how they did that, what kind of motors they used and what kind of applications they like try to develop and see how they did it.
And then try your project based on that one.
And I think that's always a good thing because you can just get back to the community and ask questions.
And usually you get like really good responses in like a short amount of time, which help you keep going on the project.
Did you guys do anything with the hour of code?
Like were there projects going on that you knew of or anything like that?
It seems like robotics would play a big role in that area.
Was the hour of code?
Are you familiar with this, the hour of code?
I'm sadly not.
I might miss something.
Oh, yeah.
So check it out next year.
It's in, oh, gosh, it feels like it was like three or four months ago.
Just check out code.org.
And there's a lot of robotics sort of projects.
The idea of the hour of code is have every student in the world do one hour of programming during that week.
And many of the projects that were sort of formed from there were robot based.
And so it seems like a really cool place to get involved with.
Oh, that sounds great because that will get the people engaged into the project.
That sounds really amazing.
Absolutely.
I will look that up.
Yeah, check it out.
Okay, awesome.
I think that might be a good place to call it a show.
A question I ask all my guests sort of near the end of the show is there's a ton of packages on PyPI.
And there's a lot of stuff on GitHub.
There's some really awesome stuff out there in Python you want to call people's attention to.
And, you know, Rospy might be the best one.
I don't know.
Yeah, Rospy, which you can sadly not get over PyPI because it requires more than just Python because of all the dependencies it uses.
But I think there are a good amount of tools available which came from the ROS project, which are really nice to use.
So just when you go through the wiki of ros.org, look at packages.
And maybe some of them are even useful for you without using them in the context of ROS.
And that's the big advantage that people can actually make use of them and apply them to different areas.
So anything you want to give a shout out to your organization, something like that?
Oh, well, I'm happy to work on the project.
So it's a fun project.
You see great results.
You have the hands-on experience in contrast to classic software engineering.
It's a great community.
And it's really fun to be a part of and design the future of robotics.
Well, thank you so much for being on the show, Dirk.
Thank you, Michael, for having me.
You bet.
This has been another episode of Talk Python to Me.
Today's guest was Dirk Thomas.
And this episode has been sponsored by Codeship.
Please check them out at Codeship.com and thank them on Twitter via at Codeship.
Don't forget the discount code for listeners.
It's easy.
Talk Python.
All caps, no spaces.
Remember, you can find the links to the show at talkpythontome.com slash episodes slash show slash seven.
And if you're feeling generous, please check out our Patreon campaign at patreon.com slash mkennedy.
Be sure to subscribe to the show.
Visit the website and choose subscribe in iTunes or grab the episode RSS feed and drop it into your favorite podcatcher.
You'll find the link at the bottom of every page.
This is your host, Michael Kennedy.
Thanks for listening.
Smix, take us out of here.
Stating with my voice.
There's no norm that I can feel within.
Haven't been sleeping.
I've been using lots of rest.
I'll pass the mic back to who rocked it best.
Bye.
.
you