How Rust Could Change Robotics

Drew: Let’s start off getting some background on you, and then we'll talk about some of the things you're doing right now. In my experience, people who are into robotics either start with software and then learn the hardware or vice versa. Which direction did you come from?

Carter: A little from column A, and a little from column B. I took a couple programming classes in freshman and sophomore year of high school, and then I ended up transferring schools. In the high school that I transferred to, they started a robotics competition team. That ended up being a huge life changer for me. There was a geometry teacher at that school who basically grabbed me by the collar and was like, “you're going to be on the robotics team because no one in this high school knows how to program except you.” So I ended up on a robotics team in high school and it became a full-blown addiction. I got an internship at a robotics company through one of the team mentors. By the time college came around, I'd known how to program for four years and had been working part-time as a robotics software developer. I even did a work share thing senior year so I could spend a lot of time professionally programming robots in high school. What a crazy opportunity! Anyway, I felt very confident in software before going to university, and I had this super fortunate resource in that my older brother had also gone into robotics. Right as I was entering undergrad, he was doing a PhD in robotics. So, we kinda chatted over my plans. I landed on getting a mechanical engineering degree, somewhat intentionally, so that I could be interdisciplinary. I felt like I already knew the software well enough. So, I got a mechanical engineering degree, which was very far outside my comfort zone at that time. I also took as many electrical engineering electives as I could. And, it was all just kind of setting myself up at undergrad, like I'm gonna be a robotics engineer, I'm gonna know everything.

Drew: That's really cool that you were able to be involved so early. I don't think I could have dreamed of having a robotics team in my high school.

Carter: It was incredibly lucky. I've been a coach of a team now for six or seven years. I'm wearing one of their shirts. I go to the competitions and that geometry teacher that grabbed me by the collar is there. We get to battle our teams against each other now. But yeah, the opportunities that high school robotics programs create for kids are amazing. The kids are incredibly smart, and they get great real world experience. I'm a full convert to high school robotics.

Drew: What high school is it?

Carter: For me it was Jackson Hole High School in Wyoming.

Drew: What's the team you coach now?

Carter: They were at Fairview High School which is on the south side of Boulder, and I moved them out of Fairview a while ago. So they actually operate out of the MakerSpace in downtown Boulder right now, and I have kids from seven high schools.

Drew: So I was looking at your work experience, and I saw you had a couple of interesting stops on your path to AMP. SpaceX was one of them. That’s a big name. I don't know how much you're able to talk about your time there, but what did you do there?

Carter: Yeah, coming out of undergrad my plan was to go to grad school. I'm the only one in my entire family that doesn’t have a graduate degree. So, I just thought that was the way. I was accepted for a PhD at Georgia Tech or a master's at Carnegie Mellon. I was kind of sorting out those options, and then I threw a resume in at SpaceX randomly. I didn’t think much of it until I got a call to interview. After four years of college, I decided maybe working would be better. So, I made that pivot last minute. I ended up working in a group at SpaceX called Vehicle Operations Development that was automating handling of the rockets at the launch sites. Most of the work was happening at Cape Canaveral. The group was building stuff for picking up the rockets, turning the rockets around, and so forth. I worked a lot on getting software control of the cranes inside the hangars. The group I got hired into was nothing but mechanical engineers. At the time SpaceX was suffering from a little bit of tribalism and work blocking. The group was responsible for building robots, but it was entirely mechanical engineers. So, the mechanical engineers would design the robot and then they would be blocked for months waiting for electrical engineering groups, which would then wait for software groups. Getting a whole integrated system together was a real challenge. So, I was hired to be a software engineer in the mechanical engineering department. I did almost nothing but write software for them.

Drew: Let's go ahead and get some foundation on AMP. Do you know the founding story of the company?

Carter: Yeah, so Matanya, who's one of the cofounders, finished his PhD I believe at Caltech and then founded the company right away. The original funding was an NSF grant or something for applying AI to recycling. So, he called up his undergrad roommate James Bailey who I'm good friends with and they started the company in the Denver-Boulder area. It was very scrappy early on. A lot of the original prototypes were written by Matanya and his brother. They got some angel investment from former bosses and such.

Drew: Can you tell me a little bit about AMP’s problem space?

Carter: Yeah, and maybe I'll answer this in a way by adding to my previous answer. One question is', Why recycling? Why would this hotshot PhD roboticist decide to go and sort trash? And, Matanya deserves an enormous amount of credit here. He was really serious about going out into the world and finding a problem where he could make a difference. Anyway, he felt like there was a real opportunity for innovation in the recycling industry. The broader waste industry is really archaic. There's just not a lot of pressure to innovate. So, there were not a lot of players in the space. Matanya noticed that all the tech people didn't want to get their hands dirty sorting trash. And, a lot of Matanya’s peers said this was impossible. But, the big unlock came from a shot that Matanya called from like five miles away. He saw how neural nets were improving at object classification and bet they were going to be able to do recycling classification well enough soon that he should start building a company around it. He was early by probably like two and a half years, but sure enough they got good there. By the time neural nets were ready, AMP already had the datasets and everything in place to take advantage of the opportunity.

Drew: That reminds me of the story about Reed Hastings telling early Netflix employees that the business of mailing CDs was just a way to get them ready for when Moore’s Law would make streaming possible.

Carter: Absolutely, there’s a real parallel there. When I first came to AMP, I was pretty unsure this was the choice I wanted to be making. And, I'm here in decent part because I called around the industry to ask about Matanya, and he had like the golden boy reputation. People would be like, “I don't even know what AMP is doing, but if Matanya is doing it you should probably go work there.” Finally, Matanya took me out to dinner and I was like okay what's the plan? At the time, they were just getting their first pick and place recycling robots off the ground, and he didn't talk about them at all. Those were just the flywheel that was going to let AMP eventually build whole new recycling facilities of the future. And, that wasn’t talking about incremental improvements, it was like we're going to bring the cost down by 90%. So, it was a similar thing where there was this long-term vision of how technology could disrupt an industry.

Drew: So in that vein, one of the questions I did have in terms of bootstrapping things is how did the initial data set get put together?

Carter: Yeah, AMP got incredibly lucky. A lot of people will talk about this with startups, but your first customers matter so much. We were lucky in that there was a recycling facility 15 minutes from the headquarters that basically gave us a stretch of conveyor belt and said do whatever you want. So, the original team immediately just slapped a camera down and started uploading frames to the cloud. That's where it started. When I joined the company after it had been going for two and a half years or something, everyone in the company was labeling frames of recycling to build that initial data set. Like nobody worked at the company who did not label frames.

Drew: That's so hardcore!

Carter: Yeah, and AMP was early enough in the object classification game that there were not off the shelf solutions for building your own data set. So, we had to write our own labeling tool from scratch. Nowadays there's like 20 companies pounding down our door. So, we ended up building an enormous amount of infrastructure from scratch for better or for worse.

Drew: That makes sense. So, is automation really common in the industry as it sits right now?

Carter: Automation to a point is kind of the status quo. A lot of the actual sortation that happens in a recycling facility is done by physical separation in different forms. For example, in some cases there's different kinds of mechanical screens and filters. Usually those involve paddles and vibrators that try to get most of the paper over here and most of the plastic over there. That kind of thing. That's all literally like 1800s designed equipment. The other dominant piece of technology that's been in the industry for a long time is what’s called an optical sorter. It’s a line scan camera that's usually hyperspectral. So, it sees dozens of colors of light in different wavelengths that different plastics respond in and then that material goes past a series of air jets that hit the material. Those hyperspectral optical sorters are kind of like late 90s early 2000s tech. There's a company based in the Netherlands called Tomra that AMP likes to compare itself to a lot. That's like a 10 billion dollar company today. They’ve sold thousands of these machines around the world. But, optical sorter machines get the material to like 80% purity at the end of the day. So, the standard template recycling facility has machines doing probably 70-80% of the sorting, then there’s like 30 or 40 people standing on conveyor belts doing quality control sorting to actually bring the material up to sellable quality. That's been the way that you run recycling facilities for a really long time. So, AMP’s first real product that we got traction with were these pick and place robots that could pretty quickly just drop into an existing recycling facility and replace those people at the end of the line.

Drew: I want to hear a little bit about what you do day to day. I think your title is robotics architect, so what does a robotics architect do every day?

Carter: It's a bit of a grab bag position. I think my LinkedIn tagline is “still figuring out what this means.” It’s the type of position that occurs naturally at a startup. But, I know a little bit about how everything was built and how everything was put together and have a lot of legacy context that helps people. I'm also very fortunate to have a pretty broad mechanical and electrical and software background. That's not how a lot of companies organize. AMP has tried a lot of different versions of how to manage and coordinate projects that are interdisciplinary like robotics projects. And, the traditional solution that a lot of companies employ is something like an engineering product manager that coordinates all the work. That can be super helpful, but what we observed is that when you have each discipline operate in isolation with a technical person stitching all that together without knowledge of each discipline, you get a lot of lopsided designs. So, a lot of what I've been doing is going into all of the projects and programs at the beginning and trying to set those up for success. I set the technical foundation for each project, and the structure of the phases of the project so that at the end of the day we actually build the right thing given all of the context.

Drew: You and I met at our local Rust meetup. Where and how is rust used at AMP?

Carter: So, primarily I've been writing C++ code for the last 10ish years. AMP’s main tech stack, the actual embedded code that runs on our systems, is like 99% C++. But I hate it! I hate it so much. My experience with C++ is that, as I’ve become more of an expert in the language, I’ve become more disillusioned with it. It’s incredibly hard to do things that you should be able to do in software. And, it’s a huge problem for me to constantly be helping other engineers debug the same bugs over and over. It’s always another use after free. I’ve probably debugged 300 of those. So, I had been playing around on the side for years trying to find a better way to develop software for robots. I looked at several different languages including Rust to try and find something I could write instead of C++. Eventually, an opportunity for a big greenfield project came up. AMP decided to build its own recycling facilities for the first time, and we needed a control system that would run the entire facility. This system was going to be talking to dozens of subsystems and hundreds of devices across the network. It's not an incredibly complicated thing, but because it controls the whole facility, it had to be bulletproof. So, that was enough of a greenfield project that we could just start it from scratch in Rust. I made the call to do it in Rust, and I firmly believe that it was the right call. We started by just dabbling around with Rust a bit, and everyone agreed they liked it and it would work, so we went ahead. So, we wrote an entire facility control system from scratch in Rust in about nine months. Actually, I gave a talk at RustConf 2023 about building this system. The success of that project basically converted me to a full Rust evangelist. Now, I'm like how quickly can we possibly get off of C++ and get everything moved to Rust? I'm not a lunatic. I know it's not right to just throw away all our C++ code and say everything's Rust now. We’ll have to gradually migrate. We have to respect legacy code, find libraries that match the capabilities we had in C++, and retrain developers. But, I'm definitely now leaning as hard as I can on the lever to switch us to Rust at AMP.

Drew: I guess a lot of people are having that type of experience with Rust right now. It doesn't necessarily make sense to just start rewriting everything even though that was the meme, but when a new project comes up they take the opportunity to use Rust. It sounds like in your ideal scenario you'd like to rewrite everything at AMP. How feasible is that?

Carter: Do you know about ROS, the Robot Operating System?

Drew: A little bit.

Carter: So, ROS is not an operating system first off, it's a framework. And, more than anything it's microservices for robots. Basically, there’s a message bus you use to write your robot application as a bunch of microservices that publish and subscribe to messages from each other. That’s the fundamental architecture of the robotics stack. So, I am indoctrinated in microservice culture. It's how I've been writing software for the past 10 years. And, I believe in microservices as the fundamental architecture for robotics. So, that interprocess communication layer lets you write each microservice in a different language and they can interoperate with each other because they're just passing messages. So, we can actually really gradually migrate a stack by just rewriting one microservice at a time. I’m hoping that we can just rewrite them one by one as it comes time to rewrite each of these services. When I started at AMP, our code base was like 40% Python and 60% C++. And, those are kind of the two main languages supported by ROS. A lot of people when they start building stuff in ROS start writing everything in python just because it is faster to develop on. I think that’s a great way to start too. Then, once you get everything in the right places you start hunting for the bottlenecks. I think like a quarter of my career has been rewriting Python into C++ to make it like 100-200 times faster. I'm not a python hater. You can write really fast Python code. But, usually I'm picking up code that people wrote in a hurry not thinking about performance at all. So, we really have a lot of opportunities to rewrite microservices.

Drew: Have you rewritten any yet?

Carter: Not yet but very soon. We have yet to set up the infrastructure on the actual embedded stack first. You could not write one of our microservices in Rust yet. For example, there’s not a template node and the template setup and all the tooling in place to be able to do that. We're probably going to have that in place in the next four months though.

Drew: Would the tooling you’re talking about be applicable to other people using Rust for robotics, or is it more specific to AMP?

Carter: Some of it would and some would not. Actually, I apologize for continually plugging my talks, but I gave a talk at ROSCon where I presented roslibrust, which is a ROS to Rust interface library. That was needed for our control system to talk to all of the ROS devices in our facility, so we use that pretty heavily. The way that's architected and implemented is not good for something like microprocessors on the same computer talking to each other. It's pretty high overhead. But, it's really flexible which is great for what we needed that central controller to do. When we're talking about two processes on the same computer passing gigabytes of image data back and forth, there’s no way that you're going to use that. So, we do need to get the right tooling for that. And, there are several libraries for doing that. I know some of the maintainers of those libraries. But unfortunately the broader context here is that ROS makes it pretty easy to stand up a robot stack but has no standard way to do things like updating software on deployed systems around the world. And, ROS has no off-the-shelf answers for packaging and distribution. So, around our C++ code we have an entire infrastructure of CI and everything that's actually built on top of Docker. We have Docker images descending from other Docker images, installing Nvidia drivers and TensorFlow and OpenCV and all of this software that we depend on into final docker images that can then be deployed. And, we have all this tooling around how those docker images get deployed. So, that's where a lot of things have to get updated to support another compiler, another language, and another set of dependencies.

Drew: I remember when we talked before you mentioned the fact that the future of ROS is maybe a little unclear or that there's some appetite for change. Could you speak to that a little bit?

Carter: Yeah, there's a few things going on. Over the last four years or so, ROS has had a major fork of the framework to ROS 2. I understand why they made the changes they did in ROS 2, but they didn't do it with an eye toward backward compatibility. And, the design choices that they made for ROS 2 were right only for what some people wanted. For example, in my opinion they were right for a lot of academia, swarm robots, and sets of robots talking to each other with bad network communication. None of this matters to us. We're running one stack on one computer embedded in one location, and we have a hard-lined ethernet cable into it. So ROS 2 is not getting migrated to by a lot of people in the industry. I think this year was the first year that ROS 2 downloads exceeded ROS 1 downloads. The educational material and new people learning ROS are more and more moving to ROS 2, but there's a huge number of companies out there that are on ROS 1 and probably not moving off of it. I've personally talked to several of them and the migration story is pretty brutal. So, that's the first big nugget of knowledge about ROS.

Carter: The second big nugget of knowledge is that ROS is more than anything else an interprocess communication framework for microservices to send data from each other to each other. ROS 1 invented its own communication protocol for serializing and deserializing messages. I got very familiar with all of that because I've re-implemented a lot of it from scratch in Rust. But anyway, it was ROS’s own thing that they rolled. At the time ROS 1 was written, there were not great off-the-shelf equivalents. So it was reasonable to write your own. Since then, there's now dozens of things that do that for you. A really good example would be protocol buffers. Protocol buffers solve a lot of the same problems that ROS does. So, that is a big part of ROS's ecosystem for which there are now more standard off-the-shelf solutions. So when they switched to ROS 2, they decided that this time they would not roll their own communication system. One thing they grabbed off the shelf is this thing called DDS, which I'm not an expert on so I can't speak to it well. I think it came from the automotive industry or the aerospace industry. But, DDS is messy. There's not one way of doing DDS with ROS. There's like three DDS backends that are plugins, and they have weird differences between them and behave differently on different systems. So, generally the ROS community was like hey DDS kind of sucks. So, that’s one of the reasons people haven’t moved to ROS 2.

Carter: Here's context nugget three. At ROSCon last year, it was announced that part of the Open Source Robotics Foundation was acquired by Alphabet. I think this is good because they’ll at least theoretically have more firepower to point at ROS. But, they also announced that they're going to provide an alternative to DDS in ROS 2. The middleware that they picked as the alternative is this thing called Zenoh. And, it’s written in Rust! So, ROS is about to put Rust at the very core of the project. They have a lot of blog posts about why Zenoh is really good because it's written in Rust and Rust is better and more reliable. The somewhat hilarious part is that they're not going to let you talk to Zenoh straight Rust to Rust! See, in ROS 1 they decided to define this communication mechanism and then every language had to implement that communication protocol. This caused a ton of bugs and community compatibility problems. For example, Java would handle things slightly differently than Python and then there'd be a weird bug when Python talked to Java or something. So, for ROS 2 they decided to find a C library that would be the robot middleware and every language would call the C library. So, they're putting the Rust Zenoh layer behind that C library. You're still going to call the C library and then there's going to be Rust on the other end of it. So, you have to go through a bunch of weird indirection layers. You don't get that native feeling Rust, and you have to deal with linking and installation.

Carter: So, ROS is moving toward Rust. Probably over time Rust will get more and more support. I think eventually Rust will be a flagship language under ROS 2. And, that's great and that's what I want to see happen. So, that’s “Column A” about ROS.

Carter: “Column B” is that I just don't think you need ROS, because if you use Rust I don’t know if you really need microservices. The first fundamental reason to use microservices is async and parallelism. You want to describe the idea of a robot thinking as an async compute graph where you take in sensor input on one end and you output actions on the other end. Information flows through that graph with each node operating as fast as it can on whatever data is most recently available. That's a really good way of programming a robot. You don't want to write a robot with a central loop or something. That causes you a lot of problems in performance bottlenecks. So, it’s good to break your application apart into a lot of async tasks that are dynamically sending and receiving information from each other. That lets you take better advantage of modern compute hardware and run much bigger, heavier algorithms in parallel. In C++, that's really hard to write effectively without all kinds of memory leaks and all kinds of thread locking problems and mutex hell. In Python, that's almost impossible to write because of the GIL and performance problems with multi-threaded Python. So, ROS provided a way to write this all as separate processes. So, if any single microservice seg faults or drops memory, it kills that node. That node restarts, but your entire application doesn't go down because memory corruption and undefined behavior are locked to the process boundaries of the individual nodes. That all comes with a ton of overhead because serializing all those messages and sending them over the ipc layer is much slower than just shared memory access. So, what if now I have Rust? It’s a language where I can write an async graph of individual tasks connected to each other and I can know that there's no undefined behavior that's going to happen in any of them. I know there's going to be no memory corruption where one of those tasks is going to take down the other tasks. And, instead of having to use an ipc layer where you serialize the data and send it out over a socket, you can use Rust's channels and low level synchronization mechanisms to pass that data for free. That replaces the majority of the reasons I advocate for using ROS. Now, there is a giant blocker to achieving any of that. It's drivers. Drivers are a huge problem that I've dealt with my entire career. For example, our application running on our robots might be 150,000-200,000 lines of C++ code. But, we're calling like four million lines of C++ code from other people. You just can't write a robot completely by yourself. You have to pull in everybody else's stuff, and all that code is still written in C++ and is still buggy. So, today I can't say you should write your entire robot application as a Rust monolith, because the reality is as soon as you start calling some of that vendor code, it’s going to start corrupting memory. It’ll take down your entire application. So, we're not there yet. But, look at how far Rust has come already. If 10 years from now my camera drivers were written in Rust, my motor controller drivers were written in Rust, and the path planning libraries I was using were written in Rust, I could run my entire application as one Rust monolith. It would be way lower overhead than what I'm currently doing with an ipc set of microservices. I also think it would be easier to debug and ship.

Carter: One thing I should call out is that ROS has a solution to reduce some overhead, which is where you can write everything in separate processes but then flip a flag to compile them as nodelets. So, what looked like separate processes gets compiled into one process. You can do shared memory access that way in ROS to eliminate some of the overhead. But, you still have the problem that if one of them does fail it takes down the whole set. We probably lose 10-20% performance by not doing that. But, I think the bigger problem is that writing everything as separate processes that are separately compiled strangles the compiler's ability to do a lot of the good checking that it can do. If everything was compiled as one Rust application the borrow checker could check across task boundaries which you just can't do when you're compiling everything.

Drew: So, one last question about the feasibility of this. You can still shoot yourself in the foot with Rust by writing unsafe code. For robotics applications is it safe to say you're not going to run into that, or do you think there are cases where it might be a problem?

Carter: The people who have to write unsafe code are the people who are implementing interactions with hardware. For example, if you want to make a system call to the operating system, or if you want to implement a driver where you're going to be dealing with bytes coming in and out. We wrote an entire 100,000 line plant controller in Rust and we never used unsafe. For every single thing that we needed to do there was something off the shelf that did it for us which wrapped all of that unsafety in Rust's guarantees. In our experience using the Rust ecosystem for almost three years now, I don't think we found a bug in a single Rust crate that we've pulled off the shelf. We found a bug in one of them and that was a Rust crate wrapping a C library and the bug was in the C library. The software quality that you kind of get for free is amazing. I’ll admit free is a strong word because Rust is more challenging to learn and slower to compile. But, for the type of code I'm writing and the type of problem that I’m working on, you get basically 20% higher code quality. That pays for itself.

Drew: So, did you want to just go ahead and announce your open source Rust robotics monolith project? (laughing)

Carter: (laughing) Well, you know here's a really interesting thing. C++ doesn't have a package ecosystem. There are several people who have tried and started different things, but there's no way to super easily just grab C++ code off the shelf and put it together. A huge thing that ROS did was just provide a package ecosystem for a lot of C++ tools that people needed in robotics. The wonderful people maintaining ROS have figured out compatible versions of all of the packages that work with each other correctly, which is a shockingly hard thing to do in C++. That problem largely disappears when you're in an ecosystem like Rust. You just need people to implement each piece of functionality in a crate on crates.io. Then, I can just go shopping for a motor driver or a camera driver, and if they're of high quality I'm done. I don't need a central authority figuring out compatibility issues between all of those and shipping one giant meta package of all of those put together. So yeah, maybe at some point something like that would be helpful. But, we need less of a coordinated central authority managing robotics and Rust and more just a lot of people to go write Rust code that does useful things in robotics. Rust already makes it easy enough that we can just stitch their stuff together ourselves without needing a microservice ipc layer.

Drew: So maybe it's more of a call to arms to whoever's reading that might be capable of writing good drivers in Rust.

Carter: Yeah! I wanted to make one more point if I can.

Drew: Go for it.

Carter: There's a whole set of companies that have come in and built layers on top of ROS to make it easier. So, there’s Formant that’s a big player. Foxglove is another big player in that space. They’ve extended free ROS. Then, there's a company out there called Viam. Viam is basically writing an alternative to ROS that is supposed to be way friendlier and easier to use. I think they're going about it in totally the wrong way. They're trying to abstract you even further away from the source code by creating things like web interfaces where you can do things like json configuration. That's not a crazy thing. It does solve a lot of the challenges of working with ROS, but I'm afraid for them that they're going to get beat up by the modern tide of software development. The need for a lot of those abstraction layers just disappears when you have a language like rust that lets you just write apis how apis should actually be written.

Drew: I have one more question. I don't actually have data to support this but I feel like there are a lot of software engineers out there who would be interested in getting into robotics. What would be your advice or thoughts you might share with those people?

Carter: I have a lot of advice, and it's probably mixed in a few different directions. The first thing that I would say is learn ROS. That's the advice my brother gave to me. I did a personal project in ROS early on. That's incredibly attractive to people hiring for robotics engineers. ROS is the king right now in most of the world, and it's just a good framework to know and a good thing to learn. So, that's a very concrete thing. It's kind of painful to get started with, but it's not that terrible. The second thing that I would say is go and build robots. Even if they're bad and even if the idea is dumb, just go and do the whole thing yourself from scratch. You should design it in CAD, 3D print the parts, buy the motors off SparkFun, wire it together, put the software on it, and have it do the dumbest thing. Just going through the entire process yourself so you understand the fundamentals makes you so incredibly valuable. You’ll be much more valuable than just being a software developer. You need to know what the mechanical people are talking about when it comes to torque or amperage or anything like that. Having a broad foundation where you understand a little bit of how everything works just makes things gel better. Also, practical hands-on experience is everything. You learn so much more building something yourself than you do sitting in a million lectures. In terms of getting hired, make a portfolio website. The thing that lights me up is YouTube videos of the robot that someone built being terrible. Showing me that you have built things is a 10 out of 10. One of the other things I’ll stress is figuring things out yourself. The more of a tutorial you follow, the less experience you're going to get out of it. One of the famous things about robotics is that robots are so much harder to build than people think. So, what's going to happen is you'll come up with an idea that is way too hard, you're going to get halfway through it, realize how complex it is, and then you're going to toss that out and come up with a simpler idea and actually build that. I’ve seen like five robot arms that are a clock that writes the time on a whiteboard. Sounds easy, but those projects are hard! If you can actually pull that off, I will legitimately clap for you. I know how long that would take me to do.

Drew: I really enjoyed this and I really appreciate you doing it Carter. You are really sharp, but even more than that you are kind and attentive and interested in people. Some technical folks can be the opposite, so I really appreciate that.

Carter: I’m really grateful to AMP for this role. It’s the perfect role to combine soft skills and hard skills. Also, if roboticists out there want to develop their people skills, they should coach a high school robotics team! (laughing) Coaching a team of high school students building robots in high stress situations for seven years has done a lot for me.

Drew: I can only imagine! Well thanks a lot Carter.

Carter: Thank you!