Zorg with Gunther Cox and Kevin Brown

Hello, and welcome to podcast.init,

the podcast about Python and the people who make it great. I'd like to thank everyone who has donated to the show. Your contributions help us make the show sustainable.

Linode is sponsoring us this week. Check them out at linode.com/podcastinit

and get a $20 credit to try out their fast and reliable Linux virtual servers for your next project.

We are also sponsored by Sentry this week. Stop hoping your users will report bugs. Sentry's real time tracking gives you insight into production deployments and information to reproduce and fix crashes.

Check them out at get sentry.com

and use the code podcast in it at sign up to get a $50 credit. You can also visit our site to subscribe to our show, sign up for our newsletter, read the show notes, and get in touch. And to help other people find the show, you can leave a review on iTunes and tell your friends and coworkers.

You can also join our community forum at discourse.pythonpodcast.com

for your opportunity to find out about upcoming guests, suggest questions, and propose show ideas.

Your host as usual is Tobias Macy. And today, I'm interviewing Gunther Cox and Kevin Brown about Zorg, which is a Python framework for robotics and physical computing.

So, Gunther, if you could start by introducing yourself.

So my name is Gunther. I am a computer science major, and

Python is 1 of my primary interests as far as programming.

Great. And, Kevin, how about you?

Hi. My name is Kevin Brown, and I am also a computer science major. And, Python was not my initial,

program language of choice, but it has now since become my program language of choice.

How did you guys get introduced to Python? Gunther, how about you?

For me, it was a little bit just on my own and then also a little bit through work.

And, Kevin, how did you first come across Python?

I came across Python through work.

I was assigned projects that required it, and I basically was given an option to learn it or take a different project. And I decided to try something new.

So could you guys share a bit about what Zorg is and how it came to be?

Sure. So, originally,

the idea to create Zorg came around when we were participating at a hackathon at the hack UMass event at UMass Amherst.

The idea initially came up after talking to a group of developers from Intel that had, come to the event as sponsors,

and they had mentioned how

they had a a lack of,

a Python implementation to work on their Intel Edison boards.

And, what is it about the Edison that makes it a good platform for robotics?

So first off, there's a lot of very interesting features about the Intel Edison.

What's nice is that it has

a multiprocessor

architecture, so you can do some,

very interesting computing on it. You can do multiple things simultaneously.

The the other thing is that

it has,

typical Unix environment that actually gives you the ability, you know, to run,

fairly fairly high level commands and things like that that you don't have access to

on development boards such as

the Arduino and things like that.

1 of the good things about the Intel Edison when we were working on it that really appealed to us is that unlike working with a couple of other development board,

the Intel Edison allows for direct, serial communication between Intel Edison and your computer. So we didn't have to plug into a monitor or find a TV or find an,

find a router to connect it to. We were able to directly work on it without any extra,

effort required,

which made it really good for developing,

in a short period of time.

And when you say serial communication, you're talking about via an RS 232 port, or is this just via pure SSH?

This is it's through a, it's through a RS 232 port that,

that basically serves a,

terminal back to you through a TTY,

which basically gives you the equivalent of an SSH

without having to actually go through the protocol.

Yeah. I've,

spent more time than I would like at a the RS 232 console for, 1 of my previous jobs.

So how would you define and differentiate the concepts of robotics, physical computing, and the Internet of things?

So in my opinion, all of those topics are tied very closely together. I don't know if I

necessarily differentiate all of them, but I'd say that it's more of

a subset ecosystem

is that you have the Internet of things, which is a a larger overarching category,

and then

physical computing. Actually,

physical computing and robotics are both kind of go hand in hand, but I'd say that robotics is more of a type of physical computing,

and physical computing is just 1 component of the Internet of Things.

Because the the important thing to remember is that a lot of the devices that are out there, some of these aren't actually physical. You can have virtual machines running as well that, you know, processing information and feeding it back to your physical computing projects, which is kind of the cool thing about being able to use high level languages like Python.

This means you can actually, you know, leverage a lot of these these tools very easily.

Yeah. It seems that a lot of the dialogue about the Internet of Things tends to focus more on,

sensors with a little bit of intelligence

attached to them directly so that they can communicate their information wirelessly without having to have them wired directly into a separate piece of computational hardware.

It seems that the at least consumer robotics has taken off quite a bit lately with the advent of a lot of the different single board computers and

Arduino becoming more prevalent and somewhat more powerful.

What are your thoughts on that?

So, I mean, it's definitely very interesting to see, you know, how the wide availability of computing power is contributing back to what people are creating. Originally, a lot of the limitations

of, you know, boards like the Arduino

and, you know, basic stamp chips before that,

a lot of the issues were, you know, coming down to the fact that you were limited to only so much memory.

But now that memory and and processing power isn't such

a huge issue, it's it's not holding back the ability for people to use high level languages

that let them use more features and abstraction

than they would have been able to use before.

And

would something like Zorg be useful

in conjunction with, you know, microcontroller

boards powered by the MicroPython runtime, for instance?

We actually looked into that at 1 point. Kevin, if you want to, Sure. So the micro Python board along with PyBoard, I believe it is, that goes alongside of it, is something I've actually looked into in the past

for for connecting to Zorg.

As advantage of it runs pure Python and also,

supports

package management through PIP, which is something that, nicely goes along with Zorg, which also relies on pip for package management and for the just generally distributing the source.

So we have actually looked into micropython and I have looked into obtaining a board, but I have not yet,

been able to. But it's definitely something that it complements Zorg instead of fully replacing replacing Zorg. And Zorg does not fully

replace it. This would probably be a good time to dig in a bit to how Zorg is actually implemented and some of the design choices that you guys had to make in the process. Okay. So actually implemented and some of the design choices that you guys had to make in the process of building it.

Sure. So,

Zorg uses, an adapter pattern, which actually ends up working out very well for projects like this. It wasn't actually our decision to use that. We kind of discovered that that was how the hybrid group was designing,

their robotics frameworks.

The hybrid group, for anyone who isn't familiar with it, they designed 3 different robotics frameworks, 1 written, in Go, another written in Ruby, and another written in JavaScript, and those are called Gobot, r 2, and Cylon.

And at the time, we were we were looking, closely at those for inspiration for how to actually properly set things up and get it working. The power behind the

the adapter pattern is that it lets you define a a single set of code for your device. So a device might constitute something like the Intel Edison, the Raspberry Pi,

things like that. And then it lets you create all of your drivers, your your devices that you your other devices, so sensors,

LEDs, motors, things like that. It lets you create the code for those separately, and then

it promotes reusability because once you have the driver for the initial board created, all you have to do in order to use your sensor code with it is change out the driver you're using. And because they all use the same interface, you don't have to rewrite anything.

Yeah. Definitely is a very powerful pattern. And by not having to change your code when you switch out different hardware underlying it, it makes it a lot easier to innovate at the concept level as opposed to having to reimagine and sort of rework the code. If you wanna start running on a different hardware platform so that different people don't necessarily have to all have the exact same hardware to be able to take advantage of something like Xorg. I know that that's 1 of the factors that has made the Cylon JS project pretty popular.

Yeah. So, I mean, it's basically the same thing. So, I mean, if somebody, you know, somebody creates a project and it's designed to run on a Raspberry Pi, there's very minimal software changes that have to happen in order for somebody else to run on Edison or something else. But it's just it's very cool because it it approaches, you know, platform independence at the code level.

And I know that it runs on the Intel Edison, and it looks like there's some support planned for Raspberry Pi and some of the Arduino chips. What other platforms are you currently working to support and or which ones are you hoping to be able to support in the not too distant future?

So development is is currently partially completed for our platforms such as the Raspberry Pi and, the Arduino. Kevin's done a lot of work with the Raspberry Pi in order to get it working with some of the native Python libraries on there, which is very cool and very efficient to see how how a lot of that works. And then the, the Arduino borders that are set up using, the from auto protocol. Because, unfortunately, right now, we don't have the ability

to run Python on an actual Arduino.

Those tend to prefer c and c plus plus but, what it does allow us to do is create use format as the standard communication protocol between

the Arduino itself and, post computer

to actually control it. And

that's about that's about the closest we can get at the moment.

Just to add a little more onto that,

so I am the 1 who's actually in charge of the Python

adapter for Zuora, and that's actually very close to being, finished. I've got it working

pretty much completely with the Zorg platform. I have also invested in my own spare time in a, Piant 64, which I plan to ask for for relatively soon, once I actually figure out how to, interact with the piant 60 four's pins through Python.

And I've also got a chip, the, $9 microcomputer,

which I'm also considering

looking into supporting on the org.

And for platforms like that, what is actually involved

in

engineering the communication between the Python layer and the actual chip itself? Is a lot of binary protocols and sort of what are some of the either standard library or third party libraries that you need to use to be able to actually facilitate that communication?

Because there were a lot of layers that,

takes different

libraries for interacting with platforms, and it gives them a consistent interface for communicating with them,

which is very helpful, because, for example, the Raspberry Pi and Intel Edison

have completely different, built in libraries for communicating over Python. So with Zuora, we're able to actually make that consistent,

across those platforms with

minimal to no actual work required for actually porting code between the 2 of them. And what's fun about Zorg and what's very useful is that as long as there's actually a library already available for using

Python to communicate with the platform,

it's very simple to build a Zorg adapter for it,

which means that we aren't that often dealing with binary protocols and actually reverse engineering how we're supposed to be communicating

on the hardware level as long as we've already got the library support out there. So it's nice that for a lot of the popular

platforms,

the libraries do exist because Python is a popular language. And

by adding Zorg to them, we we got the we got the platform independent

that comes with Zorg that allows us to actually interact with devices

across them so that people don't have to do that manually.

And going back to what you were saying about the Arduino needing to have a host computer, how frequently do you see people using Arduinos where the host computer is something like the Intel Edison or the Raspberry Pi as opposed to actually tying it to a desktop platform?

I've actually seen that quite frequently, primarily with libraries such as,

going back to to Cylon JS again.

But I've actually used it a number of times that way myself, just to get the,

the platform slightly more mobile.

The

the benefit of that is a lot of times

that Arduino is you can get 1 for, you know, extremely cheap, you know, under $5 in some cases, and it adds a really good way of adding a number of input and output pins onto,

the typical ones that are available on the Raspberry Pi.

And I imagine that would also make it a lot easier to offload some different

logic routines onto the Arduino as opposed to having to keep them on the CPU core and tie up some of the processing

cycles that are available to perhaps do other things.

Yep. No. Definitely. It allows you to start delegating tasks to some of the other devices, which is always a help when it comes to processing power.

And is Zork currently

useful or actually being used for any production level applications, or is it still primarily intended for educational or hobby projects?

So I'm not aware of any production applications that are currently

using it. 1 of the kind of design philosophies that we wanted to go for with it was, you know, looking at how successful Python platforms have been for software such as, Django or or Flask and and,

you know, some of the the current web frameworks like that. So we were kind of thinking the concept behind it is what if you could create a Python framework for robots, say, a a a Django for robots, so to say. The idea is to have, you know, the extensibility to have numerous plug ins and support for different features available. And it's just the concept that we've kept with us as as we keep developing it.

And what kind of plug in system do you currently have in Zorg? So I know that you can plug in the different drivers for the hardware level, but at a higher level, what kind of things can you plug into it?

So, an an example of that is, still sticking with the the hardware level, the same the same architecture that allows you to create a driver that can allow your device to control a servo motor. You can also do things like creating virtual drivers. So I've experimented with creating ones that allow you to have a virtual

OpenCV driver. So

because, again, because there's bindings for OpenCV and Python, it makes it very easy to connect your Zorg application

to a,

to an instance of OpenCV,

and, you can do things that treat that that new module as a virtual device.

So whether or not there's a camera attached or not,

through you know, directly to to what what's being pulled in, It can still process images and come up with results. So I guess a good example of that could be a virtual face recognition sensor. The idea is to use OpenCV

and and a camera as a virtual driver that allows your robot to,

wait for an event such as somebody to walk into the room. And so you create a virtual driver that using open CV to watch for a face. And then once that occurs,

you can execute some sort of, action in response to that.

And what sort of hardware knowledge is necessary for somebody to get started with a project that would use Zorg?

So I'd say very minimal hardware knowledge.

We started at at a, a hackathon.

We we ourselves were were learning the Intel Edison

and we've tried to keep the documentation up to date such that someone can,

in the same way, just sit down and start learning it. It's designed to be fairly fairly easy to set up and get started with.

So 1 of the other things that's nice about Zorg is that we do have the options for web API, which we found even in our own testing and at the, hackathon reserve was developed. We were able to work with other,

with other people there who had,

basic web knowledge and were interested in actually testing out the door. And they were able to build, very minimal apps in a very small amount of time that interface with the drivers over a web API, which meant that the web API basically exposed the standard Zorog interface. So they were able to just make web requests instead of actually executing basic Python code. And that's 1 of the philosophies that we've tried to stick to with Zuora is that, there should be very

minimal work required to get it up and running on the device as long as we support the device that you're using.

And that's something we've tried to stay true to, and I feel that we have so far.

What are some of the most interesting projects that you guys have seen created using Zorg?

So to give a couple examples, I've seen a number of just small autonomous robots created with it. Some more specific examples, I mean, at the, the original hackathon

that we participated in, we designed a,

an automated door locking mechanism. The idea was that somebody, when they approached it, it'd be able to detect them and authorize them to open a door. And so that was just a simple application of demonstrating an IoT device

that, allowed me to interact with the physical world. Other projects, another 1 is 1 that I manage of of a, a 6 foot tall humanoid robot named Salvious. The robot's made out of recycled parts, and typically, I take it around and do different, technology related talks and demonstrations with it. But Salvius is currently running,

an implementation of Zorg and using that with several other Python libraries in order to do different tasks.

When I was looking at your GitHub, I noticed that you've also got a voice adapter for plugging into Zorg for being able to do voice activated

interaction with the actual robot?

I don't believe that's, that we currently have that on the Zorg repository on GitHub. I have a similar 1 that I created for, for a different project. Yeah. It's, that is 1 of the, the libraries that I use with the robot.

So on on a different on a different level, it it does get some sort of use for with Zorg.

I have a Zorg driver that allows it to communicate with the e mic 2 text to speech module, which is just it's a nice way of allowing the Raspberry Pi to hand off the text to speech process

to a different device to have that processed.

But the library that I use for the voice recognition, it, has several parts, including coming up with responses to what the user

is,

actually saying, and it it'll use different machine learning algorithms to figure out,

new responses based on hearing how the person replies over time.

That's very cool being able to build up that conversational repertoire just by interacting with the with the robot or if you're just using it via text

with, for instance, a chat room.

What kinds of machine learning routines do you use for being able to

determine

what parts of speech are applicable to the various different conversational

contexts?

So right now, the way it works is

it represents conversations internally as a graph data structure,

and it uses,

a couple of different algorithms

to come up with different possible responses.

So, 1 of those algorithms is the Levenshtein

distance algorithm,

and

that's doing

essentially a fuzzy match on the text. So it's looking at the current user's input statement

and the different known existing,

possible responses,

and it's looking for a simple text match.

Another 1 that it does is it uses, the Python NLTK,

natural language toolkit library in order to

look at the actual synonyms of different words in this in the sentence.

And it makes a comparison to try to figure out if, 2 statements are

base basically synonyms to 1 another in order to come up with the closest match and generate a response.

So how does Xorg compare to some of the other Python robotics projects that are out there such as ROSPy?

So for ROSPy,

I'd say that, XORB does not it

it doesn't necessarily try to compete with it. ROS, the robot operating system,

it it doesn't necessarily try to replace other robotics frameworks.

What's nice about ROSPy is that it allows you to ROSPy is essentially Python bindings for ross as far as I understand.

So what's nice about that is

it would actually be possible for

somebody to potentially use Zorg and ross,

side and

side. ROS,

the whole philosophy behind the project is to reduce

reimplementation of different algorithms.

So they really they focus on usability of their code.

And the whole, the whole idea is that they modularize themselves, and it would actually make it possible to use different components

of ROS with within Zorg or potentially vice versa if if 1 was interested.

So are there any other questions that I didn't ask that you think I should have or anything else you wanna bring up?

I don't believe so.

So for anybody who wants to keep in touch with you guys and follow what you're up to, what would be the best way for them to do that?

We're,

on GitHub, underneath the, organization Zorg, which is nice and easy to remember. We also have a newsletter that we occasionally

send messages to, which you can sign up for on our website, zorg.github.io.

That's probably the best way to keep up with us because that's where we post announcements

for the latest developments within the org, including new adapters, new drivers, and just interesting things that we found out.

So with that, I will move on into the picks.

And for my first pick today, I'm going to choose

the, Padlock password manager.

I have recently

been working on swapping out some of my duplicated passwords and using a password manager, and the padlock is a nice simple

open source option that has both Chrome plug in as well as an Android application. So

I've been using that. It's been nice and easy. And another project along those same lines that I started using recently at work is the Vault project from HashiCorp,

which is

a storage mechanism for being able to keep track of the various different secrets and security tokens and keys

for your infrastructure.

And it just makes it a lot easier

and more well maintained than some of the typical approaches that people generally use for keeping secrets in infrastructure. And with that, I will pass it on to you, Gunther. What do you have?

Okay. So, again, my, something that I really like is,

robotics. It's a subject that I'm very passionate about. I'd say that probably 1 thing that I would recommend most is a, a book called Robot Builders Bonanza.

It's got a lot of information in it, a lot of good projects and ideas. I would definitely recommend it to anyone who is kinda interested in, in either learning robotics or just looking at some some interesting ideas for different projects.

And, Kevin, what do you have for pics?

So I found a it essentially is a blog post, but it's also it's got tutorial built into it For working with OpenCV and Python for facial recognition and face detection, that's been a line of work I've been looking into for quite some time, and there's plenty of different algorithms out there. This algorithm appears to work properly with the latest version of OpenCV and the Python binding, which I thought was actually kind of nice, considering OpenCV,

as recently as last year, had a major version release, which made it such that path

of blog posts and tutorials didn't quite work how you'd expect.

Great. So I just wanna say thank you to you guys for taking the time out of your day to join me and tell me more about the Zorg project.

It's definitely an interesting space, and I am hoping to spend more time in it. And I'm sure that there are, plenty of my listeners who would like to,

start thinking around with Zorg for their own purposes. So thank you very much, and I hope you enjoy the rest of your evening. Thank you. You too. Thank

you.

The Python Podcast.init

Summary

Brief Introduction

Interview with Gunther Cox and Kevin Brown

Keep In Touch

Picks

Links

The Python Podcast.__init__