#7: Robot Operating System (ROS) and ROSPy Transcript

00:34 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 am at @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 Rospy.

00:59 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. We'll talk more about it later in the show, but please take a moment and check them out at codeship.com or follow them on Twitter where they are at @codeship. And, if you love this podcast, please send Codeship a message to say "Thank You", jump on twitter and say something like "Thank you @codeship for sponsoring the Talk Python podcast, you rock" or however you want to say it.

01:45 Next stop- time stamps. Several listeners have asked for something like an outline with time stamps, so they can go back into the show and 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 time stamps. Only a couple of shows have transcripts so far, and I am 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 am talking about, I think you will find it very useful. Special thanks to Mark Vimer for recommending a show on Rospy. We probably wouldn't have this show that you are listening to right now without you Mark, so thanks a bunch.

02:29 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 a feedback via the discuss common 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 list option, and subscribe to the show_guest list. there you will find a Twitter stream from all the guests who have been on this show and of course, that list will be growing over time. You can also find a link to the list on our homepage. Wow, what a week! Now let's get onto the interview with Dirk Thomas.

03:15 Hello, Dirk, welcome to the show.

03:17 Thank you for having me.

03:18 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 are mainstream so we'll probably have a lot of them throughout the show, but I am thinking of things like web frame marks, data access libraries, you know, Pyramid, we are going to do a show on Flasc3:37 , show on SQLAlchemy is coming out pretty soon, and what we are 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 in the software development maybe it's the reason they got into software and then they got dragged over to the financial section or they are building like you know, reports out of databases or something like that, which is robotics.

04:00 Yeah, that's really great project because robotics in general is I think more interesting then classic software engineering, because it's just much more hands on and you have like real results which you can try and set of like a big business projects.

04:14 Absolutely, and you know, like, I think one of the things that is sort of representative of that is I do a lot of work with schools and I do professional training for real developers, but I also help my kids schools with like a after school projects and stuff and they very rarely want to ride like a financial trading system, they are more like "How do we build a robot, how do we build a game?" And so, you are really involved with this thing called ROS- The Robotic Operating System, and we are going to talk about that for this show.

04:42 Before we get to it though, I think the listeners are really interested to hear kind of how everyone who has gotten to some really cool place contributing in some great project, well how did you get started, what's your background, how did you get into Python?

04:52 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 it's not computer science that's like the 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 big ones was Robocop, where you play like soccer with the robot, and you try to make the robot play soccer on its own so you not like steering it with the 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.

05:34 And what languages did you use to teach the robot to be autonomous?

05:37 Yeah, so, usually a lot of things in robotics if they are like the algorithms which do like see objects and the camera and make decisions, a lot of those things are like in C++. Classically, of course. But C++ is like, is a good language for doing like the low 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 hook 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 are just much more efficient in writing code and putting things together.

06:20 Right, it's more about understanding what you built than it is build in you know, shave in that millisecond or microsecond after...

06:24 Exactly, yeah. Especially if you think about like user interfaces or when you start robot to determine which parts to start and how to configure that, those are not time critical. So you want to be like as fast as possible developing that but it doesn't need to be like that fast at one time.

06:40 Perfect. So you started what kind these robotics projects and they were in C++, and somewhere along the way you were like "Enough of C++, Python" When did that happen?

06:49 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 doing and changing like plans, and we started, because the rest of the software was in C++, we were all familiar with it, so we started the C++ of course. And then we figured it out that like for graphic user interface you want to be really fast developing new things to interact with the robot, and I tried to like look at different languages and with some co-workers 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.

07:34 Very nice. So maybe you can give us a little bit of an overview of what the robotics, the sort of where Python is being used throughout the robotics industry?

07:44 Oh yes, so especially in the robot operating system which we work on at the open source robotic foundation, it is usually like two full 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 are doing; and while there are many language bindings for different languages those are of the two common ones. And Python especially is used for for example writing comment 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.

08:49 Sure. That makes perfect sense. When you are down talking to the serial port of the hardware 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.

09:00 That's actually very interesting problem, if you think about like serial communication you would think like serial communication very low level like C, C++ are the most fitting language for that, 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 are 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 would probably choose Python for that.

09:43 That's really interesting, I wouldn't have guessed that, but that's- I guess it makes sense, that's cool. So, you are associated with the ROS project, the Robotic Operating System at ros.org. Maybe we should talk about that for a little while?

09:58 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 while it just is better to reuse something which already exists and the robot operating system has been started like 7 years ago at Willow Garage, and they developed it for a very huge humanoid like robot, it's like robot on a mobile platform with two very complex arms and head with 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.

10:48 That's interesting, so it was almost extracted from the construction of the robot and the need that they had...

10:56 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 in different variety of things, but you see, a lot of design decisions in this system are just based because they were like developed for this first robot.

11:20 So you are also working on this thing called "ROS Py" which is part of the ros_comm communication project on GitHub. What's the relationship between those two?

11:30 So, basically ROS is like this many thing at the same time, you have 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 ROS PY is one of those so ROS PY is basically the Python implementation of this communication primitives. But ROS provides more than just bare communication, there is on the one hand a lot of toolings so you have a lot of tools to help you develop software for robots; you can introspect the state of your robot, you can change things at one time, additionally beside these tools you have a lot of visualization. Developers around the world write like applications and like functional components capabilities for example to make a robot be able to navigate, make him robot be able to like recognize objects with the camera.

12:36 Excellent, so there is like a simulator or something, is that right?

12:39 Oh yeah, there is also the option for the simulator, you can actually use different ones but one of the most common ones is Gazebo which is used like try your software with the simulated robot before you actually wind on the real robot.

12:53 Ok, so could I actually build and have like a virtual robot before I even touch a piece of hardware and decide ok now I'm ready to like go in and actually get the hardware?

13:03 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 the certain use case, so you want to try that out before so the simulation allows you to rapidly prototype 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 are not happy with the geometry of your robot you can change it and iterate on it over time and when you are happy with it you actually go to the hardware.

13:34 [music]

13:44 Now let me take a minute and tell you about our sponsor for the show: Codeship. Codeship 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 test have passed. Codeship supports your GitHub and bitbucket projects. You can get started with Codeship's free plan today, should you decide to go to the premium plan Talk Python listeners can save 20% off any plan for the next three months by using the code Talk Python, that's TALKPYTHON, all caps no spaces. Thanks to Codeship for sponsoring the show and I encourage you to check them out right now at codeship.com and thank them on Twitter where they are at @codeship.

14:32 [music]

14:35 So, you have mentioned some other tools, like when I was looking through the project there was one called RVIZ and one RQT.

14:43 Oh yes, so these are the two most commonly used like user interfaces to interact and look into a robot and control it. RVIZ is the older software it's like the more mature one and it has more features, it provides you basically with the 3D scene of the environment and your robot can like move in this 3D scene so you have this cap model for example which you can import as like a mesh of the robot and robot can actually drive through the an environment which you can render and for example if you see camera image from the robot's head it can project those image into the scene as the robot sees it. So it's very good for the user to get the feel what the robot currently sees and what his like information about his world is.

15:36 That's really cool, so it's like 3D environment and it basically sets the viewpoint of the 3D simulator to be where the camera would be?

15:43 Exactly, and you can actually put multiple view ports in the same scene or you can render all the sensor information the robot has so if he has a laser int he base you can render the laser scan itself and yous see how good does it fit with the worlds 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 of gesture the more difficult it is for the developer to follow what's actually going on in the system.

16:16 Yeah, and you said there is some debugging capabilities that can like let you capture these messages and that data flow and like replay it and stuff, right?

16:25 Yeah, so that's another feature of ROS in general but since you tried 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 like figure all problems which happen on the 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. That helps you actually fix things which are very hard to improve otherwise.

16:59 Yeah, it sounds like it would be really hard to set a break point on like a live robot, maybe you could do that on the simulator if it was you know, get in the same, you know, imputes or something, right?

17:08 Exactly, with the simulator you are able to reproduce them you are not even able to do a break point actually pause the simulator and then change something in the debugging code and continue, but you are actually able to like change the code and run it against the same laser information for example and you can ensure that now was your change as it's fixed.

17:32 Yeah the reproducibility part of it sounds really hard, that's fantastic.

17:37 Yeah and the second part you asked about was the RQT it's basically a different approach than RVIZ so they are both like serving a little bit different needs, and RQT is where all of Python comes in actually; because RVIZ is mostly based in C++, it has some abilities to run Python plugins, and RQT is the other way around. RQT is like Python application which has the option to run like C++ plug and if you really need like the logic of the power of C++. And RQT is not built around like 3D environment it's more like I would say like a development environment where you can add different things so we have plugins which visualize for example just single numeric value over time like a function like a controller or 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 that developer can use to look into certain things and have that all in one powerful environment.

18:43 Very nice, so, RVIZ is kind of the simulation and RQT is more like the setting it up and debugging it maybe...

18:53 Yeah, almost, the RVIZ thing though does not do real simulation, it only shows you the current state, it does not do like physic space simulation or something. That will be like a simulate external tool then.

19:07 Right. Ok, fantastic. You know, mostly I touch computers through software, so the hardware parts are a little unknown to me like if I've got server who is in 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, what do I install the robot operating system?

19:28 It depends on the use cases, there is such a variety for example, the PR2 robot from Willow Garage I mentioned earlier is like this huge robot, it has like two i7 multi-core machines it's like the heavy piece I would say. It does a lot of things, it's very powerful. On the other end you have like really small like adrenal base on raspberry pie 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 the use case and some of the micro controllers depending on what you use very common is the Linux version of the Linux distribution Ubuntu that people have run it on various different other systems, so we are very flexible in that term.

20:20 That's really cool, there is 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?

20:31 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 this like raspberry pie and the couple of motors and sensors into the small robot, like a toy, which just as like kids, like teenagers just trying to like make it like drive around and wear obstacles and that's like a great project. On the other hand, you have developers which really use that on like product level, like robots which are like car size robots which drive around, for example on the field for farming, and they have to drive reliably, they have to drive autonomously, they have to be like if something goes wrong, they have to like have fail saves so you have the whole spectrum of like kind of users which use the system.

21:24 Wow, I suspect that presents some design challenges, architecturally in the software, right, like you on one hand do you want to make it so kids can like build their 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?

21:41 Oh, the tension is definitely that is really difficult to like satisfy everybody in the community, so you have like very different demands and terms of like people who want like for hobby project they want very low 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 are like eventually mechanical engineers or probably even might be teenagers just trying to play with it. So it's really difficult to bridge that whole area of users, and I would say that there are a lot of design challenges, so one example of this when it was originally developed, 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 their 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 ROS also runs on the robo nao 2 which is on the ISS space station.

23:00 That's amazing.

23:00 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 ROS needs to improve in the future, so we are all working on like making it more suitable for like production level software that you actually rely on it and can sell the product and do not have to worry about it ever going wrong. But that's definitely an ongoing effort to make it more solid in these domains.

23:28 That's really cool, I'm sure that they are challenge, but probably also makes it a better thing in the end.

23:33 Oh yeah, I mean the more use cases your software has the more flexible it gets we often get actually contributions from the community which make it work on a totally different operating system which we do not even have in our offers, we can't even test it. So we rely on external people which use it on their systems, then contribute back and make it more usable in different scenarios.

23:58 That's amazing. So maybe we should talk a little bit about the core components, like what is ROS made of before we talk more about how a Py work in there.

24:08 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 the 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 maps the drive command to real action on the roll and the system tries like keep those things separate. And this abstraction on the first level allows the developer later to swap out 24:55 with the new implementation and try them out. And that's where the all this communication infrastructure comes in, that every component talks to other components by exchanging messages. It's like data centric approach.

25:11 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.

25:16 Yeah, so, so most of the times they are asynchronous there are times when you can do synchronous request responds and 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.

25:35 Excellent, and ROS really encourages that, with its API and so on, right?

25:38 Yeah, so if you look at the PR2 robot, it runs I think roughly a 150 25:45 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 will receive certain messages on so called topic, and responds on another topic, if you replace it with a different component that has a same kind of interface, nobody will notice as long as you like produce similar results.

26:12 That's really excellent. I'm sure it's good for testing or adapting or maybe even trying different pieces of hardware in your robot, right?

26:19 Yeah, exactly. So, that's another pick strings of the size of the community because so many people use the software, that if you have like the set of cameras for example or motors, then somebody very likely has used another robot, then somebody very likely has already implemented the driver side of it and make it the ROS component that you can just send it to ROS message you drive forward with that speed and the motor will do it 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 for you.

26:56 So these nice little building blocks are kind of there, so, you are almost ready to start using the Python stuff to just orchestrate that?

27:02 Exactly. And that's where Python is very strong at the orchestration part; for example we have a tool just called ROS lounge and it's basically the file that tells you what kind of software, 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 and compile time; it gives you a lot of like power over steady and compile languages.

27:36 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 have all these moving parts of my robot, maybe he's got an arm, and he's got wheels and it's...

27:48 Yeah, exactly

27:48 So there is support for modeling that kind of stuff, right?

27:51 Yeah, exactly, so if you think that you receive the 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 an environment, where the robot stands or where your wheels are, but then you know all your joins and your arms and your head and neck- how are these like joins 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 is like packages which support you with that like geometry is one, then another one called TF for transform. It can transform if you see in your camera in the middle of the camera and 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.

28:56 That's cool. I bet there is a lot Matrix multiplications going on in there, right?

29:01 Oh yeah, for sure. It can get really difficult and depending on how complex your robot is you have to be careful setting up the computation that is like actually fast, because you are probably interested in every join of your robot is probably fast enough if you only know a certain amount of them.

29:20 That's math you want to just put into a library and forget.

29:24 Exactly. Because not everybody wants to write and see that stuff.

29:27 That's right. So actually I have a couple of questions from some listeners who send in some messages questions for you. So one of them was: what's the process of writing and deploying your own packages using ROSPY?

29:40 So, that's another interesting question for ROS in general because we don't only provide the software there is a lot of infrastructure because we have this federated approach everybody contributes a package and I think the latest ROS release has like 1500 packages which we built 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 repositor 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 is Python you have to set up the Py file, additionally we have xml file describing like meta information like what's your packages 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, beside 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 the ROS package and if you give us the location we can excess it so it must be publicly readable, then we can actually like provide that information to others so we can potentially build like packages out of that, and people can easily reuse it.

31:26 It's cool, is there a like a central repository kind of like Py Pi with Python packages?

31:26 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 are like two classes of packages there are the ones which are like released and in terms of that we build like debian packages out of them, or fedora rpm packages or whatever platform you want to imagine. Yeah, you just have to register in this like, it's basically huge yaml file and you register your repository with a name and url and you can specify which branch it's coming from, and after that anybody can use on his computer like 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 a C++ code or if it's Python code you can basically just run it.

32:33 So you talked about licensing, is there like a commercial ecosystem, is there other companies that like build these packages and sell them?

32:44 That's a very good question, I can't say for sure because the company is just so big, but I am 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 proprieties of 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 product or use it only for their in house robots depending on their use case.

33:20 So another listener question is "Is there a time we can build Ros node without catkin make" when using RosPy they don't really feel that it's super Pythonic.

33:31 That's a good one. So classically, in the very beginning we had a tool called ROS make which was basically a make file and it build the whole process. And like two years ago, two and a half years ago, we introduced a new build system which is called catkin, which is based on C make, so C make calls Python set up the Py install which is definitely not very native to a before Python developer. So for the current system, what I would call Ros 1 which is commonly ROS indigo renamed like in alphabetic order, like a lot of other projects, there will be Ros jay tsun, but for those things we might not touch that because a lot of these changes will affect a lot of users and updating all tutorials and teaching the whole community to change the workflow is really difficult. We learned that when we deployed the new build system catkin like two and a half years ago, and we would not go for a change in the near future again I would say.

34:36 Yeah, that's too much infrastructure and support knowledge around it to change, right?

34:40 Exactly, but we always work on like new stuff and that's currently one thing we focus on it's called ROS 2, it's basically we have learned a lot in the last 7 years and we know that there are certain things where we have to make the system more flexible and more capable especially if you just think about like really small systems like micro controllers it's something we currently do not support very well because of early design decisions we used xml for some rpcs and generating xml on a micro controllers is really not something you want to do.

35:13 That made sense 7 years ago probably when xml was the thing, right?

35:19 Yeah and you had 2 i7s in the first robot so they didn't care. But now you have like raspberry pie and really small micro controllers where you want to learn stuff on and on the other hand you have people who want to ship their robot like the vacuum robot or their lawn mower which just works a 100% of the time out of the box without ever a developer touching it a 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 ROS 2 and for this one we actually think about and have some prototyping which have a pure what you would call pure Python package contains of the meta information in xml file because we still need like a coherent way to like describe your package, like other languages have the same thing like manifest file basically and beside that we only have to setup the Py file what you would expect? And there is no like C make around because you don't want to have like, you don't need C make to build the Python package.

36:24 Absolutely.

36:25 And then you also gain that features which the previous system didn't have for example you could only use for example like a c extension what was really difficult to do because our system just didn't allow you to do that. But with the pure setup the PyPI you can use the full power of whatever for example set up tools gives you to build your package.

36:49 That sounds fantastic, so when is ROS 2 planned?

36:53 That's always a good question. I would say it is going to be shipped when it is ready, but we aim to release a first version in the 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 into 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 bases to migrate so we don't plan to replace the original system with the new one, it will be more co existent, you can still use the old system and 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.

37:43 That's cool, what kind of features are coming?

37:45 So, that's actually a lot of things.

37:50 What are the highlights?

37:50 The highlights- let me think about it. So the first thing is the new system uses the completely new communication system under the hood. For the first version of ROS we developed like everything from the serialization of messages to the tcp transfer udp transfer, everything from scratch. Because 7 years ago there was not that great library support for that, but time has changed and for the new thing we actually rely on the 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 re-implement it from scratch. And build on that system we can provide you a much better support for example deterministic start-up, reliable delivery of a message, we can tell you your message got delivered or we will give you an event like a call back 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 future of the ROS 2 which will hopefully be better than ROS 1. For example, one of the interesting things is that ROS 1 was always focused on Linux support, so Ubuntu, a lot of versions where we could build on fedora, and pure debian, and os x, but one thing we it is not good at is building it on Windows. This is something we have fixed for the ROS 2 prototype very early on. So ROS2 will just build natively in virtual studio on Windows, the same as on another platforms, so it is really like from the day 1 to support it well, and once you support it it will be supported in the future but adding the support later is really difficult.

39:34 Yeah because you have got to go back and fix a thousand errors and you have got to rewrite this and that- that's great that you are supporting Windows as well, it's nice to just say "Yes, we support everything " there is still a lot of people using Windows for this kind of stuff.

39:43 Exactly. And currently they have a really hard time using it; there are some tutorials where people make it work but it's everything but smooth process, it takes a lot of effort.

39:58 That's right. Let's see, so I have a couple of like sort of larger scale pictures for you; first of all, what kind of robots or automation have you seen, you said something about the international space station, which is just amazing

40:11 Oh yeah, that was actually really interesting project, the first robot now which is like the humanoid robot, the first one had only torso and arms and a head that was not yet running ROS but the second iteration which was launched like last year now has like legs or it's more like four arms if you look at it, and that one has a new computer system and the new computer system is completely ROS based. And I think they make the choice to use ROS because it allows them to really fast prototype new functionality, try them out and then, if that goes well like focus on something they want to like make more detailed. And sure, our communication protocol is not the best one to communicate with the 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 if 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.

41:14 probably a part of the benefit for the async message passing not waiting on things and all that kind of stuff...

41:19 Exactly. Yeah. You have to be a little bit more defensive when you write your component, like not embed assumptions in your code, which do not hold in those scenarios, but if you are careful about your code, obviously you can make it work for those case.

41:33 Are there notable use cases that you can talk about?

41:36 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 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 pass around obstacles probably in a dynamic environment and that's where ROS is very good at; and so a lot of this use cases they use like industrial controllers on the lower level and then put it all some top to do the more sophisticated dynamic environment plan. And of course there is variety of vehicles from like small autonomous cars to like platforms in like warehouses to drive around and deliver things, which all rely on localizing yourself and let then autonomously navigating in an environment.

42:39 How do you see the future of robotics and what role do you think Python and ROS play in it?

42:46 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 the people want to do achieve more easy, so I think that will continue to grow and just spread into more use cases. 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 the product ready faster. And usually that's to a very big amount due to Python because they can just rapidly prototype what they had in mind. And later on, it's they figure out something is not fast enough or they can still like migrate code to C++ if there is need. but a lot of stuff is not that critical.

43:41 Yeah, it seems that there are maybe 2 ways to go fester. one hand is to write something in C++ and ROS directly, and the other one is maybe write a C extension for your Python code, is that the thing that would actually work?

43:53 Yeah, that is definitely something which works. It's always a matter of like first you have to like identify what's really the bottleneck, and in the lot of cases it's not the Python code, it's more like you have an algorithm which is just like not well structured and even if you restructure it in Python you would be already good to go. So it is not just merge your code in C++ and then it is not even better because your algorithm has a flaw.

44:23 Yeah, sometimes choosing the right data structure like a dictionary instead of the list or something would make all the difference right...

44:32 Oh yeah, exactly, 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 is a lot of effort.

44:55 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 and then the ros py is really ros_com right?

45:11 Yes, correct, and probably the easiest entry point is usually wiky.ros.org because that gives you like the documentation and from there you can find a lot of links to the repository for the code. And also a lot of tutorials especially for the Python part.

45:26 So, that sort of answers one of my other questions is if I've got a motor and I've got a raspberry pie and I've got some servers and I just want to make this thing I want to build a robot, and I have some parts, how do I get started?

45:39 I think the best thing for something like that is always like I mean depending if you want like get there fast of if you just want 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 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, then what kind of applications they tried o develop, and see how they did it and then try your project based on that one. And I think that's always the good thing because you can just get back to the community and ask questions and usually you get like really good responses in like short amount of time which help you keep going on the project.

46:29 Did you guys do anything with the hour of code? Like with their projects going on that you knew of or anything like that? It seems like the robotics play a big role in that area

46:40 With the Hour of code?

46:42 Are you familiar with this? Hour of code?

46:43 I'm certainly not. I might missed something.

46:46 Oh yeah, so check it out next year, it's in it feels like it was 3 or 4 months ago, just check out code.org and there is a lot of robotics sort of projects, the idea of the Hour of code is have very 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 very cool place to get involved with.

47:11 Oh, that sounds great because that would get the people engaged into the project, that sounds really amazing. Absolutely. I'll check it out.

47:18 Yeah, check it out, ok. Awesome. I think that this might be a good place to call it a show. Question I ask all my guests, sort of for the end of the show is there is a tone of packages on PyPI and there is a lot of stuff on GitHub, are there some really awesome stuff out there, in Python you want to call people's attention to? Ros Py might be the best one, I don't know

47:38 Yeah, ROS Py which you can certainly not get over PyPI because it requires more than just Python because of all the dependencies of users 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 to the wiki.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.

48:11 So, anything you want to give a shot out to, your organization, something like that?

48:17 Oh, well, I'm happy to work on the project so it's a fun project you see great result, you have the hands on experience, it's a great community and it's really fun to be a part of and design the future of robotics.

48:32 Thank you so much for being on the show Dirk.

48:34 Thank you Michael for having me.

48:35 You bet.

48:35 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 where they are @codeship. Don't forget the discount code for listeners. It's easy, TALKPYTHON, all caps no spaces. Remember, you can find the links to the show at talkpythontome.com/episodes/show/seven. And if you are feeling generous please check out our patreon campaign at patreon.com/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 will find the link at the bottom of every page.

48:35 This is your host, Michael Kennedy. Thanks for listening. Smixx, take us out of here

48:35 [music] developers developers developers