CppCast - Vehicle Control Software

Episode Date: October 3, 2019

Rob and Jason are joined by Philipp Schrader. They first discuss some post CppCon news and the LLVM 9.0 release. Then Phil talks about the work he's doing at Peloton Technology to enable the 'platooning' of trucks with software written in C++. Links CppCon 2019 Keynotes CppCon 2019 Trip Report LLVM 9.0.0 Release Sponsors Enter #cppcast in the Message field and get a month-license instead of 7-day license PVS-Studio PVS-Studio Twitter JetBrains

Episode 217 of CppCast with guest Philip Schrader, recorded September 25th, 2019. Sponsor of this episode of CppCast is the PVS Studio team. The team promotes regular usage of static code analysis and the PVS Studio Static Analysis Tool. And by JetBrains, makers of smart IDEs to simplify your challenging tasks and automate the routine ones. Exclusively for CppCast, JetBrains is offering a 25% discount for a yearly individual license, new or update, on the C++ tool of your choice, C-Lion, ReSharper C++, or AppCode. Use the coupon code JETBRAINS for CppCast during checkout at www.jetbrains.com. In this episode, we talked about a new LLPM release.

And we talked to Philip Schrader from Peloton Technology. Philip talks to us about his use of CppCast, the first podcast for C++ developers by C++ developers. I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, I apologize for interrupting your week of rest. Yes, I had to wake up for this. I was planning to sleep all week, as our Twitter fans know, I guess, and friends. Yeah, so for those who weren't tracking, you were keeping a running to-do list of everything you had to do during cpp con the three talks the field trip the training and then the last item was sleep for a week i believe right was sleep for one week and i am i am not asleep at the moment although it's not obvious

this is being recorded just a few days after cpp con fortunately i didn't have to travel so i didn't have jet lag or anything right so did you get to get some good rest for the past two three days though yeah pretty good um i'm starting to get caught up okay okay uh well at top of episode let's read a piece of feedback uh this week we got a tweet from gulik and he writes uh cpcast about herb's talk you could find the folks that think exceptions and rtti are bad and need to die. They need to come out and propose something. The community can't have a good debate on the subject when only half of the interested parties show up to the conversation.

And, yeah, I guess he's talking about Herb's CBPcon keynote, where he's talking about his proposals to do static exceptions and have reflection as an alternative to using RTTI. And I see what he's saying, but I do think Herb is, I guess, trying to address the concerns of that half of the community that doesn't use exceptions in RTTI. But maybe it would be worth talking to someone and see if they think Herb's proposals will work for them. Yeah, and I'm curious now, because we've had a bunch of game developers and such on.

Have we ever had anyone on who worked in a code base where they did dash F no exceptions or no RTTI and actually fully disabled it? No, I don't remember it coming up. But that's the category of people that he's talking about, is the people who disable it in the compiler. Right. I saw our

guest is raising his hand so we'll get to him in a minute and uh get his opinion on uh herb's proposals but yeah it's it's definitely something worth talking about i i think i'm sure the committee will be listening to lots of feedback you know these proposals you know it would be great if they made it into 2023 but uh i'm not even sure if that's gonna happen 2029 maybe yeah they're they're pretty big proposals but uh i'm sure the committee will you know listen to all voices about it i mean that was actually one of the things herb talked about in his talk about how you can't have a role by majority with big changes like this yeah okay well we'd love to hear your thoughts about the show.

You can always reach out to us on Facebook, Twitter, or email us at feedback at cpcast.com. And don't forget to leave us a review on iTunes and subscribe on YouTube. Joining us today is Philip Schrader. Phil started working in consulting primarily as a C programmer. Very quickly, he found himself being tempted by the famous object-oriented programming language called C++. He started volunteering at a local high school robotics program where they use C++ to make their robots competitive. Hooked on C++, he found Peloton technology, where he had the chance to learn and explore what C++ is capable of, and he's still exploring.

Phil, welcome to the show. Thank you. I'm excited to be here. So why were you raising your hand a minute ago? Oh, you said I'm curious if we've ever had anyone on the show who actually does add fnordti to their compiler options. And we actually do do that. Okay. Just nordti or no exceptions as well?

No exceptions also. Okay. exceptions as well uh no exceptions also okay um mostly for uh i guess mostly for reasons that i'm not super privy to but uh has to do some to some extent it has to do with uh adhering to real-time constraints in right in our environment and so exceptions are historically not very real time friendly. And so that's one of the reasons we've disabled them. I honestly haven't tried exceptions on say, you know, Clang or the latest Clang release or something like that. I haven't tried them in a while, but just from a historical point of view, I've always had them disabled. Yeah, I mean, I think in a real-time situation,

it often comes down to the fact that throwing an exception incurs a dynamic allocation, and that's not something that you can guarantee the runtime cost of, real-time cost of. Yeah, that's a good summary of it, yeah. Now, you could theoretically probably get around that there are real time memory allocators but we don't

happen to use one so disabling exceptions is a pretty straightforward thing to do that's interesting maybe well sure let's talk about it now I've excuse me and all the like hard realtime systems that I'm aware of, people just don't do allocations.

I didn't know that there were real-time allocators that could address that. Well, I mean, so we don't use any. So personally, I couldn't name one. But I know that one of my coworkers has at least looked into one and evaluated a couple and such. But the way I guess I see it is that if you call malloc and you just have a gigabyte of RAM already available, right? Then you could just return a chunk of that, and that does a constant time operation at that point. So I don't know. I mean, that's obviously a gross oversimplification,

but roughly speaking, if you're not asking the OS to pause your process while you go get some memory, then that could be a constant time operation. Sounds akin to what a lot of game developers do, allocate a giant chunk of memory up front and then just do whatever they need to with it after that. Yeah, that's roughly what I'm imagining, yeah. Okay, that makes sense.

So Phil, we got a couple news articles to discuss. Feel free to comment on any of these, and we'll start talking more about the work you're doing at Peloton, okay? Sounds great. Okay, so this first one, kind of going back to our feedback, is the CBCon 2019 keynotes are all up, and that's starting with Bjarne's and ending with Herb Sutter's at the end of the week, including the other three plenary talks in the middle of the week. And Jason, remind me, how long does it usually take for some of the other videos

to go live? I think they usually come out in like batches of like 50 videos at a time or something like that, right? Yeah, we should start to see a stream of them coming out pretty quickly here. Yeah. I mean, they're not sitting around waiting to edit them, right? They're processing them and getting them all ready right now. Yeah. So I would expect many videos every week to come out personally, but it should probably ultimately take five or six weeks or something maybe to get all of them and all of the lightning talks edited. I can only imagine how much more effort editing the lightning talks

takes. Yeah. And there were like five days of lighting talks, I think. Yeah. How big is CPP con? Uh, yeah.

How big, how big is it like in terms of attendees and talks? About 1300 people this year. Five days. Five days with between six and eight tracks at any given moment is that right four tracks a day four tracks a day plus the keynote plus the keynote i think that's right so somewhere on the 25 ish talks a day for five days at least 100 and something talks i looked at how many episodes were in the previous uh year playlists and it was uh last year was 151 that for the full talks and 43 lightning talks

yeah okay yeah previous year was was 139 and 55 so i don't know if we went up again in the number of talks but figure it'll be about one 50 probably. I'm certain we did because we didn't have the space to do things like eight tracks and some of the, and some of the moments like we did this time, I think it was eight was the P I don't know. It was big. It was big,

right? Too much for any person to absorb. And going back one more time to that piece of feedback about exceptions in RTTI, Phil, did you have a chance to watch Herb's talk? Are you familiar with his proposals about static exceptions and reflection? I haven't. I've definitely been excited by the snippets over the past few years, at least, where people have talked about static reflection or compile time reflection and all those things um but i haven't had a chance to uh listen to herb sutter yet but uh go watch the talk it's a good one okay good yeah no the um i definitely want to use exceptions more particularly

well perhaps i'm jumping the gun a little bit, but we periodically run into problems importing third-party libraries that do make use of exceptions. And then when you want to compile a big binary together, generally it's fine when you have one library compiled without exceptions, another with exceptions and put them into a binary. But sometimes you do run into headaches and problems. So I would love to... That sounds risky.

Oh, yeah, yeah. No, it's highly not recommended. So, yeah, I'm definitely super excited to actually use a feature of C++ that I haven't used in, well, many years at this point. Oh, interesting. Very much looking forward to it. I've made some notes here. I'm going to ask you more about your error handling, what you do today, once we get to the main part of the interview also, without exceptions.

Sounds great. Okay. And then another thing from CppCon is we're starting to see some trip reports come out. Matt Godbolt released his trip report where he's talking about all the keynotes and then some of his talk highlights, including

his own talks. Is there anything you want to comment about Matt's trip report, Jason? I mean, nothing specific, but he did highlight lots of good talks, talks that I wish that I'd had the chance to see, but for various reasons didn't get to. JF's Let's Deprecate Volatile, Kate's talk on naming,

I heard from outside the room, unfortunately, so I only heard a little bit of that. I was getting ready for my next talk after that one do you say master report because jason was there or is is there like a thing called the master report um i'm sorry matt's trip report oh matt's trip report sorry god yeah uh but yeah these trip reports are great in highlighting talks and you can kind of use them as a guide when you decide which talks to watch once the YouTube videos are live.

So I know I would like to watch some of these that I did not see in person. I heard, um, Peter Bindles and Cy Brands talk. Uh, hello world from scratch was really interesting. I want to see that. Yeah,

I did go to that one. That was fun. They, they do do a good job of, um, uh, uh balancing each other responding to each other and stuff as as partner speakers also uh bjarne's keynote c++ at 20 i saw some complaints on twitter about how he starts out by saying uh that he's giving lots of high level things and each one of these high level things is at least an hour talk at the conference, and many of them are things that were being talked about at the conference.

So, like, doesn't that say that there's a problem with the language? But I don't think that's fair. I mean, to say that that means there's a problem with the language, personally, because fully understanding what any programming language is going to do is going to have lots of depth to it. Oh, you mean the fact that there is an hour on just one aspect of the language is the problem? Yeah, that's what some people were saying on Twitter. And I'm like, I just don't think that's fair.

Yeah, I agree with that. Right. I mean, every time I watch Gernot, it's amazing to me how simple he can make his slides look a lot of the times. When I do a presentation on C++, especially my code snippets take up the entire slide.

They're like int i equals something and then maybe I'll squeeze a comment in there to explain it. And every time I see Bjarne, especially his keynote this time around, he made it seem so simple. And I don't know, I think perhaps in my mind I have a much uglier version of C++ in my head than Bjarne does.

And I think that's a good thing, that he has a vision that C++ can truly be the language for everyone. Yeah, that's interesting. I didn't mean to interrupt you. I'm sorry. No, no, no. I was done. Okay. Someone asked me at CBPCon for a book that has good examples for learning and understanding C++ better. And I thought about it, and the answer I gave was not one that I expected to give.

And I said, pick up any of Bjarne's C++ books. And, you know, just look at the examples. Because he does subtly different things than, like, anyone else does. And there's a few things that I've picked up from him. Like, if you are printing a single character to see out, he uses the single quote. Because it is a single character to see out, he uses the single quote because it is a single character. He doesn't use the double quote, which has to be handled differently as a string with a potential call to stir lane.

Like there's these little differences. And if you just read it, you're going to pick up random things that you don't expect to. Yeah. Yeah. It was definitely, I mean, part of some of the things that he was pointing out are C++20 only that I'm not super familiar with. Yeah. And so, for example, his example, yeah, his examples with concepts. Is that the name?

Concepts? No. Probably concepts. Concepts. Yeah. Okay. All right. Okay.

Yeah. I should really know this. Like constraining templated types. Yes. Yeah, okay. All right. Okay. Yeah, I should really know this. Like constraining templated types. Yes. Yeah, exactly. And just that, just, I don't know. Anyway, he made it sound super useful. Or just the way he talked about them and gave such casual examples almost just amazed me. And I always feel that way when I see him, when I see him present something. It's cool.

Okay, and then the last article we have is from LLVM, and they just released version 9.0, which sounds like it should be a pretty significant release, right? It does. I feel very confused. What are you confused about? Well, I read the Clang release notes, and if I click on C++ language features, it's like two things.

And I'm like, I must be missing something here, because I know Clang 9 versus the previous version has lots of C++ 20 stuff implemented, and I feel like maybe i just am like clicking on the the wrong thing i don't know but you're you're looking at llvm versus clang i clicked on the clang release notes sub sub one oh got it and maybe this is just the release notes versus like the pre-release. I have no idea. I don't know. I feel like I'm going nuts here.

Maybe they should be summarizing everything that's different in Clang 9 from Clang 8. I don't know. So do they... Oh, that's interesting. Oh, sorry. Does Clang get released at the same time as LLVM? Because I saw the LLVM announcement, but I'm never sure if they're separate projects technically or if they just happen to keep track. They are technically separate projects, but they release all. So if you click on the mailing list release, there's the Clang notes, the Clang extra notes, the LLD notes, the libcxx

notes, they're all like tied together with a 9.0 release. Fair enough. Yeah. Although the thing I just said, oh, that's interesting, is that the static analyzer now has dash analyzer dash w error to turn analyzer warnings into errors so now if you want static analysis to be hard errors also you can turn that on for your continuous integration builds it's a good feature oh here we go so in lib c++ we see c++ 20 things being added standard swap is now constexpr. Been waiting for that one. Is constant evaluated, is officially supported. Standard midpoint, which I think there was a talk on just the implementation of standard endpoint for C++20

from Marshall Clow. I think that's right, at CppCon. Is that standard midpoint? Yeah, standard midpoint. You give like a couple of points on a line and it tells you what the midpoint is apparently that's a surprisingly difficult algorithm to get exactly right with all the possibility of like rounding errors and whatever oh and a naive implementation you could have like integer overflow or something like that and probably yeah got it okay yeah that sounds that sounds great yeah and it sounds like something that's trivial but it's not yeah yeah especially integer overflow is something that i generally you know it's not the first thing that

i worry about when when writing something so So when you deal with big numbers, it suddenly does become important. Right, yeah. The other one that I thought was super interesting is the more undefined behavior optimizations. Like the one that was, or I think, I thought it was part of this release where they

if you try to write to a const address like to a pointer pointing to const basically it'll optimize it away or it'll it's a you know the example in the bug report that was filed against

Clang 9 the Linux kernel had a const, extern const int something rather, and in one of the functions, it did a C-style cast to just a regular int, and then it wrote to it. And the new Clang 9 just deleted that whole call because, well, it's undefined behavior to write to a

const location. And so, by definition, it can't happen, I guess, depending on how you want to phrase it. And so, they ended up fixing it in the kernel itself by not declaring

the integer as const and whatnot. I think that's what the patch ended up fixing it in the kernel itself by not declaring the integer as constant and whatnot. I think that's what the patch ended up being. Anyway, I'm always excited by the compiler not making excuses for the programmer, to actually follow the spec and not do things that happen to work, but that actually should work. Right. Yeah, I found the actual note you're referring to here. It says LLVM will now remove stores to constant memory.

That's the gist of it. Yeah. Yeah, those are the kinds of changes that excite me maybe more than they should i guess i don't know but uh i i love that i love those like where you know stop stop making excuses for the programmer and just and just you know do follow yeah just just follow the language basically just adhere to it that's like uh i think we've we've brought this up on the show a couple of times now but you you used to be able to like check if this was null which is illegal

this can never be null if you're inside a member function and gcc made it a default behavior to remove that check something like five years ago now and there was a minor uproar because of all the code that it broke. And people are like, no, your code was broken from the beginning. If you were calling a member function on an object that had already been, you know, gnawed out, like, what are you even thinking? Yeah, yeah, that's definitely what it reminded me of. That's true. Okay, so Phil, could you start off by telling us about what Peloton Tech is,

the company you work for, and what your role is there? Yeah, I guess the first thing I should clarify that we're not the bicycle company. I did wonder that at first. When I went to, every once in a while I meet someone. The first time it happened to me at the Basel conference two years ago. And someone came up to me and said, you know, what do you do for Peloton? My dad really loves your product. And anyway, it's just our product is not released yet. So I doubt anyone is really loving it at this point.

But it's always funny that you have to clarify. company uh we basically focus on a uh cruise control system for semi trucks okay so that you can take two two semis and have them drive behind one another at a distance where the air resistance is lowered enough that you start getting fuel savings um and i think the rough numbers that we have on our website are something like five percent fuel savings for the front vehicle and around 10 percent for the rear vehicle and i'm i really don't know anything about fluid dynamics but it has something to do with the buffeting of the wind on the back of the trailer for the front truck that gets reduced so the air is more streamlined going you know across the trailer and of the front truck and just kind of keeps going over the over the tractor of in the back

kind of thing okay and so and the tractor in the back at the same time doesn't have as much air to push out of the way because it's already being pushed out of the way of the front tractor or the the whole truck kind of thing anyway so roughly speaking uh peloton technology builds a cruise control system for for that so that um you can safely uh platoon for fuel saving purposes. And I don't, as I said, I'm not involved in the fluid dynamics part of it or really the control. I'm not a controls guy.

Okay. But I work on the platform. So I make sure that Linux is running, our microcontroller lets the controls guys do their thing. So make sure that all the message passing is working. And just that all the information that people need from the sensors is available. Just that kind of stuff i don't know if there's a like a good term for that kind of a role but uh does that give you an idea of what my what i do and i think uh maybe for the sake of our listeners around the world

just to clarify we're talking about these giant 18-wheeler big rig trucks that crisscross across america that you know depending where you live they either don't exist at all or there aren't as many of them yes yeah sorry yeah when i when i say semis yeah i'm talking about the some people call them 18 wheelers um i don't actually know if they're if they have 18 wheels, I think in some configurations they do. I think the ones that have two rear drive axles with, with,

with, with dualies on both of the rear drive axles. And then you add in the wheels on the trailer. I think it actually does add up to 18 wheels. That's eight and then 10 just on the tractor. And then you just need eight more on the rear. Yeah, no, I guess that's fair. Yeah. Okay. No, that's fair. Yeah 10 just on the tractor and then you just need eight more on the rear. Yeah, no,

I guess that's fair. Yeah. Okay. No, that's fair. Yeah. We there, those are the kinds of questions that perhaps I should already know the answers to.

My grandpa was a trucker for a long time, so that's why I've only reason I've ever thought about it. Really nice. Yeah. Fair enough. Fair enough. Um, but yeah,

so big, uh, tractors, the... Yeah, so when I say tractor, I'm talking about the vehicle with the engine in it, and then separately there's the trailer that the tractor is hauling. And in general, we colloquially call that a truck. Right.

And how much of the truck is actually being controlled by the Peloton software when it's being platooned like this? Good question. So going back to the cruise control analogy, it really is a cruise control in that sense. It takes over your longitudinal acceleration. You basically can take your foot away from the gas pedal and the brakes. It will essentially speed up and slow down for you. But you still have to... Well, sorry, this is all from the perspective of the person in the rear trailer or in the rear tractor.

Okay. The front tractor driver has to do, well, everything that he would do normally. Oh, okay. do well everything that he would do normally oh okay and so so that that's just a more or less a regular truck with additional sensors essentially the one in the back is where where it's really the only place that's interesting to talk about because again the front is kind of a regular truck and the back is where the cruise control system lives and takes over the acceleration and braking in order to keep at a close gap between the between the two trucks but the so even in the back you still have to steer to stay in the lane and stuff like that. Does that answer that?

It's kind of like if you imagine being on the road and you engage your cruise control system to go at a constant 60 miles per hour or something. It's basically like that, except you don't control the speed. You just say, you know, do your thing, It's basically like that, except you don't control the speed. You just say, you know, do your thing. And then depending on the speed that the driver in the front truck is deciding to go, that's the same speed that you in the back will go also at some certain gap between. So you said, now if I understood right, the software that you write

isn't the control system, it coordinates things, right? Yeah, I mean, it's basically, at the core of it, it's really a message-passing system, I guess, that kind of like a pub-sub

system. And so someone who does write an algorithm to control that gap between the two trucks doesn't have to worry about all the nitty gritties of, oh, how do I get information from here to there? They just get an object, like a sender object that they can pass a message to. And then the software that I'm responsible for takes care of actually sending the message across

and making it to the other processes or the other processors in the system, et cetera, et cetera. So does either truck have any kind of user interface display that tells like what's going on with the vehicles around them or anything? Yeah. So there is a display in both trucks, like a little 800 by 400 display. Okay. Tells them roughly, you know,

what, what gap you're, you're currently at. And this is, this applies to both the front and the back so you can see in the front even you can see oh you know the truck behind me is this far you know has a gap of well whatever the gap is at that time uh even if you're not actually platooning yet it'll give you some information about oh you're you're paired with this other truck and this the other truck is say a mile ahead of you you know it can give you all

kinds of information it can also give you information about saying there's traffic coming up ahead um we might and the system might disable platooning and actually grow the gap ahead of time before reaching heavy traffic. For safety reasons. Oh, okay. Yeah, yeah, yeah, exactly. And it'll give you those kinds of, you know, heads up to keep the driver informed.

Because, yeah, I'd imagine having a system like that without any sort of feedback would be quite intimidating perhaps. But yeah, so, and there's, there's a button on the dash kind of like, you know, your regular cruise control there's, or, you know, maybe it's in the steering wheel or something where you enable cruise control. You change the speed again for our system, you can't adjust the speed, but there's a button that you can push and enable,

and then the display will update either saying, oh, can't platoon right now because of rain or something, whatever. Or it'll go ahead and start taking over and controlling the speed and such so on the topic of like safety kind of issues does it uh do things like take into account the local regulations for say following distances or weight of the load or whatever uh yeah so the system does compute the weight of the truck that it's in. Okay. I don't pretend to know the math of how it does that. No, don't worry about that.

At the core of it, the way our controls guy explains it to me is that there's, you know, there's F equals MA, the famous physics equation, or force times mass times acceleration. If you do that a whole bunch of can make decisions based on their individual weights and, you know, which one it would be safer to have in front versus the back. I forget the other examples that you mentioned in your question, but yeah, it does take a lot of factors into account. For example, and as I mentioned mentioned, if it detects rain, if you turn on your windshield wipers, for example, it'll deduce that it must be raining, theoretically.

And so it'll use a bunch of input like that. It also has a connection to our central server that has more information from like the weather service and the road conditions, like if there's construction and stuff like that. Right. Yeah. Sorry, did I miss something? I feel like I missed one of your examples there, but... No, no, I laughed for a moment because i was thinking if you turn on your windshield wipers there's a good chance it's either raining or you're in florida during love

bug season and you're just gonna have to stop and scrub those things off at some point because have either of you experienced that that is gross i've heard of them but i have not experienced it i don't are are love bugs a specific kind of bug, or you just mean that it's that season? Love bugs, I mean, it's a colloquial name of some sort, but they are small flying beetles, and during mating season, they fly around attached to each other,

and you end up with them. Windshield wipers do no good good you have to stop at the gas station and like use the scrubbing thing because otherwise you just can't see out the windshield it can be it can be nasty it's um it's its own thing for sure yeah got it fair enough so i've never experienced that myself however if you're having trouble seeing out of your windshield because of said love bugs, chances are you don't want to be platooning either. Right. That's a great point. I wanted to interrupt the discussion for just a moment to talk about the sponsor of this episode of CppCast, the PVS Studio team. The team promotes the practice of writing high quality code, as well as the methodology of static code analysis. In their blog, you'll find many articles on programming, code security,

checks of open source projects, and much more. For example, they've recently posted an article which demonstrates not in theory, but in practice, that many pull requests on GitHub related to bug fixing could have been avoided if code authors regularly use static code analysis. Speaking of which, another recent article shows how to set up regular runs of the PVS Studio Static Code Analyzer on Travis CI. Links to these publications are in the show notes for this episode. Try PVS Studio. The tool will help you find bugs and potential vulnerabilities in the code of programs written in C, C++, C Sharp, and Java. When I was at CPCon last week, I did go to this one talk from Michael Wong about writing safety-critical automotive C++ software.

And I learned a few things that I wasn't aware of about these standardization processes that, I guess, vehicle control software has to follow. Do these affect you? I heard of like MISRA and AUTOSAR. Are these standards you have to follow in your work? Short answer, not really. Okay.

With caveats. So the way that I think one of my coworkers first put it when i joined a few years ago at this point um is that trucking is special so there are a lot of standards around passenger vehicles The most famous one, perhaps, is ISO 26262, where they specify essentially a process that you should follow and document and such when developing a passenger vehicle. um there is no such or well up till i think the most recent uh revision of that standard does include trucking but anyway the the long story short for a very long time there really were no standards mandated by the industry for example to that apply to trucking. So we don't have really any other than... So we try to follow ISO 26262 anyway, just because it's the best guiding post that we have, so to speak. But there's nothing mandated in that way.

Now, when you are developing a product that tries to integrate with someone else's system you know then if they want you to follow certain processes or in this case when i when i say someone else's system right if you're trying to make a system for trucks then the people making those trucks they have the right to mandate that your own development processes follow certain standards or that you show them various documentation, whatever, documented processes, things like that. Okay. Yeah.

So we don't follow MISRA. We've definitely considered it um it is at the time that we started the project uh the mizra c++ standard i think was still in either i think it was might have been 03 like c++ 03 which felt very restrictive right. And one of the things that at least they specify in MISRA is something like, you know, no pointers. So pass everything by value. Okay. And so I feel like, I mean, which is totally doable, but with the advent of things like move semantics, a lot of those concerns, I think, are not as valid anymore.

I mean, the primary reason being, you know, if you do have pointers, kind of almost by definition, you're probably doing manual memory management. And so if you're doing that, then there's a whole class of bugs that happen. And so if you just eliminate pointers from the system entirely, there's a whole class of bugs that by definition can't happen. And so anyway, so we use C++11 in our code base with unique pointers and all of that, the tools that what I would call modern C++ gives us.

Right. So your specific role in doing this message passing coordination, and we hinted at real-time before, this is like, it sounds pretty hard real-time. You have to make sure those messages get from point A to point B, otherwise things go bad. Yeah, if the track in front of you starts breaking Like you have to make sure those messages get from point A to point B. Otherwise things go bad. Yeah. If the truck in front of you starts breaking,

you need to break right now. Yes. Yeah, exactly. So, um, so I mean that, that,

that's definitely one aspect of it of, yeah, basically if you send a message, you're more or less promising that the message arrives within a certain time at the other end. Right. Given priorities and the like. So if, you know,

just because you send a high-priority message, some low-priority process doesn't necessarily, can not necessarily expect to be woken up right away to process that message. But anyway, there's always asterisks, I guess. Right. But at the same time, the algorithm developers

or the controls guys also have to take into account, well, if this message doesn't arrive on time because, say, the network link is down or some other part of the system has failed in some way, you do have to take corrective action. Okay. So, and, you know, with redundant sensors, that risk is reduced and such. But anyway, so what I'm trying to say is that there's, you know,

you have to tackle the same problem from both sides. On one on one hand yeah you make your best effort to make the system robust and you know make the message passing reliable but at the same time you have to work with the assumption that yeah sensors fail the message that you send out won't make it one reason or another, radio interference, et cetera, et cetera. And you do have to take that into account also. Maybe I took your question into a different angle than what you were trying to get at. Well, but I mean, you already said before that you can't use exceptions. So I am kind of curious what you do do for the error handling case.

So the control stuff, it sounds like, is more like kind of curious what you do do for the error handling case so the control stuff it sounds like is more like kind of embedded it sounds like you're maybe a little bit less embedded you talked about linux and like you maybe have a real operating system available i'm going for it oh i like the term real operating system uh yeah but i you know, whatever the lines are so blurry these days. I know, I know. Yeah, so we have basically, yeah, so we have Linux that does run the control algorithms. We have a microcontroller with an RTOS that is there as kind of a watchdog slash, you know, monitor. So it makes sure that,

uh, so then that one is, you know, hard real time, highly reliable. It has, you know, it's a cortex R five.

So it has the, I forget exactly what it is. It has the, it has the cores, the CPU. There's a, there's two copies of it at 90 degrees rotation, 90 degrees out of sync in lockstep with each other. So that if they ever, and they run the same code, and if they ever produce different results,

then you know something is wrong in the system. Anyway, so that is a whole cool other aspect of, I guess, the hardware side of it. I had no idea that was a thing at all. That's pretty amazing. Yeah. No, it's pretty impressive what the hardware folks come up with these days. But anyway, so we have sort of our safety watchdog monitor that just makes sure that the decisions that the Linux box makes are safe and don't interfere with any of the boundaries that it sets on the gap that can be in such.

Okay, at this point, I'm already forgetting what your question was. But what I was trying to get at, I think, is that we present the same API on both platforms. And so you can run the same code on either the microcontroller or on our Linux box. So the error handling is very much the same way. So if you try to send a message and it fails for some reason, you get an error code back. And that has to be handled, which is made a lot easier with the no discard tag. I was wondering what techniques you use to say it has to be handled. Right, yeah, exactly. So no discard is definitely my favorite.

Obviously, it doesn't prevent anyone from just you know casting it away and and not doing anything with it but uh those kinds of features are uh you know make our lives a lot easier um but at the end of the day when an error does happen as as per internal policy, I guess you could say, you have to keep track of it. And everything in the system periodically reports its status. One of those things is error counts, like how many times it has encountered an error doing a certain thing, such as sending a message or reading from a sensor or whatever it may be. Like packet loss kind of counts or something. Yeah, yeah, yeah. Or number of times, you know, it had to take corrective action or whatever it

may be. Basically, try to report on as many things as you can so that you can, if anything does go wrong, you can then decide to react or another system can decide to react based on someone else not taking action kind of thing. Is that the kind of thing you can also flag for maintenance issues? Like, this cable seems to have gone bad between these two components or something like that. Yeah, that's something that I'm actually working on right now. Okay.

You try to basically based on ping counts between our Linux boxes, try to diagnose at which point in the network the failure might lie, and try to report that for diagnostics purposes. That sounds like a really interesting problem.

I think that's, I don't know, what is that I just saw this on? Like GM turbines for jet planes. Like that they can tell you, oh, by the way, we're getting such and such code, which means this component needs to be replaced soon. It's about to fail or whatever. Yeah. It sounds like you're working on a similar kind of thing.

Yeah. Yeah, exactly. And it's just to make people's lives easier because you really don't want to spend your time debugging which cable is bad. You want to spend your time debugging which cable is bad. You want to spend your time tuning the feel of the system. Is the braking too aggressive, et cetera, et cetera? That's the kind of thing that I want to enable people to do.

Right. Yeah, totally. That stuff helps a lot. One thing I'm kind of curious about is how does your team go about testing all of their code? I'm guessing you're not getting onto a truck very often and actually driving it around with the system. Do you have emulators? Yeah, so, okay. There's a lot of aspects to it. And I don't know if I will remember all of them or I don't know if we have time to go into all of them. I'm fascinated by all of them, I guess I should say.

Go for it. Whatever interests you the most. Whatever interests me the most. Well, I think I'll touch on a couple regardless. So we have unit tests, I guess, at the core of it. Perhaps no surprise. Hopefully no surprise anyhow. Fair enough.

What helps there is, you know, with every check-in that you make or something you push out for review, the whole suite of unit tests gets run, et cetera, et cetera. Then we have bigger nightlies that get run that don't necessarily, sorry, that'll run more than just what gets run at check-in, et cetera, et cetera. We do have physics simulations of various platooning scenarios. So we have a couple of physics models that let the software or basically as long as we present again so i mentioned that the

microcontroller and the linux box present a certain api to the controls algorithms and so that the same software can run on those. So as long as we present that same API on top of the simulation world, we can very effectively run, you know, sort of a system test against a simulated system. So we can see how does the UI respond in this situation, for example,

or how if you're trying to reproduce a bug that was reported, like I got this error when I didn't expect it to, and you can try to reproduce it that way, and it helps a lot. Then we have another level that's like a hardware-on-the-loop kind of setup where we take our actual ECU and we provide it CAN traffic. CAN is the network that is used on vehicles a lot, the network type. And so we feed the ECU, our ECU, CAN traffic so that it believes that it's in a truck and it has to respond to certain signals. And we see how it responds and stuff like that. Make sure, you know, does it see that there's something on the radar, you know, in front of the truck that is, you know, like a, like a passenger vehicle cut in between the two trucks, like, because the gap happens to be large enough for a

passenger vehicle to come in. So one of them decided to do just that, you know, do we respond correctly and in time, like in the, in the time constraint that we set for ourselves so so that that that last one i think is the most interesting one to me just because it's a very high level system kind of test and it it very quickly makes you realize that all your applications and everything in the system run at such a different sort of phase offset from what you are used to in a simulation kind of world. Like in a simulation, when you instantiate all your classes and then you simulate time, basically it'll always happen the exact same way every time you run the program. Like all the events will happen in the exact same way every time you run the program. All the events will happen in the exact same order,

in the exact same amount of simulated time apart, etc., etc., versus when you have it in a hardware kind of setup. Then all of a sudden, that is not true. Your applications will take differently long to start up. They might be running a checksum when they start up and such. And so they all have these phase offsets all of a sudden that reveal bugs or, you know, race conditions and all of that. So that one is definitely, in my mind, my experience, that's been the most interesting one to me. Okay, cool. Well, it's been great having you on the show today,

Phil. Uh, is there anything you wanted to plug before we let you go? Uh, is Peloton hiring? Uh, do you want to let us know about your own social media presence or anything like that?

Uh, yeah, uh, definitely hiring, um, C++, definitely, uh,

a big plus, I would say. Where are you located? Mountain View in California. Okay. The commute's not the greatest, I guess, just because of... So I'm, I guess, along the lines of Jason wanting to sleep for three days or a week or whatever. A week was the goal, but...

Fair enough. It had to be done. When the interview started, I'm still normally asleep at that time just because I wait for traffic to die down and then go in after the big traffic. Anyway, I don't really have much social media, so I don't have much to plug there, I suppose.

But thank you. I do appreciate it. Okay. Well, it's been great having you on the show today. Thank you. Yeah, it was really fun. Thank you. Thanks for coming on.

Thanks so much for listening in as we chat about C++. We'd love to hear what you think of the podcast. Please let us know if we're discussing the stuff you're interested in, or if you have a suggestion for a topic, we'd love to hear about that too. You can email all your thoughts to feedback at cppcast.com. We'd also appreciate if you can like

CppCast on Facebook and follow CppCast on Twitter. You can also follow me at RobWIrving and Jason at Lefticus on Twitter. We'd also like to thank all our patrons who help support the show through Patreon. If you'd like to support us on Patreon, you can do so at patreon.com slash cppcast. And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode was provided by podcastthemes.com.