State Machines for Complex Robot Behavior

10. State Machines for Complex Robot Behavior, with Brett Aldrich

2021-12-28 · 1:51:46

In this episode, Audrow Nash interviews Brett Aldrich, author of SMACC and CEO of Robosoft AI. Robosoft AI develops and maintains SMACC and SMACC2, which are event-driven, behavior state machine libraries for ROS 1 and ROS 2, respectively. Brett explains SMACC, its origins, other strategies for robot control such as behavior trees, speaks about the challenges of developing software for industry users and hobbists, and gives some advice for new roboticists.

Comments

Outline

0:00:00 - Start
0:01:50 - Introducing Brett and SMACC
0:18:58 - Events in State Machines
0:21:01 - Clients and Client Behaviors
0:23:30 - State reactors
0:29:54 - Explaining dance bot + hierarchy in states
0:35:14 - Recovery states
0:38:07 - Origins of SMACC
0:56:47 - SMACC and market pull
1:05:31 - Robotics domains using SMACC
1:08:03 - A problem to push the limits of SMACC
1:12:50 - Making ROS packages smaller
1:18:17 - SMACC for industry users
1:22:23 - Making SMACC easy to use?
1:27:42 - Control in many robotics applications
1:31:16 - Comparing state machines to behavior trees
1:44:40 - Future of SMACC
1:47:01 - Advice for those starting out in robotics
1:50:16 - Links and getting involved

Transcript

The transcript is for informational purposes and is not guaranteed to be correct.

(0:00:02) Audrow Nash

This is a conversation with Brett Aldrich who is the CEO of a Robosoft AI. Robosoft AI develops and maintains SMAC, which is a library that aims to make it easier for roboticists to control robot behavior. One of the key ideas in SMAC is that a finite state machines, we'll be referring to finite state machines a lot in this interview, so I'll explain what they are. Before we start. Imagine that you have a lawn mowing robot. Imagine that that robot is powered off, and that you turn it on by pushing a button, it boots up and drives to a field to mow. When it gets to the field, it starts mowing. Once it finishes mowing, it drives home and powers off. This robot has states like powered off, booting up driving, and mowing. The robot also has transitions that occur on events, such as when the robot is turned on by you pressing the power button, or the robot arrives at the grass to mow these transitions change the robot from one state to another. For example, the event of arriving at the field to mow could transition the robot from the state of driving to mowing. So summarizing, a finite state machine is something made up of states like driving, and mowing, and transitions when the robot has reached the destination, or when it has finished mowing. This is the sense think act Podcast. I'm Audrow Nash. Thank you to our founding sponsor open robotics. And now here's my conversation with Brett Aldrich. Would you introduce yourself?

(0:01:52) Brett Aldrich

My name is Brett Aldrich, and I'm the author of Smak. State Machine library for robotic applications written in C Plus Plus, I'm also the founder of robust soft AI. Robot soft. We're the keepers of the smack tool chain. We're also the creators of the smack to runtime analyzer. A graphical application lets you visualize your state machines both statically and at runtime.

(0:02:13) Audrow Nash

Hmm. And what so can you start at a high level and explain what SMAC is, and then what its motivation is? Sure.

(0:02:22) Brett Aldrich

SMACC is a state machine library for robotic applications. I'd like to describe it as dealing with the highest level of task planning and management on a robotic system. It has many unique features. And.

(0:02:55) Audrow Nash

Okay, so it's a, it's a high level state machine library that helps you figure out so you get to control your robotics application with it.

(0:03:07) Brett Aldrich

It's a control, it's an architecture for control. And a couple of things about it. You know, when you're writing your state machine, what one it it provides a tight integration with. With ROS, allowing you to generate events for ROS topics, services actions right out of the box. It also offers a reference library of state machines that are guaranteed to compile and run right out of the box.

(0:03:41) Audrow Nash

So by reference library, you mean a bunch of state machines you can already use for specific things. Okay.

(0:03:47) Brett Aldrich

Exactly, exactly. With, with simulation included for many of them. Gotcha. It also offers a client library. And this, this is part of the architecture of SMAC. That allows ROS users to use ROS packages like move it to or nav to right out of the box. And it also provides a pathway for other ROS packages. And for the interfaces of those packages to be developed by specialists that are then tied to your state machine it all of these features have the effect of dramatically lowering the bar for new developers to get started in ROS, and then in programming in general controlling their robot. I can go on quite a bit longer about this, but I would say so it's a good high level overview of what SMAC is,

(0:04:45) Audrow Nash

is it kind of so that if I if I'm using smack, I can kind of compose more complex behaviors out of almost like blocks that will affect their behavior and I can, I don't know, like, if I have this sensor, I can run use this block to send out the data? Or is that how it looks kind of like a bunch of blocks that I can compose together?

(0:05:10) Brett Aldrich

Yes, yes, you have, you have state you have states, right? That you can let us to divide your problems. You have hierarchy, which does much the same thing. You also have the concepts of orthogonal, which are like boxes that allow you to modularize the physical subsystems on a robot.

(0:05:31) Audrow Nash

Okay, and by that you mean kind of control them independently or use them into basically, right. Can you give me a more an example, I suppose?

(0:05:40) Brett Aldrich

Yeah, absolutely. In fact, I'm gonna show a robot that that was recently built using smack as an example. So this robot is from field work robotics, it was built by them along with ourselves in Bosch, India. And as you can see, there's four robot arms and a couple of trays, and navigation based, so looks like a fruit picking robot or exactly. It picks raspberries. Yeah. And it was based on the work of Dr. Sutton's at the University of Plymouth and his soft robotics lab.

(0:06:16) Audrow Nash

So that just to describe it for the audio listeners, it's kind of like a big moving cart with four different arms. That probably it that's on wheels and probably drives through and picks stuff for it. Would you say? That's, that's a good description of it, I think to add Exactly, exactly. Okay, so use this.

(0:06:36) Brett Aldrich

So each orthogonal, contains an arm. So there's this orthogonal one with each arm. Another thought for the base, there's probably two more orthogonal is for there was like, like a packaging. Not exactly sure what you call it, almost like a gantry. A small gantry inside for for packaging, the raspberries. You probably also have your cameras with perception, all of these would would go into an orthogonal using a model of let's say, the human body. You might have orthogonal for your eyes, another two orthogonal for each arm. Yet another orthogonal, so is

(0:07:17) Audrow Nash

it? Can you think of it kind of like a degree of freedom? Yes, in a sense, yeah, you can. Yeah, cuz, so I mean, I'm thinking of so orthogonal, which means, like, it has a technical definition, which I think is it's the dot product is zero, or something like this, right? So it basically means perpendicular, but it allows for higher dimensions. Right? And so it's like a new dimension, a new dimension and state space kind of thing.

(0:07:47) Brett Aldrich

You know, I, the term that is I use it comes from comes from boost HR. And it was always tied to physical subsystems. But actually from boosted, charted, inherited originally from David Harold's 1987. Paper on state charts. So in 1987, David Harrell came up with state charts. And he developed that formalism that I guess you'd call it an extension of the formalism of state machines while working as a consultant, Israeli Aircraft industries, and in particularly, in particular working on an avionics system. And so in that, in that context of a fighter jet, each orthogonal basically was tied to a physical subsystem. Hmm. Yeah. As opposed to, I think a more like a mathematical interpretation, which is, I think, where you are going more

(0:08:47) Audrow Nash

with yes, that's where I know the word from I haven't heard it. And this in this this state machine sense. Okay. So then, so you have all these different orthogonal, I'm thinking of them kind of like a general degree of freedom, where multiple so if you said a full arm is one, it's kind of like a subsystem. And then maybe you want to do things with it. And maybe that subsystem has several degrees of freedom, like a shoulder and an elbow and a wrist, which is controlling it independently of other parts of the system. Is that kind of the core part? It's an orthogonal is something that is controlled independent of other parts of the system? Yes. Okay. Yes. So I'm thinking generalized degree of freedom. So multiple degrees of freedom

(0:09:32) Brett Aldrich

is probably modularity. Yeah. Yep. Yep.

(0:09:36) Audrow Nash

And can you have can you have orthogonal in orthogonal? Like, if I have an orthogonal that's my arm? Can I have that broken down into orthogonal is that are my shoulder, wrist and elbow? Is that kind of this hierarchy? Okay,

(0:09:53) Brett Aldrich

so I think the short answer is no. The orthogonal is can be quite complex, and so you deaf We can have multi joint, real, you know, arms in

(0:10:03) Audrow Nash

one orthogonal, orthogonal.

(0:10:07) Brett Aldrich

But one of the things that that that we did we being Pablo and I in terms of the robot, sorry, what? Oh,

(0:10:18) Audrow Nash

sorry, I thought we were still talking about the robot for picking

(0:10:22) Brett Aldrich

things in Yeah, not for that robot in particular, but in, in SMAC, as a library and viewing smack in a historical context. One of the things that that we we did was, we took the orthogonal concept that David Harrell and Andreas Huber Dawn, put into, into, you know, instantiated essentially in boost a chart, and we simplify, and because up until that point, so I think the world of Andreas Huber Donny, but he didn't, he never really used the orthogonal and the orthogonal in a, in a, in like a context of a PC really don't make that much sense. And so we took them and began to use them, and we saw shortcomings with them. And so we, we simplified the orthogonal structure and, and then what we did was we added this, this architecture part of clients and client behaviors. So inside of each orthogonal, so visualizing, and orthogonal is a box, right, a box inside an eight box, there are generally two to further boxes inside that have a client and a client behavior. The client is has a lifetime of the entire state machine. So if you if you have something that you have some piece of code that you want to effect that robot in every state, then you just put it in the client. So this would be something like, let's say, you've got a connection to a robot arm. And if at any time you lose that connection, you want some event to be thrown, you put that in the client, the client behavior contrast,

(0:12:11) Audrow Nash

oh, it's like a global state in a sense. Yeah,

(0:12:15) Brett Aldrich

there is there was a blow valatie to it. It's a different type of state, though, in that. Typically, in smack, we're talking about states in a control sense. The states that are stored inside clients are more like, like an image state. This gets confusing actually, what it's like when you hear about something like state estimation, it's more like an image in a sense, right? So that part is stored, whereas the control states are always explicitly controlled within smack the state machine back to the talk. So if you've got clients that are scoped to the life of the state machine and client behaviors, they're only scoped to the life of that state. And and you can have more than one client behavior at any one time. And I would say that that's where really the modularity comes in. That's basically how you interact with the orthogonal is through the client behaviors, the client that sets up, you know, would say, all the communication and all the kind of stuff that you want throughout the lifetime of the state machine. But the particular behaviors are in are in these modular client behaviors that

(0:13:27) Audrow Nash

so the client is like, it's the manager of, but so how do you call it so you have the client and the client is in a? What was the word again, orthogonal? That so you haven't or thought so you have like a global state, and then from the global state, you have your orthogonal, your orthogonal is some piece that can be controlled independently of all of the other orthogonal, and then inside that orthogonal, you have a client, and that client is going to control that orthogonal to run several different behaviors given the state. Am I understanding correctly? Not the client

(0:14:07) Brett Aldrich

and the client behavior. But okay, what's the sorry? What's the client behavior? The client behavior is different in that its lifetime is scoped only to that state?

(0:14:18) Audrow Nash

And how are we talking about states? And this You were saying something about images? And what is the state in this?

(0:14:25) Brett Aldrich

Yeah, we're talking about it thinking from a control structure. So going back from like, a global, yep, the state machine is essentially synonymous with the application layer. Right? So the state machine is your application. And there's one state machine on any one robot I mean, one time, okay. Many libraries have like where you start nesting state machines inside of each other. I don't, we don't do that with you don't like it. Yeah, okay. I think it it creates problems with data with routing the data and other problems. So, so you have a state machine that It is your application. And within that state machine, you have a series of states, and they can be grouped in different levels of or higher of hierarchy. So let's say let's say back to

(0:15:12) Audrow Nash

that vegetable picking robot. Like that would be a nice concrete example, to talk about this. Okay.

(0:15:21) Brett Aldrich

Okay, yeah, we'll use that. And also, we'll blend in an example that I heard about it for the DARPA subterranean challenge. So in starting out, or in one of these teams that I've had the pleasure of speaking with people involved, they started out with a four state state machine. Okay, so four states. So in that, in that example, you would have one state machine with four states moving forward, nor hierarchy at this point, I

(0:15:53) Audrow Nash

see, I see one of my points of confusion. So state in robotics, and like a control sense can mean like, the thing that defines where the robot is. So this joint has this degree, this angle, this joint has the next one. So I was trying to understand this, but you're using state as an in a state machine. So is a specific state that the state machine is in. And that's what we're talking about when we're saying stuck in this. Okay. So then we're saying we have a finite number of states, those control basically the behaviors, or we can do different behaviors in different states. And we move through from one state to another as the operation proceeds or something like this based on Okay, exactly, I see an ambiguity, okay, that I was confused by. But it is it's a confusing thing. And especially, yeah, we'll just have to say state for state machines or something and states for controls or something. And that will help keep me clear with it. Or I'll try to make it explicit anyways. Okay, so you have your state.

(0:16:56) Brett Aldrich

So this is back to this example, we have four states, right? So, and we'll just name them state, 123, and four. So in each of these states, going back to the example of that field, work robotics robot, we would have, let's say, Okay, we got one orthogonal for each arm, one for a base, one for the two gantries, that's for six, seven, and let's say one for perception eight. Okay, so in each of those four states, you're going to see eight orthogonal 's, that okay, inside you, each one will have a client in every state. And then, depending on what behaviors we want that robot to express, we arranged the client behaviors accordingly. And so it provides like a modular control structure for each subsystem of the robot.

(0:17:51) Audrow Nash

Gotcha. So if you are, yeah, and the state

(0:17:54) Brett Aldrich

basically serves is like, this gets more into like the sub state architecture of smack, but those, the client behaviors, and the clients throw events based on what happens outside, you know, so smack is a single node, operate back to this example. Smack is a single process operating at runtime. And you're also going to have, you know, other processes on this system, you're going to probably have nav two, you're going to have move it. One with perception. And so when those other nodes communicate via let's say, ROS topics or services, the the SMAC clients will turn those messages, which you'll specify into events. And then those events are that's cool ordinated by the state, like, like a conductor would, you know, on this event, we transition to this state, at the end of the day states are a lot of people, you might you might incoming to state machines, you might think that states, that's the state machines are about states, and they're really not they're about events. And okay, it's through events that you begin the subject of states almost, it's like, it begs the question, you know, like, when you have an event, you have what was before and what's after, right?

(0:19:25) Audrow Nash

And then can you define an event? Can you define event,

(0:19:29) Brett Aldrich

an event is general explanations. It's like some type of discrete.

(0:19:37) Audrow Nash

So in ROS, it would be have I received this message or not sure. Is the event is the message occurring, this kind of thing.

(0:19:45) Brett Aldrich

Exactly. Exactly. Are they completing or

(0:19:49) Audrow Nash

are they action completing or something like that? So if I'm using naff to, and I want to move from one spot to another spot, the action completing of me moving to the To location could be the event. So it says I'm in this location event has occurred, I then occur.

(0:20:07) Brett Aldrich

And then when that event is occurred in some in smack in a state Yeah, you specify often where you will like what the next state you'll transition to is.

(0:20:17) Audrow Nash

So are we always transitioning on events? Or should you always go to another state, or you can probably stay in the same state and have several events. I'm just trying to think of more complex behavior. But so are events always used? They're not always used for transitions, but they

(0:20:35) Brett Aldrich

not always but and here, we get into the minute you start using events, you start using more. One of the another one of the features we added to I'm saying these are things that I think are interesting, historically insensitive, like what's unique about smack, you know, versus a blue state chart. And what happened before we we brought in the concept of state reactors.

(0:21:03) Audrow Nash

Let us define a few things just because there's a few things that I don't quite understand before we get into state reactors. So I don't quite understand the difference between clients and client behaviors.

(0:21:16) Brett Aldrich

Sure, it comes down to the lifetime client, oh, or lifetime to the state machine. And behaviors have a lifetime specific to that event.

(0:21:29) Audrow Nash

Oh, okay. So so, so client behaviors are just for behaviors? Or how does it what why are they named that? Let me just see, I think my smoke alarm is gone, or some smoke alarm?

(0:21:45) Brett Aldrich

Sounds like a smoke alarm.

(0:21:46) Audrow Nash

I do hear a beep beep. We just filter it out in the thing. So long as I don't smell smoke and whatever. Yeah. Okay,

(0:21:54) Brett Aldrich

you do get out of there. Yeah, for sure. Just gets into like the systematic architecture of code layout SMAC offers. So let's say you have something that you want that robot to do, like some type of event that you want to respond to in a particular way. But you want that to be throughout the like every state of the state machine, you put that code in the client.

(0:22:25) Audrow Nash

I see. Okay, so and then. So you're kind of you generate these client behaviors, when the event happens. And that will take care of a specific, it's the kind of created and destroyed on a specific event, whereas the other one occurs all the time, I'm thinking of them, like, kind of simple, but for like web pages, or something like you always want to load this one thing, it's going to happen no matter what page you do. So it's like the header or something, that's always going to be the same. And then your client behaviors would be the very specific things that are on a specific route, in this case, yep. Is that a fair way to think about it?

(0:23:03) Brett Aldrich

It's not very good, and the only nitpicking thing I would have there is that it's there not so much. The client behaviors aren't created with events, they're created with new states. So one state to another, that's when the client behavior is created at runtime.

(0:23:23) Audrow Nash

Okay, I see. Okay. And then you're gonna so there was another thing that you were going to introduce?

(0:23:32) Brett Aldrich

Yeah, state reactors. So this is another type of this is all part of the the sub state architecture. So like, once once we're in a state and looking down at the pieces inside of it, what state reactors do is so

(0:23:47) Audrow Nash

what so in the sub state what composes a sub state? Is it so other states within states or are there so others?

(0:24:00) Brett Aldrich

We do have we do have? We do have hierarchy? Yep. But when when we're talking about the the, but to in the hierarchy, one thing that that is unique and smacker? Or maybe, I don't know, what's one feature? You we break down the library into having container states and leaf states and it's the leaf state that has the orthogonal and the full substate architecture, V. Okay. The container states don't by default. You can turn them on. It's smack we follow the philosophy of we do things in a certain implementation that you know, as we see that we think is best but we try not to turn off like other ways of doing things because some of the early clients that we had really challenged my views of how they would interact with the system. And I'm thinking to you, Bob peetha, gray, Orange. They, they did things that I, what, what are you doing? You know, it took me back. But, uh, but it totally valid way of running things. So we try to leave those those sorts of things open anyway, back to the hierarchy. So. So generally, there's always a leaf state that has orthogonal and other things like that a state reactor is is a just another one of these objects. And what it does is it receives events and throws its own event. And so it basically brings in second order events, the first ace, so we came up with it. This is in like, mid 2018. And we just begun the library in like, at the end of 2017. And we were contacted by the company here.com. And they were working on a self driving car at the time that it had a very complicated array of six, like super high end cameras, was for like a self driving car that would map you know, as well, and what, what they wanted it to do was, you know, navigate from one point to another, when it started up, it wanted to make sure all the cameras were ready to go, and then drive, if anything happened, stop, bring all the other cameras back on line and go. And that led me to create the state reactors. And so what we did is we have a state reactive called all events go, and it's a runtime object that resides inside the state. And it receives events from camera one, that camera to event and once it's received it from all then it throws its own event, and then the state transitions. It's become such a popular, I'd almost say it's a state machine design pattern. You know, we call it S T acquire sensors. And I don't know what percentage of state, you know, we have in the reference library, we have certain state machines that are extremely simple. It's just like this one back and forth. So they don't have it. But I think for all of the other state machines that we've like, if there's a simulation video, I'm pretty sure all of them have one of these SD acquire sensor states and very early on in the execution chain.

(0:27:41) Audrow Nash

Gotcha. Okay, so you have those that will kind of take information and they take in all the events, and then when a specific condition is met, they may event they may emit another event, and that can be used to trigger some sort of transition or whatever might occur. Correct. Okay.

(0:27:59) Brett Aldrich

They also, one other thing too about him, that's I don't know, that might be interesting for the specialist out there. They they've set the stage for us to move ahead with cogeneration in a new way, one of the things that's always cool state machine libraries,

(0:28:17) Audrow Nash

when you try to play code, or Yeah, well, boilerplate,

(0:28:20) Brett Aldrich

but also, like graphical cogeneration. That one of the problems that that has are always complicated, that is callback functions. But with state reactors, you avoid that by with, you know, through these second order events. And so yeah, and that's part of our plans over the over the long run, you know, to build out an entire tool chain along with the the ability to right now we have this Mac to runtime analyzer, but we want to create a smack to writer where you can, you know, graphically align your state machine and have it auto generate the code, or at least generate some of the code, you know, like, like a lattice framework type thing. And, yeah, the only thing about that is that, in my opinion, you have to do that last. Because if you do that too early, and you've got some problems in your, you know, in your architecture, you basically baked it in place. So, yeah, so that's one of the things I'm really hoping to accomplish with SMAC, in this current year is basically getting more and more use cases, to a point where it's like, okay, no, no, we've seen you know, we've got an idea about every which way that the library could conceivably be used. I don't know if we'll get all the way there, but,

(0:29:46) Audrow Nash

but if you get a lot of them, then you have a fairly general solution, and then it can be used for a lot of things. That'll be great. Yeah. So one thing that I don't quite understand, well, I guess I'm having trouble mapping The idea is together. So I understand this architecture with the client behaviors and you have your orthogonal and you have your states and things like this. Can you explain kind of so like a simple application, say say like that video of the Fetch, sorting, the Fetch, in simulation, sorting cubes by color, okay, like, how do we go from these states? And then the orthogonalize in and then how, just like an idea of how all the systems work together to create some reasonably complex behavior? Or can be a simpler one, if that's kind of complex?

(0:30:41) Brett Aldrich

Yeah, maybe we'll start with the dance bot example. We'll kind of dive into that one a little bit. All right. Sure. In so for those who, you know, who haven't seen it, the best spot to see the dance bot example I can like it. Yeah, is in is in the the ROS world 2021 presentation on smack to It's the opening video how we link that all together.

(0:31:12) Audrow Nash

And just to describe the video a bit, it's a robot that it's in a sort of maze, and it goes to a location and then it drives until it hits a wall, and then it goes back to its original location. And then it goes out again, but slightly different angle from where it was heading. So it makes kind of like a star pattern. And where it goes, and it bumps each of the walls around it, and then it goes back to its original location, and then it goes to some other location to start doing the same pattern there. And I believe the intention with this is to map out an environment.

(0:31:45) Brett Aldrich

Not exactly it's oh, there is there is a mapping that, that, that that does happen. But it's really more about floor coverage. We were modeling, you know, how how a robot might, you know, cover a floor space in in modular ways. In that one, the robot navigates to to global waypoints and begin, proceed to perform dinners of superstate this is, so now we get into hierarchy a little bit. So we've got our leaf state. And then you can have these containers. These are like levels of hierarchy, which we have shorthand for, which I'll go into right now. So the first level of hierarchy we refer to as super states. The next level we refer to as mode states. There's no difference,

(0:32:42) Audrow Nash

per se, it's just because it's a hierarchy. So super states is like high level control. And that's like fundamentally what the robot is doing. It's mapping it's driving to some location.

(0:32:54) Brett Aldrich

In your application, I think I think the most common use for for Super states is for loops, for loops, or like, like sequences, you know. So in that application, it moves to the first global waypoint. Okay, it's to execute a super state, that is a radial pattern. And you can set the parameters of that radial pattern in the superstate. So I think in the video, it showed something like 16 rays,

(0:33:29) Audrow Nash

and the 360 divided by 16. And then it just went out exactly what each of those angles,

(0:33:34) Brett Aldrich

okay, but you would just go in there, and let's say, put in 32. And so it's parameterised. Exactly, exactly. It does three of those super states in a row, at which point it navigates to a fourth way point, and we haven't execute an F pattern, same kind of thing, although it's like, I think it's a series of seven states that execute this repetitive F pattern. Again, though, designed for floor coverage. Then it goes to a final waypoint where it's more of an S shaped pattern. So five total super states and five global way points, all the super states parameterised. In this case, we're only using two or thought well, let me think there might be more than one orthogonal in there. But in terms of like the crucial orthogonal for that example, there's two, there's the, the the LiDAR, and to cool. Yeah, in that particular example,

(0:34:40) Audrow Nash

and nav to handling the navigation of the robot from one spot to another, okay, and controlling the motors and everything to drive it around. Exactly, right. Okay.

(0:34:51) Brett Aldrich

Yep. Yep. In other in other state machines, we might use, you know, something like ROS 2 control the same kind of a similar way that that move it relies on ROS to control the move the robot. And we've had we've built examples and navigation in ROS, one where it uses the ROS 2 or the ROS control draft controller. But yeah, it's you know, you start using like your standard ROS stack to get around. Yeah.

(0:35:16) Audrow Nash

And then so if we're in superstate one we're in the radial star. Okay, one. What does that look like from the mode states, so not the super states, but now we're in Super state one. And so super state one is composed of mode states, as you were saying, with the shorthand, yeah. So how does it look? They're like, what, what's going on down there? And how do we get closer to

(0:35:44) Brett Aldrich

the CLI that example? Like, in depth, or just ballpark? Yeah, I believe the way it has is that we've got a mode state called Run, and we have another one called recover. And where I see that architecture evolving, in going, you know, in terms of real world is that one of the things that SMAC offers is very advanced recovery sequences, and capabilities. So I imagined, and I think one of the things that SMAC one of the most important things that SMAC offers and in why it's disruptive, is that it allows for a new order of magnitude in the complexity of robotic missions, particularly age missions. So So for instance, let's let's take an example of a fixed wing aircraft, right. So you'd have one mode for taxing on the runway, another mode or takeoff, another mode for I don't know, you know, the your initial flight, where you're finding your right heading, stuff like that. And for each one of those modes, you're probably going to want to have a separate recovery state, you know, separate recovery mode state, where dependent, so let's say you're in takeoff, right, and something wrong happens, then you switch from that mode.

(0:37:13) Audrow Nash

So the appropriate recovery for that will take

(0:37:15) Brett Aldrich

off recovery, and you begin your, your, you know, error recovery procedures there. And as that continues to expand, you just, you end up with like greater, greater needs of hierarchy. It also brings in the question of where your data goes, another unique feature of SMAC is that every state is a class and every container is a class. So you can scope your variables and other things to the lifetime. And that's needed. You know, perhaps you need a variable across every state in in a certain mode. Perfect, you put it in the mode, you can also do you we also have the opportunity, or the option of global variables. But

(0:38:01) Audrow Nash

yeah, okay. So interesting. And so, can you tell me a bit more about the real? So you're saying, I guess, the origins of smack and how it was born, from, I guess, a real application and then how it's evolved since? Yeah,

(0:38:25) Brett Aldrich

it's in the oranges of smack it's hard for me to put a finger on it i i would say it started the same. So I graduated from UCLA with a degree in biochemistry. And one of the the, my first job outside of outside of university was under a NASA grant at the UCLA UCLA Medical Center in the department of Head and Neck Surgery under a brilliant researcher named Dr. Larry Hoffman. And I, I ran one of the research labs there. I forget the exact title, but that one of the labs was basically mine. And what we were doing was it was this insane program where we were dissecting the inner ears of we were, we were injecting, like dyes, and then dissecting the inner ears of mammals, mainly chinchillas and mice. And then we were studying the organelles of the inner ear, the you trickle and the sack you will and stuff like this.

(0:39:34) Audrow Nash

I don't know anything about this. Okay. It's just an our little parts of the object. Yeah,

(0:39:41) Brett Aldrich

even then. And in dissecting these organelles, we would then visualize them, you know, under fluorescent microscopes, and imagine like, I'm holding up for the listening audience. I'm holding up like my hand, it's like an Organon. It's like they would, they would have these Nerf patterns that would kind of follow through these organelles. And we were studying those in an effort to create better rocket guidance systems, which I have no idea if it ever, you know, resulted in such things, I have a feeling gyroscopes do a pretty good job. But it got me it brought up.

(0:40:25) Audrow Nash

So it was this this was like, fundamental. So like, one thing that might be similar is I think it's rapid random exploring trees, R R T, or something like this. Yeah. So it's, it's almost like an you're trying to identify an algorithm that controls these nerves spreading through them. And then maybe that algorithm would be useful in applications, like, guided missiles, or whatever it might have been.

(0:40:53) Brett Aldrich

Yep, that's exactly right. And that's, and so it opened, expose me to to concepts like this. neural nets was talked about. I got to program a little bit of Fortran. Also, decision trees were part of that. And it, it, it began an interest that I had, like, even in terms of office hours, where I just started, I started sketching out these kinds of systems, you know, like, and then, in looking back on it, it was clear to me that I was drawing out state machines, although my early my earliest state machines, it's like, each state was a neuron. And so I was imagining these chains of neurons and how they would process information. And you know, what, where that was just like, yeah. And so anyway, that was, that was where, like, some of my earliest interest in that arose. Later, I went, I went back to school to get a degree in math and theoretical computer science at the University of Irvine, and which I did not complete. But in some of the early courses, you know, I was exposed to set theory automata theory. And so I had

(0:42:13) Audrow Nash

no, any idea what that latter one is. Oh, automata

(0:42:16) Brett Aldrich

theory. That's like, that's like the, that's like the math behind things like finite state machines. Okay. Yeah. You get there into like, whether or not state machines are Turing complete stuff, like

(0:42:32) Audrow Nash

proving things about them. Theoretically. Yeah,

(0:42:35) Brett Aldrich

exactly. Particularly when you start getting into advanced state machines with event queues. You know, and like, how then how that maps so there was that that part as well. I moving on later, I remember I got there was a when I started believing that robotics was the next wave that it was in I believe this still that robotics is going to be the next boo and probably the biggest one in my lifetime. I feel like that's going to happen to within the next 10 years. And so as I was looking forward to that there was a book called UML of real time systems and I read that book like I I've gotten rid of it since but I don't know I could almost pry tell you on a particular page what's on it and sketching too at that time though, I although I was so interested in them I never would have thought that I could have written the state machine library like that I just I would have thought that well and at this time this is really before ROS you know so like the systems were more closed off I would have thought that that was part of some giant proprietary stack I see Yeah. Anyway my my first project you know that involved ROS was creating what the company is real robotics and we were creating level line cable reels that we're going to provide mobile robots with tethered AC power for which you know more

(0:44:17) Audrow Nash

level line which is level one okay?

(0:44:19) Brett Aldrich

It's a level wind meaning level wind level meaning that if we've got a real here it goes like a fishing exactly like a fishing line fish yeah, there's like a goes like this. So it winds perfectly every time. Cool. And I've got a picture too of like what, what we had in mind for the system holding it up for the camera right now and it's on top of ClearPath robotics Ridgeback robot so you can see the box that it is the real there's a yellow it's meant to be Like a nine gallon Shopback that goes on top in this application here, I'll show it from another angle.

(0:45:11) Audrow Nash

Okay, so it's, it just looks like. So it looks like one of those small clear paths, or maybe not small, one of those clear path robots that has kind of the wheels underneath. And then there's a big cube on top of it, and it kind of looks like there's so I guess that's the Shopback cylinder that sticks out of the cube.

(0:45:31) Brett Aldrich

Yeah, exactly, exactly. Okay. And that's

(0:45:39) Audrow Nash

to get started with this. So the problem was to do level cabling. So you wanted to basically have the robot drive, and it would leave a cable behind it. And then you could wind back on the same path, and it would organize that cable as it retracted it, basically,

(0:45:58) Brett Aldrich

which, which required tight coordination with navigation. And, and then also tight coordination with what would be really the state machine of whatever the plan was to basically sell those to, to OEMs. You know, and so we knew

(0:46:16) Audrow Nash

that OEM is original equipment manufacturers. So let's say so that's like,

(0:46:22) Brett Aldrich

yeah, go ahead. Well, yeah, somebody like Dyson vacuum or something, you know, more probably more industrial, something like 10 internal fills, but But yeah,

(0:46:31) Audrow Nash

whoever was going to meet or know them, but I see. Yeah.

(0:46:35) Brett Aldrich

And so we knew that we were going to so we built, you know, we started with that software stack. And we moved all the way up. And we really did some beautiful work there. Some notable people to contributed on that project, Dave Coleman wrote something Oh, project. Yep. Yeah. He was this was before picnic, he was a graduate student at University of Colorado Boulder, and he wrote some of the original ROS control code. Vince Magyar, also worked on the project. He's the maintainer of ROS 2 control. A mathematician by the name of ROB Hanna from UCLA. And I did some, we mapped out all the mathematics where, imagine that level line system, you know, the goal is to know exactly how much cord is being produced with every encoder tick, but it's changing all the time, depending on how many, you know, layers of cord are on the real position of the level line carriage where the robot is the robot rotating. And so we did all that. I focused on the microcontroller code mainly. And that's kind of how I that that was more my background is I came into smack I was more like an embedded programmer. And that time, I thought that C 99.

(0:48:01) Audrow Nash

That's where it's at. Yeah.

(0:48:03) Brett Aldrich

That was my belief in anything involving templates. I looked it like, you know, I didn't like that at all. Yeah, Pablo country project too. And there was also a developer, from the former ClearPath developer named Devin Nash, he did some really great work on the project, too.

(0:48:22) Audrow Nash

Anyway, it's cool to see. It's funny to me that it's such a small community, in a sense, as in these names keep popping up for a lot of endeavors. Okay, so you worked on this robot. And so this was with real robotics. And this was the application. Yep. And smack was born from this.

(0:48:43) Brett Aldrich

Correct? Yeah. Because we knew that we were going to have to integrate with whatever the OEMs were using for their top level coordination, because you have to coordinate you'd have to coordinate the movements of the reel with the navigation, you know, the navigation of the robot, which we accepted. You know, we knew we were going to have to do custom work like that. But in order to, you know, develop our own demos, the idea of a state machine came in, also early on, I'm going to say so we started this in like 2015 2014 2015 by 2016, maybe even a little earlier, I realized that smash was not up to the task,

(0:49:28) Audrow Nash

and smash what Smash is that a filmer?

(0:49:31) Brett Aldrich

Oh, yes. Smash was smashed was a state machine library developed by Jonathan Bullrun, I believe in 2009. And it was a state machine that that powered the PR two examples. Yeah. I think very highly of that library. I think he did a number of very, very innovative things that that inspired SMAC probably the most important was Tying the events to actions, you know, like, like, like, like in the example you were describing to navigation finally gets to a goal that, you know, that then creates an event and you transition to the next state. Exactly. There were things though about smash that never fully. So I want to give credit to Jonathan Boren like for like, it was a, it was a creative and in essence a leap forward. I think in terms of though, like, it was never really suitable for like more of a production level of robotics. The concurrency always had issues, the data porting is another subtle problem. Anytime you see, in my opinion, anytime you see data porting and state machines, run,

(0:50:48) Audrow Nash

I don't know, I don't know what data hoarding is. Well,

(0:50:51) Brett Aldrich

it's in in Smash. When you want it to provide hierarchy, right? It was, you would put another smash state machine inside of a state machine. It was like, yeah, it was like you have

(0:51:11) Audrow Nash

that. And then you would forward state down or something or a well,

(0:51:16) Brett Aldrich

yes, he did. This is where it starts to get interesting. And how you move data around, it's a design patterns are common amongst state machine libraries, where people try to do that. I think it's fraught with, with problems, and usually in where you're trying to move data around, you know, and where you have to be explicit about where it goes, that doesn't really scale. Anyway, after so late 2015, or mid 2015, I'm looking at Smash, and I know that it won't be the library that allows us to you we can't use that one. And so I look, I looked at the market, and I didn't see any competitors. And I I saw a chance, you know where we could we could take a stab on writing our own, I knew it was a daunting prospect. But I don't know, I take risks every now and then. And and I I think I think I fell in love with the idea. I think if I try to justify it in terms of cold, hard business logic, it's sort of tough. But but we set out that way. And you know, I started on it architecting out what that solution would be where I would, where I how I would piece that thing together. And I settled on booth state sharp. Mainly one thing that helped me in that in that in that stage was that I focused solely on

(0:52:53) Audrow Nash

the C++ library booth.

(0:52:55) Brett Aldrich

Exactly. And it's template metaprogramming based, which is

(0:53:01) Audrow Nash

what was the what's it called? Again, the library to C

(0:53:06) Brett Aldrich

sharp state chart.

(0:53:09) Audrow Nash

Charts. Oh, okay.

(0:53:10) Brett Aldrich

Exactly. And that comes from David Harrell named his models of state machines state charts. So,

(0:53:20) Audrow Nash

huh. Yeah. Yes, an arm to it. Great.

(0:53:24) Brett Aldrich

And, and yeah, over. So we started that in approximate we started coding it in approximately 2017. Right at the end of 2017. Excuse me. But I had been working on it for about a year at that point, just like laying out the architecture. I use my intuition, largely, but I got pretty good intuition. And later, you know, as I learned more, I look back and I'm surprised how many of the decisions we got, right. Nice. Yeah.

(0:54:00) Audrow Nash

Okay, and so then real, real robotics. closed down or No? Was this? Yeah, so

(0:54:09) Brett Aldrich

what 2017 We began No, sorry, at the end of 2017. We began building the library. And very, very early, the market pull started to pull us in. So that call with click here.com that took place, I think in May of 2018. So it was as soon as we were developing it, we started getting calls. Then, we started working with gray orange. I'm going to say late 2018. So it's we started just being pulled into you know, one meeting after another and, and then two I picked up confidence as we proceeded. Yep. Ran into So at that point, we were developing both with both real robotics and smack, which later, we split off into Robo soft, but at the same time, we were pursuing them at the same time. That went all the way up until we announced the library in 2020. In June of 2020, we announced, wow. Okay. And we set out one to finish up the reel. And our plan was to launch them together. And

(0:55:34) Audrow Nash

launch the real launch what together both real and smack together, launch the company real robotics. And with and smack at the same time I see. Right? Yep.

(0:55:45) Brett Aldrich

And we ran into a mechanical issue along the way. So we announced the we announced smack for ROS, one in June. And we immediately set out to create it for ROS 2, because I realized that as we announced the library, that, that at that point, most of the most of the major players, were already moving into ROS, two. And so we immediately set out another version, and also set out to complete the reel, and where it's at now, the real works, we got a picture to have it like we and we built this thing. It's awesome. And there's one mechanical issue. And but the the market poll was just too great. And so I'm putting it down for a while and putting all of my focus on smack now. So you need to figure idea, you know,

(0:56:45) Audrow Nash

so think, by market poll, your meaning that there was so much customer demand, that it kind of sucked you away from real robotics. Yeah, um, suck the time and energy. Okay. Yeah. So then, what do you think? So? what is the what is the appeal of smack to these companies wire? Like, what are they looking for that smack is meeting? And why does it not? Why why are there not alternatives? And I don't know what, what why is smack so appealing to them? Basically,

(0:57:22) Brett Aldrich

I think I think the first part is that you've got a standardization at the application development layer, you know, smack can be viewed as basically an Application Development Framework. So I think that's, I think that's what draws them. I think the features of Smak then start to come into play. And the main or I'll try to go through a few important ones. One of which is that being a composite, smack. With smack, you can build state machines that are an order of magnitude more complicated than with almost any other library. The reason for this is the compile time validation. This comes from boost state chart. So have you ever heard of the N times N problem in state machine?

(0:58:13) Audrow Nash

Not I don't know what it is in state machines. So

(0:58:16) Brett Aldrich

it's, you know, I, it becomes intractable note, that when you have when you have n states, right, then you might need

(0:58:26) Audrow Nash

and transition the

(0:58:27) Brett Aldrich

transitions, yeah, to each state. And so it just keeps getting bigger and bigger. You know, like, if you've only got five states, okay, great. You got n times n is 25. But what happens when you have 20? States? 30 states? Yeah, that expansion. And this, I don't like I feel like the the academic treatment of the N times N problem is overly simplistic and misguided. But, but there

(0:58:57) Audrow Nash

isn't, it might be just more theoretical, and it might miss some of the application. considerations and application.

(0:59:06) Brett Aldrich

It's true. I will. And I also think it it's somewhat sloppy, versus it seems like big O notation, but without the without the rigor, I'd say. But anyway, but it is true that the larger your state machine gets, the harder it is to, you know, to manage that, or at least it can be. And yeah, and this also gets into one criticism of state machines is that they're a one way transfer of control. Right, like so when you go from one state to another. It's this you don't you don't automatically go back to the state you were in currently. And in that sense, they've been compared to go to statements.

(0:59:48) Audrow Nash

Okay, so I'm just jumping around

(0:59:50) Brett Aldrich

where you jump around. And while I think that's a bit of a stretch, there's a truth that if you go to the wrong place, then you're in big Trouble, right? If the if you if you're transitioning to a state and there is no state there, you know, we got an

(1:00:06) Audrow Nash

undefined. Yep. Right.

(1:00:08) Brett Aldrich

But what happened there is? So template metaprogramming arose, so

(1:00:17) Audrow Nash

does that. What does that mean? Yeah.

(1:00:20) Brett Aldrich

So um,

(1:00:23) Audrow Nash

so I'm familiar with templating and C++, Is it anything similar?

(1:00:27) Brett Aldrich

It's very similar. It's the same. It's the same type of

(1:00:30) Audrow Nash

and Meta Programming. Is it like lists? Like programming? And less is? That's what, but okay, what is that's a beautiful thing that happens

(1:00:41) Brett Aldrich

it, it happens at compile time. That's the key thing is that, like, so? Template metaprogramming by occurring at compile time. It's what sets it apart. And

(1:00:55) Audrow Nash

because you can have all sorts of compiler checks, rather than runtime checks or this kind of thing. No, that's okay. So because of that, you just run into a compile and build and whatever. And it's gonna go, and it's gonna suss out a bunch of problems for you, rather than you having to like test them. And see, so it's much faster and easier for the developer.

(1:01:19) Brett Aldrich

And that's right. That's right. Much safer. That's right.

(1:01:22) Audrow Nash

So can I take a stab at what template metaprogramming would mean, because I. So I'm imagining it's similar to what they do in Lisp. And I'm imagining it somewhat similar to what they do in C++. So it would be that you're writing code, and your code at compile time is going to like expand things, run them through functions, and then it will change what that function does based on arguments or this kind of thing.

(1:01:49) Brett Aldrich

Okay, that's more like function templates. Yeah. But it's okay. Same thing, right? How do I say that? In let's say, if you were if you were starting to look into, like the template metaprogramming that works in boost HRT, that would be like, the opening chapter. You would, you'd start there. Yeah. But then it moves into class templates. And okay,

(1:02:14) Audrow Nash

well, yeah. So you can do all sorts of objects this way. I mean, you could do functions, you could do classes, but it's fundamentally the same kind of approach, where things are parameterised. And it's generating stuff based on those parameters by following Yeah, by following a code path that you define, which is the meta template programming part of it, right? Yep, that's right. Something like that. Yep. Okay.

(1:02:37) Brett Aldrich

And in the, like, 1995, there was a famous paper by James Copeland, where this pattern called CRTP, and it stands for the curiously recurring template pattern was discovered. And it was discovered by independently by a few, but one of them was a female programmer by the name of Lorraine jewel. And it's that method was then taken by the developers of the boost libraries. And a lot of people don't know this about the boost libraries. But the boost libraries are all based on template metaprogramming. David Abrams was the founder of the boost libraries. And he wrote a library called MPL, so meta programming metaprogramming library. And then, two important state machine libraries emerged from that early periods of boost was founded in 2002. Libraries boost MSM, which was written by Christoph Henry, and then boost HR, which is written by Andreas Huber, Donnie, and both of them use CRTP to validate the state machines at compile time. And in in Andreas Huber, Donnie, is implementation specifically, it's a game changer, because it makes sure that you know, every transition has a source and destination, make sure that every state has a parent and state machine that it accounts for

(1:04:05) Audrow Nash

and a lot of compile time safety, basically, because of these validations. Okay, yes.

(1:04:10) Brett Aldrich

And I think too, you get yet, one thing I've got is that it's very easy to run a state machine library. The trick is making all the works. And, and the fact that it's compiled every time you're compiling, you know, you're getting checked. It just has a different different type of reliability, a different type of, you know, reusability and that's tied to that. Okay. Yeah. And hence, why I think we're, you're able to, and that in combination with state local storage is what allows blue state chart and through inheritance SMAC to to have state machines that are orders of now magnitude larger than what you would think if you believed in the n times n program. For instance, in the spec to repo today, there is a state machine known as SM multistage one. I wrote the state machine, it has over 165 states and over 100 transitions. Wow. You know, that big deal? Yeah. Like it wasn't that hard to write it didn't take that long. And if you mess up anything, you know about it at compile

(1:05:26) Audrow Nash

time? Yeah, that's really nice. Yeah. Okay, what? So you mentioned all this industry interest in why you mentioned all this interest in SMAC? Can you tell me some of the types of projects that you've been working on with it, or some of the types of companies or the problem domains that the companies are interested in solving with? Smack?

(1:05:51) Brett Aldrich

Hmm, trying to think of like patterns across them? I think the main one that has, has brought them at this stage, you know, to, to smack is the problem of concurrency. You know, basically, how do you control? And, you know, I think we would start with navigation, and at least one arm and maybe two, and then a perception system, and maybe a gripper, you know, just a some type of minimal implementation like that, although, as we saw in the field work robotics example, you know, quickly went to four. Other Other ones, let's see, what

(1:06:36) Audrow Nash

kind of what kind of domains or tasks are they trying to solve? Like, what is the task that you can accomplish? Look like with this? I suppose. Yeah.

(1:06:49) Brett Aldrich

One. So you know, one was a, like a self driving car. Another it's it's broad. It's broad. And yeah. Another one was with with gray, orange, there's was a, it was a, it was a two armed robot with two arms on a gantry that was in like a warehouse type context. And I believe it was used for folding shirts. Yeah. So. But again, we have multiple orthogonal, right, like multiple, you know, arms in one application. And then for field work, robotics, you know, again, like then the the, we have the expansion to multiple multiple arms. I would say that that's probably at this stage, the most important element is the the modularity that comes with orthogonality. Areas that I don't think have been touched yet, with Smak is the complexity that it can go to with the multi stage missions. I'm not where

(1:08:02) Audrow Nash

you so where would that go? What would be some problems that you could solve that are kind of like, pushing it to its limits? And complexity?

(1:08:09) Brett Aldrich

Hmm. Well, let's see. See if I can think of

(1:08:16) Audrow Nash

would it be like space related things? Okay.

(1:08:19) Brett Aldrich

Yeah, let me I'll try to freestyle a space related mission. Um, you know, one thing I've heard being talked about DARPA is where you can really bring down the cost of launches, right? Well, let's say you've got like some type of lat like some say, it's like a truck type device, but it navigates out to somewhere on its own sets up a launch pad and then launches into space, right? Transformer in that sense, you know, so you could have one, one mode state, that's for your driving portion. And you're going to need different recovery procedures, you know, depending on

(1:09:03) Audrow Nash

driving everything, yeah.

(1:09:06) Brett Aldrich

Then you go to you transition to the launch area, setup, state, state. And, you know, you're gonna have multiple sequences involved, there are different recovery procedures, etc, etc. Finally, the launch. And then, you know, again, it changes. And in fact, you're probably your orthogonal is would change, right? Probably like the physical subsystems that you care about. And each one of those contexts would would be modified.

(1:09:35) Audrow Nash

That's a cool concept. It doesn't make sense.

(1:09:37) Brett Aldrich

Yeah. And then to you know, if that trucks got to get out of there afterwards, what if it has to, you know, wants to launch and move on? Yep, that would be another. Another way. You just keep changing on and on. And I do for see. One, one bit of feedback that we've gotten that I think is important is that as people We'll start to use events in their programming, you start having an explosion of events, which is good, you know, but you just want to handle them more. And once you start using states to chop up your problems, you want more of them. I think that's, that's another interesting thing that smack does it. If we look at it almost from economic terms, it dramatically lowers the costs of creating states. Like, for instance, one of the the examples that I think it's sort of striking is, you know, the early 2000, for DARPA challenges, right, where you're, you're navigating across the desert. And I feel that that's still influences navigation, like even to today. He's a star planners and stuff like that, that make these very complicated, you know, plans, it's almost, and

(1:10:45) Audrow Nash

so just a little background. So a star has kind of an optimal planning algorithm that'll go, and it has a heuristic for how it proceeds. But it goes, the goal is that way, I'm gonna explore everything towards that direction. And when it arrives at a solution, it computes the optimal solution in the environment. So it's a, that's why it has the star. But okay, so when you're doing path planning, and you're using something that can get an optimal solution, this is as compared to like, RRT, the rapid random exploring trees, or whatever it is, which finds an approximate solution by kind of branching, it's not optimal.

(1:11:23) Brett Aldrich

Yeah. samples off of it. Yep. Yeah.

(1:11:26) Audrow Nash

I mean, you can use that and then optimize from the RT one. But okay, so you're saying we a star for exploration?

(1:11:35) Brett Aldrich

Well, it sort of as in my mind, the assumption that there's only one state, you know, that you've got to navigate from here to Vegas, in one state, maybe, maybe, right, which is, um, and I think when you start having like, readily available state machine libraries, where, you know, developers are familiar with them, you can all of a sudden start using very different tools to start, you know, chopping that problem up.

(1:12:03) Audrow Nash

Okay, so the basic if you didn't have to, so if it's complex, and you get your trajectory from some planner, the previous way of doing things was you put everything in one big state, and it's all very complex to manage, because you have to manage a lot of like internal variables to figure out how control should be handled. And so if you can chop up the state into small, clearly defined problems, and you can handle them very well. Because you can only consider what you need and have the like, you basically only have the problem parts that are required to solve the problem. For that one problem rather than everything kind of mushed. Together.

(1:12:50) Brett Aldrich

Yep. Yep. Okay, that also has interesting effects, you know, back to the client libraries and stuff like this. I, I think that one of the ways, or one of the ways that I hope it SMAC will influence ROS in general, is that it will bring down the size of the servers and and make them more manageable. So to give a little context, what do you mean servers? Sure. So let's look at move it and enough to. So I'm gonna throw out some statistics. I don't know exactly how accurate they are. I'm sure there's people with more accurate numbers. But I remember speaking to Mike Loughton at a picnic, and I'm sharing with me that the move at code base was something like over 100,000 lines of code. I get huge, huge. And I also I have a tool that attempts to tell me how many lines of code are in something and I ran it on nap two, and it came back at 111,000. Okay, so that's sort of shows like a level of complexity in here. And some of these like extremely common.

(1:14:03) Audrow Nash

Right, I see what you're saying. Yeah. Because because you can divide things up. They don't have to get so large. Yes, one. Yes. Okay.

(1:14:12) Brett Aldrich

Much simpler planners. Exactly. And that's also important too, in that, from our own experience of developing examples, the place that we really like you just start burning developer hours, is fiddling with the the settings on these black box planners and, and checking them out during runtime and simulation. Just, there's just a slowness to it. And the way that that everybody is generally interacting with these is, okay, so you write your own note, write your own, which is essentially like a client that's going to interact with with nap to let's say, and I don't know, what would you say that they started 60 lines of code, maybe 200. And then they, you know, we start building out your application, maybe it's like 1000 You know, at some point

(1:15:01) Audrow Nash

So you're saying 1000 lines of code and relative to all the way out to?

(1:15:07) Brett Aldrich

Yeah, exactly. That's a small thing interacting with this massive, you know, we it's like we put all the complexity over in, in these giant servers. Right now and just

(1:15:20) Audrow Nash

by by server, you mean code base effectively? Yeah, like we're referencing it as a dependency in our code. And a lot of logic is being done over there in their code, right here.

(1:15:31) Brett Aldrich

Okay. Yeah, that's exactly right. I'm currently, so we did we, we finished up some of the work on our nav two Zed client today. So this is the the client and smack two that we use to interact with navigation. And it's coming in at about 7500 lines of code. And this is all written by this. This is written by Pablo, but Pablo is an expert in navigation, you know. And so I'm imagining a world where if SMAC becomes a standard, right, and these clients become a standard, you end up interacting, like that balance between, let's say, 1000 lines of code in the application in 110,000, in something like NAB two rebalances to something like 10 to 12,000 lines of code and a client. And then my hope would be that, let's say nav two could come down to 70,000 lines of code 65,000, something will you get

(1:16:30) Audrow Nash

by using less lines of code? I'm sure storage and compile time and things. But what are the benefits?

(1:16:39) Brett Aldrich

Well, there's those and those add up, you know, if you figure it out time,

(1:16:43) Audrow Nash

yeah, yeah, right. Test time.

(1:16:45) Brett Aldrich

Yeah. I do agree that, you know, measuring this in lines of code is a crude, you know, it's a crude metric. But I think what you what you can get is, I think it would be easier for the developer teams at places like naff to and move it to, if they knew that the users were going to interact with their system in like a defined way defined by like these clients. Right? If if half of the ROS community interacted with move it to through a smack client, right, it would sort of like narrow the interfaces. Yeah. Yeah. And you basically get more like focus, less code easier to maintain. And then also the simplicity, you'd have more more planners, simpler planners? That would be easier in

(1:17:42) Audrow Nash

that sense. Yeah. And one, one advantage to that, that I see is, say you want something to be like space certified, or some high level of security or you basically, the code is really hard. And for safety critical situations, you can certify only a small chunk of a larger library, rather than the rest of the library. So like, I'm sure certifying 10,000 lines is a lot easier than 100,000 lines. Yeah. Yeah, that's right. This kind of thing. Yeah. Let's see. And so one of the things we were saying before we started this interview was you see the application of SMAC really being for industry users? And, as opposed to, like, hobbyists, or this kind of thing. Can you speak on this a little bit? Maybe I've gotten that wrong, but

(1:18:34) Brett Aldrich

no, I think Well, I think it's true. It's, I mean, I hope it's Mac is used by beginning developers, and I think it has a lot to offer, you know, beginning developers, but but I don't want to, like shy away from the question that when it comes to design decisions, you know, that are going to be made. And let's say the design decision comes down to a choice between making them more friendly for, you know, new developers, or, you know, being able to meet one day a safety certification or something like this. I always side with the more high end side, it's more important to me, that smack runs on the most important robotic systems of our era than it is, you know, I'm not counting every developer that uses it. Where, though, that goes, you know, it back to the bifurcation, though, that I'm seeing in ROS, you know, especially as I look down the road, is, seems to me that we've, we have on one hand, like a research community, and this is like students, graduate students, people who are more focused on usability and getting up very quickly. I think they tend to be more focused on their algorithms. And so this would be somebody who's using like a Python node or something, they want to get their system up and running quickly. On the other side, you've got those like smack that are that are trying They're more focused on actually running in production. I think also the work with self driving cars has really led the way here. And I love to like for inspiration and where I want to go next with smack, I look at auto where I look at the work coming out of APEX a I mean, it's beautiful.

(1:20:17) Audrow Nash

Yeah, absolutely.

(1:20:20) Brett Aldrich

But it has some interesting features to it. Um, so, and we've done this with our own library, we've, you know, we brought in a more complex continuous integration system. And, you know, with that, I think we have something like seven, seven checks that we go through on every pull request. Every check, we add makes, it's just one more step that a new developer would have to go through to submit a pull request.

(1:20:50) Audrow Nash

These might be like, run the tests might be like, do a linter, check to make sure the code is formatted. Right. So you're saying,

(1:20:59) Brett Aldrich

you know, yeah, exactly. Like, you know, and hopefully, automation can help lower that burden. But But I think, too, is the libraries like this get, you know, grow more complex. It's tough environment for beginners, you know, favor, the more seasoned, focused, I don't wanna say professional, but I want to say focused, you know, where you're focused on a certain problem set and not kind of coming in quickly wanting to get something fast. I recently, as a, as a library, I won't mention it specifically. But there's a library out there that I admire very, very much. And in researching it, I, I was going through the documentation, and I found a couple of like, very minor errors, the guys English is probably their second language, and so that, you know, a few minor grammatical changes. So I opened a pull request to change it. And there's a 20 step process. You know, this, this board request, and I quit after like, step six, I had other things to do, and I pulled out of it, I'll continue it. But I think it just sort of highlights something that we're going to have to deal with as a community. And I, again, I see this sort of bifurcation between these two different camps.

(1:22:22) Audrow Nash

So one thing that I find interesting is, like in the web developing community, you have really high quality, difficult, give you everything to play with libraries, like I think it's d3, JS, d3, it's amazing library. It's data driven. It's really nice, beautiful, beautiful, beautiful. Yeah, amazing. But so that one is incredibly difficult to get into as a beginner, like I played around with it a little bit. It's very, it's awesome. You can do great things, but they're very time consuming to do, but you can control everything. Whereas then there are I don't know, maybe like chart j s or something that use d3. But they make it a bit easier for users that are more casual or just want to get something working quicker to play around with it, or to do something, but they don't have access to all the knobs and all the customization without going into d3. JS. Yeah. Do you imagine? Similar? Yeah. Okay. Well, I wanted to make sure I'm saying the right name of something. But yeah, so I mean, it's wonderful. But just it's lower in difficulty than d3. Do you imagine SMAC? Following some sort of model similar to this to make it more beginner friendly?

(1:23:45) Brett Aldrich

Yeah. You know, my So yeah, this is the dynamics, I see it play there. Um, I think that the, that what smack, the advantage that smack has is that smack as your application grows, smack can handle it. And so what that allows for is the creation of these client libraries that are developed by experts, but basically encapsulate much of the higher level function, and no, you couldn't, or you would be foolish. So let's just say we're taking navigation as an example, right? I think it would be foolish to write a client, like nav to Zed for a state machine library that couldn't handle if it got to a certain level of complexity, and then that state machine library couldn't handle it anymore. You'd be foolish to write a client for it. But because SMAC can handle almost anything that you would throw at it in terms of state machine complexity. It opens the door now for specialist developers to write client libraries. That's my number one goal as we move into, into 2022 is to expand the Every horizontally with new clients and new client developers. And in that sense, I think that's one way that we can kind of escape this trap. You know what I mean? This, this, this, this d3, you know, where it's like always, you know, if you go for high icon, if you get with capability, you can't use it, you know, that, like avoiding that, that? Yeah. And then the second part of that is cogeneration. I think, I think when when we start getting cogeneration capabilities that are graphical, it, you know, yeah, to bypass all that,

(1:25:38) Audrow Nash

you can just like visual block program, a complex robotics application, that actually does something, which is not, yep, that will be super cool.

(1:25:50) Brett Aldrich

Yeah. And in there, you know, then the complexity, it wouldn't hurt you there, either. Or you'd bypass it, you'd be able to kind of abstracted away

(1:25:58) Audrow Nash

in the blocks you use. Yeah, yeah. Um,

(1:26:03) Brett Aldrich

and, and then also has another, like, it brings in another type of efficiency where it's important. So the SM reference library, you know, the minute a developer comes, they can they can get started with a state machine there that's guaranteed to compile and run. Simulation is set up. But I think the other way to capture greater efficiency is on the back end where you don't, you don't have to upgrade. You know, for instance, back to that, that DARPA team we were discussing earlier, that started off with four states, their state machine eventually grew to 15. Now, let's just say that it kept going, you know, and now they're 45. And it's not working anymore. You know, like, the things that they were dealing with? Probably they don't, who knows how they're visualizing it, you know? Yeah. But if you're in a library, like smack that, you know, can handle that growth, well, then you never have to refactor or transfer your code base. And that's a big, you know, that's another like form of deficiency that I'm hoping that, that we can verify.

(1:27:10) Audrow Nash

Yeah, you had that foresight. And you can see, oh, eventually we're going to need it. Yeah. See, there's there's several things in that I've seen that are similar, where they're like, you're going to need to use this. So might as well use it anyway. Kind of thing. Like might as well use it to start. Yeah.

(1:27:27) Brett Aldrich

Gotcha. And into your architecture. Yep.

(1:27:30) Audrow Nash

Now, I know. So we are running out of time, we were booked for two hours. We're coming up on the end. Are you okay to go a little bit longer?

(1:27:38) Brett Aldrich

Yeah, let's do it.

(1:27:41) Audrow Nash

So one thing that I want to so SMAC is basically for control, high level control of robotics applications. How does it compare to other control patterns, such as, like, behavior trees, and I don't know, whatever other whenever I what other things exist?

(1:28:04) Brett Aldrich

I think I think with behavior trees, you know, well, okay. Well, I guess the key question there is, what do you mean by exist? If we're talking about, or patterns

(1:28:15) Audrow Nash

that developers use now for control of robots that are doing reasonably complex applications, you know, control in existing applications?

(1:28:27) Brett Aldrich

Yeah, you know, I'll be honest, in that there really isn't much available. It's hard to comment on it. You know, because there's, there's, and I think this is one of the real it's a problem for us as a community at the moment, is that it within the answer is we need more demos with links to the source code, you know, because I think a lot of it sort of reminds me in the days, you know, for those listening off camera Audrow And I before that we're talking a little bit about, we both have an interest in jujitsu. And it reminds me in the moment of like, the days before the first UFC where, you know, what would happen when when a kickboxer fought a sumo wrestler like no one really knew, you know? And? Yeah, I feel like the demos with the sort with links to the source code are a crucial part of showing like, Okay, well, you know, if it can do it, let's prove it. And from what I've seen, is, you know, of what's out there. It seems like most people are rolling with like a roll your own solution. You know, they're starting off with like, I don't know, maybe a state pattern or something like a gang of four kind of pattern. And it's good, although, I think it leads us to the sort of thing where they develop something that's pretty cool. Let's say it's 1520 states, and then it's but they can't maintain it. And so A lot of that work is lost, you know?

(1:30:03) Audrow Nash

Yeah, nothing, nothing generalizes. Like it's hard to pull components from it, it's hard to grow the application any larger. And it's also intertwined with the state representation that they have already, that it's very hard to pull out the parts into a different way of organizing them, perhaps.

(1:30:24) Brett Aldrich

Yeah, yeah. And, and I think that hurts us all over the place, you know, where? I mean, they, you know, for instance, and I know, we're trying to harvest what's coming out of the DARPA subterranean challenge. But I think we'll be lucky if we get a couple of planners. We'll get lucky if we, if we get a few algorithms, but I think the prospects of us finding like some type of state machine architecture that we can pull out, I mean, very low, very low, it would require, it would require an advanced team. I'm going to adjust my lighting here a little bit. Yan is going down one moment. Has this a better? Very bright? Yeah, yeah. Okay, cool.

(1:31:18) Audrow Nash

So, yeah. And then, so we just, um, can you speak a little bit about the differences between state machines and a state or a behavior tree based approach? Just kind of at a high level? Because

(1:31:33) Brett Aldrich

high level? Yeah, the, I think the the most fundamental differences between this one way and two way path of control. So in that sense, state machines are, I guess, more like a go to statement, although I, I have problems with that analogy. Whereas behavior trees are more like a while loop. You know, when, when you look at a behavior tree, and it's the ticking. That is like the key part that makes it a while loop, right, that you tick through all the

(1:32:10) Audrow Nash

skills, you keep polling the current state or something, too. So just just to just give a little background to those who don't know, for the behavior tree, just an example of what it might look like, is in a video game, I think I read on your blog, this MAC one, that Halo two was the first video game yeah, control before? Yep, yep. So what they would do an example of how a character might be controlled in a state machine. So in Halo two, for example, if you had like, one of those little grunt, aliens, it might, if it doesn't see you, it might just be kind of idle. Or actually, I, let's see, actually another example. Because I'm going to get confused with that one, I'm kind of going into a state machine direction. If I have a character and it wants to get into a house, for a behavior tree, that behavior tree might go and look to see if the doors open. And if the door is not open, then it might go see if it has keys. And if it has keys, then it might use them. And if not, it will go and see if someone like try to knock and it progressively goes through these things. Eventually, it might be like, is there a window that can be broken to get inside? or something? But it's a series of like steps that are all like conditioned on each other? Do you agree with that or anything?

(1:33:41) Brett Aldrich

I agree. Okay, that conditional approach to end the polling,

(1:33:47) Audrow Nash

the polling part is that at each time you go, what have I tried before? And it kind of brings you down each of the leaves for this? And that would be like, Have I tried keys? Have I tried this? Have I tried that? Okay, I'm here with try next, this kind of thing.

(1:34:04) Brett Aldrich

There's that. And, and then there's no events? And I think that's now that this is true for behavior trees dot cpp. And in a number of other behavior tree libraries, I think.

(1:34:19) Audrow Nash

So there's no events, that means it's hard to have an event trigger something in the behavior. That's right. So it's kind of weird, because it's based on like an existence of the state. Oh, I see why that gets confusing. Because if you're running through your statements, but then all of a sudden the state changes now you have to like recall everything. That's right.

(1:34:41) Brett Aldrich

That's right. And that's if you have, that's when you start to have So in a normal behavior, how do I say this? Google so so behavior trees originally came out in 2004. And they you got started in, in, you know, games modeling, they call them NPCs, non player characters, which I have a number of problems with in a robotic context. I mean, these, these creatures don't have any kind of control system, they don't have any kind of orthogonality, there's no liability. Then those, I'm gonna call that the first generation implementations, they did get some success in the gaming world. And so and I think for that reason, people thought, Okay, well, we can use them from robotics, because Robotics has always been, we've always stolen from every other field out there, right. But later, well, as of today, right, there are no behavior, I'm 99% sure that there are no pure behavior tree implementations left in the gaming world, and those that remain have all moved over to event driven behavior tree mouse. And event driven behavior tree, what you need is you need a, you need another thread, you need like an observer thread, you know, to check your events coming in, amongst other changes.

(1:36:13) Audrow Nash

So that's it just just from like, a high level to see if I understand what it is that you have the two threads, you have the one checking for events, what kind of so an event occurs, something has changed. Now your state diagram or your behavior tree, would it just like change all of a sudden?

(1:36:32) Brett Aldrich

Good question. This this, this would depend on the implementation. I know of two different methods. One of them is like, yeah, you just repol everything in the tree every time an event occurs. And that's like, that keeps it more similar to the original behavior tree design, I guess. And then there's a second model where you're keeping track of all it's a more advanced method where you're keeping track of everything that's happening at that point. I question. I mean, I think you've actually got a state machine only, you're keeping track of state in a set kind of way. Yeah. The thing about event driven behavior tree libraries, is that I think they're highly experimental. I mean, there's only four that I'm aware of, you got Unreal Engine, you've got one for unity called MP behave. And that's like a, like a third party plugin or something. I don't like, whatever. Okay. Yeah, it's like, it's like a, like a plug in type deal, then you've got the Cry Engine, which I don't know that much about. And one other one, that doesn't count either, it's not important, the only one of those that matter in any sort of way, to me is unreal engine four. And the big difference there is that they these, they cannot handle concurrency. You cannot. If we look at let's say the implementation of Unreal Engine four, right, the only event driven behavior tree library that I can think of, they don't support multiple orthogonal. And in fact, if somebody cares to look into it, in the documentation, you can look up the simple parallel node, where, you know, this would have been the node where they would have handled in their parallel nodes, you know, you could have multiple orthogonal, they punted, you're only allowed to have one a synchronous one, and one synchronous, and that's it. So you would never be able to run like the kind of orthogonality that that would be required on that field work robotics robot that we saw, or let's say, let's say some type of like military submarine, you know, where, who knows what they're gonna or like, hell, like an Apache helicopter, where there's something like 48 sensor systems. Yeah, and complex sensor systems, right? Not just not just like a proximity sensor, right? But instead, it's like a 3d scanning array, and IR scattering the rig. And so to me, that's the that's the main difficulty. Now there, there will be a lot of debate. I've been involved with debates with the proponents of behavior trees. But that's that's, that, to me, is the most immediate, short term shortcoming they have I also suspect that that there will be a way to prove mathematically that one state machines are more well, I know that you could prove mathematically that state machines are more expressive simply because the N times end problem is a is a. The flip side of that is that you have finer grained control, you know for instance, let's See, I've got a 200 state state machine. And at state one nine, you

(1:40:04) Audrow Nash

can explicitly go from each of the states to every other state. Yeah.

(1:40:08) Brett Aldrich

Handling, like certain corner cases. So in that sense, I think the the ideal that you get more

(1:40:13) Audrow Nash

probably way better for testing. I imagine it's much easier to test all the state transitions explicitly, with this kind of representation.

(1:40:22) Brett Aldrich

I would think so. Yeah, the fact that you can do a lot of it at compile time, I think that's true.

(1:40:26) Audrow Nash

Anyone, like, if I want to simulate the robot for like, additional testing, so like, I know, you can do a lot of the compile time testing, which makes sure everything has a connection to everything, or to so all the connections are set up. But having like, if I wanted to run in simulation, I could target each of the transitions for a candidate for testing, which would be nice and explicit.

(1:40:52) Brett Aldrich

Yep. And then to with this gets off into, like, where I see the future gone, but fellow, in studying the history of state machines in different domains, and I've studied them in the electronics domain, the, the, I call it computing, I've been able to track down the earliest state machine and a computer to the 1965 version of the IBM Oh s 3/61, one that I was able to find in documentation where you see a very simple state machine on the computer. But in the in the networking domain. You see state machines arising from almost the beginning, the beginnings of the field of protocol engineering. And TCP IP is a giant state machine. But one of the things that happened in the late 70s was they started creating, like dual state machines setups, where one state machine would test the protocol of another state machine, totally automated. And there were cases in the development of ARPANET where this technique exposed something like 256 bugs with without any human involvement. Crazy, got me thinking about like, Okay, wait a minute, how do we start creating? Or how do we start changing our automated testing, right to start incorporating state machines on each side testing the other state machine? This is one of those areas where I, you know, I have hopes for new fields, new fields to arise and new types of efficiencies to be gained. But back to the behavior trees, I think, I think at the application layer, I'm yet to see an example of behavior trees, where we've got a demo and the source codes, side by side in robotics.

(1:42:51) Audrow Nash

Does that mean evaluate?

(1:42:53) Brett Aldrich

Oh, yeah, that makes it hard to comment on. And I, I don't know, I feel that, that we're trying to deal with that problem of complexity, in a sense by saying, Well, you don't even need state machines. And I have a hard time, I have a hard time going down. That said, I do want to say that I believe in freedom. And although I may disagree with something, hey, I want people to know the way they want to code. And, and let the best man win. Let the best man win. Let's let's you know, going back to our discussions about jujitsu. I was listening to an interview with Hickson Gracie the other day. And he was asked to compare the cultures of Japan where jujitsu originated in Brazil. And what he said was that, you know, Gracie Jiu Jitsu could only have originated in Brazil, because the difference in culture cultures were in Brazil, there was not this sense of respect that there wasn't like, you're very, very respectful. Right? Okay. In Brazil. He said No, like people would show up at my father's studio in the middle of the night and want to test us out with a fight. Wow. Yeah, it was it was like the like you had to be ready to, to duke it out at any moment. And I think we need a little bit more of that in ROS. But you know, let's, let's put the players on the field. Let's let him

(1:44:26) Audrow Nash

on. And let them evaluate.

(1:44:28) Brett Aldrich

Definitely. Yeah, I think that I think the community benefits. Yes, yeah. Cuz

(1:44:33) Audrow Nash

you get to evaluate the ideas and actually compare them fairly. And then juice from there. What do you so going forward? What's the future of snack look like? Where you guys going with your implementation? And what do you see in the next few years?

(1:44:50) Brett Aldrich

I see too, you know, a few years. I don't look that far down the road. I'm more like looking down on your quarters to 2022 and that I think there's really two things that that we need to do, the first thing I need to do is I need to expand it into more of a community project. And one of the things I'm looking for there is a talented pedagogue, because I'm not the guy to, to teach newbies about smack, I'm gonna try, I'm gonna do my best. But I know that there would be somebody out there who's better than me at doing it. And that I think, is probably the biggest weak point of the library at the moment, partly because of the way we bootstrapped it. But we could use a lot more documentation, we could use a lot more tutorials, and, you know, fostering almost into more of a community beyond just the robust soft team, which is where we're at currently, I would say we've got a handful of people who've committed pull requests, but it's a handful, and, and for what I want to accomplish with the library that needs to grow substantially. And then the second thing is the horizontal growth. And that's basically new clients. So clients, four legged robot clients for naval, ps4 is another one that's like really high on my list. That's drone community, correct drones, but you could also use pics for based systems for like underwater sub stuff like that.

(1:46:22) Audrow Nash

So cool. Yeah.

(1:46:25) Brett Aldrich

One an autoware. Client. I really think that that's like, that would be very cool. Yeah, opens up a lot of possibilities, particularly for multistage missions, like we were talking about earlier. Other ones, let's see, there's the moose system for naval. Would you call it but basically, naval robotics? And let's see what else? I would say that that's basically it, though, the idea of horizontal integration. Yep.

(1:47:00) Audrow Nash

And then wrapping up? What advice do you have for someone who is just getting into robotics?

(1:47:10) Brett Aldrich

You know, I'm very hesitant to give advice to anybody. I'm not sure they want to do things away. That's exactly the smoothest route. But I would say this, if someone looked at my career that they would find, and a lot of this hasn't been public, because it was what the real. But over and over, I've gone into development projects that I really had no business, succeeding, you know, it would like if you if you look before, like, what would what would this guy's odds of success be? You think they were low, and over and over, I've come out of them on top. And I there's one secret, and that is have a spec, not even have a good one, just have one. I originally got a spell book, spec, I'm talking about a design document, minimum three pages, but it can grow, you know, but it's where write it down. Particularly if other developers are going to get involved. You know, it's, it's, it's just, you'd be surprised. I've ran into people whose credentials were so they looked so good. And, but they didn't write a spec. And know, the code wasn't that good. You know, when you have one, you'll notice you know, that? No, like, even the again, you may not have that much experience, but with armed with a spec you can do, you should believe in yourself.

(1:48:45) Audrow Nash

Gotcha. So you, you basically you think it through and you develop some sort of spec sheet. And with that you're a lot more focused and able to kind of knock down the task to achieve something rather than not being focused through and trying to, I don't know, you're not focused on the end. If you're, if you don't have a spec, maybe? Yeah,

(1:49:08) Brett Aldrich

I think too, it allowed me to, to identify difficulties problems. And often there were multiple ones, you know, like, like in something and overcome them, you know, and start to like, get your, they start to get your grips on a problem, you start to come up with solutions. Often that don't work. But yeah, and I've noticed it more and more that when I like, if I'm working with something I say, Well, do you have a spec, and it's rare. It's rare, but and that originally, I originally got that idea from the book, Joel on software. And that's from Joel Spolsky, who was one of the original Microsoft program managers at a time when Microsoft really led the way in terms of how to produce code. And so that's really the that's really the The one piece of advice I would give, I don't know if it'll be enough to accomplish, you know what someone would want to, you know? First, you gotta have a goal. And I don't know if a spec alone will get you there. But without one, you're done.

(1:50:16) Audrow Nash

Awesome. Okay. Now, do you have any links or contact info or anything that you would like to share? Yeah, so

(1:50:26) Brett Aldrich

roba soft.ai is our website. And then the other place that, you know, for, especially the audience of this podcast, is the smack to repo on GitHub. And, as always the most updated source of or up to date source of information regarding the repo. And I guess the last thing out there is, if you're a developer, and you've got an idea for a client, or like a smart client that you want to develop something like nav two, or we have nav two and move it and ROS 2 control that if it's something like PX four, or moose or autoware. Get in touch with us, we will support you and we want to hear from you. I'm looking for artists, globally.

(1:51:16) Audrow Nash

Awesome. Cool. All right. Thank you

(1:51:20) Brett Aldrich

very much. I really had a great time. And it's an honor to be interviewed. For those just tuning into this podcast. I'm Tony The sky is the Charlie Rose of robots.

(1:51:31) Audrow Nash

Thank you. Hi, everyone. Thanks for listening to this conversation with Brett Aldrich. Thank you again to our founding sponsor, Open Robotics and I hope to see you next time