Stay ahead of important technologies: attend QCon London in person (April 4-6, 2022) or online QCon Plus (May 10-20, 2022). Register now

Promote knowledge dissemination and innovation in professional software development

After briefly introducing design patterns at different levels of abstraction, this article will introduce some patterns that are particularly suitable for serverless systems, including pipeline and filter patterns, and demonstrate the implementation of POC using AWS EventBridge.

Tareq Abedrabbo shared how CMC Markets transformed to utilize new technologies, the architectural choices it made, and some of the challenges it faced.

The Technical University of Munich won the Indy Autonomy Challenge. Auto racing competition. Here, we discussed the event itself, why it was challenging, and the approach taken by the Technical University of Munich. We discussed the importance of simulation, the limitations of hardware, how Docker can help bridge this gap, and the role of open source software in meeting such challenges.

In this podcast, Shane Hastie, the chief editor of Culture & Methods, talked with Raj de Datta about applying artificial intelligence in high-performance tennis, serving digital searchers, and providing a superior digital experience.

Panelists discussed their journey to integrate quality into development, including the obstacles they face, how they manage change, and their plans to integrate testing more deeply into development.

How can traditional security methods scale in a cloud-native architecture? Register now!

Learn from practitioners who drive software innovation and change. Participate in person on April 4-6, 2022.

Discover emerging trends and practices of software leaders. Participate online May 10-20, 2022.

A monthly guide to all topics, techniques and techniques every professional needs to know. Free subscription.

InfoQ homepage podcasts Joe, Florian and Sebastian on Indy Autonomous Challenge

The Technical University of Munich won the Indy Autonomy Challenge. Auto racing competition. In this podcast, Roland Meertens discusses the event itself, what makes it challenging, and the approach taken by the Technical University of Munich and Apex AI's Joe Speed, Florian Sauerbeck, and Sebastian Huch. We discussed the importance of simulation, hardware limitations, and how Docker can help bridge this gap. We ended the podcast by discussing the role of open source software in accepting such challenges.

You want to find network errors quickly and need a reliable tool. what to do? You are not alone. Try Fiddler Everywhere free for 30 days and let this all-in-one web debugging solution deliver the successful results you expect.

Roland Meertens: Hello everyone, and welcome to the InfoQ podcast. My name is Roland Meertens, InfoQ artificial intelligence and machine learning editor and Annotell product manager. Today I will host a podcast and I will talk with Joe, Sebastian and Florian about the Indy Autonomous Challenge and how they won it. Joe, Sebastian and Florian, welcome to the InfoQ podcast. Can you introduce yourself to the audience and tell them what the Indy Autonomy Challenge is?

Joe Speed: Of course, very happy. So, Joe Speed. I am the technical consultant of Indy Autonomous Challenge, which is an amazing university autonomous racing challenge.

Florian Sauerbeck: My name is Florian. I am a member of the TUM Autonomous Motorsport team. We finally won the challenge. My main responsibility is the mapping and localization part.

Sebastian Huh: This is Sebastian. I am a colleague of Florian and a member of the TUM Autonomous Motorsport team. My main responsibility in our team is perception, mainly object detection.

Roland Meertens: Well, maybe we can start with Joe. Maybe you can say what this Indy Autonomous Challenge is.

Joe Speed: This is an amazing program. So many are anecdotes. Therefore, Sebastian Thrun, who is very like the godfather of modern autonomous driving, won the DARPA challenge. When he was at Indy, he once commented: "Some things about autonomous driving are not so exciting to me anymore, but if this is the case, if the Indy 500 is autonomous, it will be very interesting. I will like it. "This is a kind of Genesis, that is, Indiana and many other states, Indy Circuits, universities, sponsors and technology companies, we work together to create the Indy Autonomous Challenge. This is an automatic racing challenge worth 1.5 million US dollars. So around the first stage of the simulation... Florian and Sebastian talked more about it. Then it culminated in the race on October 23, which was held at Indy Circuit last month. But it turns out that people are so interested in the momentum behind it that there are other aspects to it. Well, I will tell you more about the next step later.

Roland Meertens: So this is automatic racing, but I have to think about how fast, how fast do they drive?

Joe Speed: Well, there are a few things. So one is how fast the vehicle is capable, and then what can the autopilot software and autopilot suite do? So all sensors, actuators, and wire-controlled drives need to be processed. A completely different topic is the actual track conditions, right? Therefore, a race on a cold track in October is completely different from a race at the end of May, when the weather was very good, very hot, and the rubber was very sticky.

Roland Meertens: So should I think about speed?

Joe Speed: Well, we haven't tested it for maximum speed yet. The design speed of the vehicle is approximately 180,185 miles per hour. Under normal conditions, the Indy Light car can reach a speed of 200 miles per hour, but we have made some improvements to the car to make it more durable. So, in this challenge, we really can't change the engine after every game. So we have some very reliable power plants in these areas.

Roland Meertens: So if I think about the Indy race, it just drives in one direction within a lap, right? What makes this challenging? Maybe this is something Florian can talk about.

Florian Sauerbeck: I think the main challenge we face is when we started the whole project, the first time I heard it was basically at the Christmas party we held here at the end of 2019, when COVID was not a topic. Then around May to June, when we really started to think about how to challenge this project, things started to get serious. So we don’t know what the game will look like in the end? How many competitors will we have? How many cars will hit the track? What speed must we consider? We don't even know the exact sensor settings or calculation settings of the car. So everything is still under discussion, and things change every week. So we still have to make a plan and have to consider what our software will look like, but we don't actually know what challenges we will encounter in the end.

Roland Meertens: How do you solve such a problem that you didn't know what you will face in the first place?

Sebastian Huch: We first build a team. On average, we have 12 PhD students, but all of us have a lot of students and undergraduates who support us. First of all, in our team of 12 doctoral students, we split the modules that must be covered. Of course, first we start with perception, and then of course positioning and parallelism, prediction, planning and control. Then we basically assign personnel to each task based on their PhD program. Then the first step is that we generate or develop those algorithms that need it. Then we tested them in a simulation. Therefore, we built our own hardware-in-the-loop simulator in the laboratory. We can test the entire software stack that we have developed in the past year or two, and we can test it here, which is a very critical part.

Sebastian Huch: So this is our first step. I think the main challenge here is also, so we start with simulation. At the time we thought, well, maybe the biggest challenge is that we have to develop all these algorithms, but now a month ago, just a few weeks or days before the actual game, this is no longer a challenge. So the biggest challenge in the end is more like, well, as Florian has already mentioned. We have no experience with tires and cars, so we have to find the limit at the end. So this is not only related to the software, but also to some competition strategies and tire temperature. As I mentioned before, no one has experience in this area. So this is a very interesting journey in the past year or two.

Roland Meertens: In terms of race, are there many people on the track?

Joe Speed: This has always been intention and plan. You have to back up a bit. We have to build and deliver the first car on the track and run-in tests, and COVID and other challenges have also been delayed. Delays will delay the construction of additional cars. So really, these people participated in the October 23rd race, but they didn't have the number of track days everyone expected.

Roland Meertens: But you mentioned that you have a hardware-in-the-loop simulator. Do you have to build it yourself or is it already available?

Florian Sauerbeck: So the entire team we formed for Indy Autonomous Challenge is basically based on the team that participated in Roborace before. So we have an existing simulation. We have provided some existing algorithms on GitHub. This is our starting point. So we didn't start from scratch, but we already have something in simulation, but the whole perception theme is new in Indy Autonomous Challenge. So we must also develop sensor simulation, environment simulation, and we must also change the vehicle dynamics model, because the car is brand new, and there are interactions. Now, there are 10 computers connected to our hardware-in-the-loop simulation. Therefore, we can run 10 times the full software stack and can basically compete with our own software.

Roland Meertens: In terms of cars, what kind of cars do you actually get? What kind of sensors are there? How many computers does the car itself have?

Sebastian Huch: Well, as far as the car itself is concerned, it is mainly a computer that the team can use, and we can decide what to run on this computer. In terms of sensors, if you think of self-driving cars, we have everything you need. So we have three lighter sensors, and we have six cameras in total. Both of them cover a 360-degree field of view. Then we have three radars, one on the front and two on the side. We obviously have GPS. We have two GPS systems just for redundancy. Finally, we also have tire temperature sensors. As I mentioned before, tire temperature is an important factor here, but we haven't studied these tire temperatures before we actually reach high speeds, because at low speeds, it's not very important. So these are only important one or two weeks before the actual game.

Joe Speed: So to build a car for this app, you will encounter a lot of new things, right? So this car is an adaptation of Dallara Indy Light 15. So this is called AV-21. So they built a monocoque body in Parma, Italy. They flew them to Indianapolis, where they were assembled, and Juncos Racing was in charge of all the assembly work. Then they took them to install the A-stuff of the autopilot kit. They brought it back to do all the final suspension break-in. The problem is that none of the autonomous kits here are really designed for racing.

Joe Speed: Its normal application is a self-driving taxi, and the running speed will be a little slower. Then you will encounter some problems, such as tires not starting to heat up until 120 miles per hour. Prior to this, no fleet had driven more than 100 miles per hour. So you have cold days, you don't have a tire heater, you have to do some warm-up laps, but you have to exceed 120 or the tires don't warm up. So there are really many new areas here.

Roland Meertens: How did you approach the construction of this car? So you mentioned that you have something that is usually used in self-driving cars. You just modified an existing car. Do I understand?

Joe Speed: Clemson took the lead in assembling the first car, which will become a template for the team's other models. They do this through a lot of iterations and feedback from the team. So TUM and other teams provided feedback, I like that sensor. I do not like this. Provide feedback on the placement and the field of view they want the camera to. They want or don't want stereo cameras and all these things, but many things won't start to figure out until you start spending time on the track.

You start to discover that it turns out that the backward radar will interfere with the forward radar of other cars because they all operate on the same frequency. You begin to understand things like GNSS antennas require special isolation brackets. You will not learn these things until you are on the right track. To be honest, if we got the first car on the track in January, then iterated from there and delivered the entire team on the Indy 500 on May 29th, I think you will see all the cars on the track in October 23rd, but this is just difficult. Even in times of prosperity, this is a daunting challenge, and COVID will not help.

Roland Meertens: Back to the original question. So what kind of method works here? Do you just use GPS for waypoint tracking, or do you implement some end-to-end deep neural networks, or what methods do you use when building a car?

Florian Sauerbeck: What I want to say is somewhere in between. So from the very beginning, we wanted to develop a racing software stack that was able to perform multi-car racing and race with others, defend positions, and overtake. Therefore, it is impossible to just follow the following method. So we planned a software that also takes into account other cars, it makes some predictions about where other cars will go in the future, and then it lands its maneuvers. So of course there is a globally optimized track that our software basically calculates. It says that if there is nothing else in front of you, this is the fastest way to get around the track. But if there are other cars, the car has to make some decisions. So sometimes it is better to stay behind another car. Sometimes it is better to overtake on the inside or outside. So we have been thinking about this issue, and we have developed a software stack that is able to make these decisions and bring them on track.

Roland Meertens: You mentioned that you have competed with other universities in the simulation?

Florian Sauerbeck: That's right. So this is also part of the challenge, some simulation games. So in order to be eligible for the final on October 23, we must conduct a simulation competition, and all teams must prove that they are capable of doing these things. Also at Lucas Petroleum, we were testing another track, we also showed real cars of us and some other teams on the real track, we actually overtook and avoided other cars.

Roland Meertens: What problems did you find in the simulation game and the real game? I heard that you picked up the car late?

Sebastian Huh: That's right. So the simulation game, I guess, will be around May this year. Then after that, I think we got the car around August or September. So in the middle, we have a little time to adjust all the algorithms to adapt to the real world. So perception is not part of the simulation. So basically our car got the exact position of other cars in the simulation. So when we get a real car for the first time and embark on a real race track, of course we have to test our perception, our entire perception stack. We did this in our own simulation, in the hardware-in-the-loop simulator in our laboratory.

But then again, there is a huge difference between the perfect world in simulation and the simulation in simulation, and once you enter a real car, there will be a lot of noise in the sensor. So there is a huge gap between the simulated and real cars here. But not only the sensor, but some interfaces are also different. Therefore, the time to change the software from a simulation to a real car is very limited. But I think we did a good job in the end, because we used Docker, and then using the Docker system, we can easily deploy the Docker container we have used in the simulation. We can use them directly on real cars.

Roland Meertens: So how did you get this Docker solution? Have you tried multiple methods, or how did you do it?

Sebastian Huch: As I mentioned before, we have different modules. So basically we have the whole thing of perception. Then we have forecasts, we have plan control. These are our main modules, and basically every module here runs in our own Docker container. They only communicate through ROS. In each Docker container, there is a ROS run by multiple ROS nodes. Then the communication is just the publisher scheme with the normal subscribers of ROS

Roland Meertens: So you use the microservice approach in the racing car and the embedded hardware.

Sebastian Huch: Kind of, to be precise.

Roland Meertens: Interesting. So how does it work with his spacecraft software working group? How do you ultimately decide what the team can access and what they can manage, etc.?

Joe Speed: This is an open competition, so they can use any software they want. Commercial, open source, local, anything. Back to the beginning of the challenge, the team was using some ROS and a lot of commercial software. But what I have seen, I think the ISE organizers, they may think that all we have to do is to build this physical car, and then give it to the team, and then we will wish them all the best and luck. They are very smart and they will figure out the software. Based on my experience, I am thinking, I think this is not enough. This may be enough for TUM, but for other universities that simply don't work. So TUM leader Alex, myself, Gina O'Connell, Neil Pusef, and Josh Whitley of the Autoware Foundation. What we did was to form this ISE basic vehicle software working group.

So Alex represents all the universities and what they need. Then the rest of us worked with the open source community and member companies to get contributions. We assembled this stack for the team, no one needs to use it, but it is a reference implementation... Our idea is to let us develop a stack for the team so that the cars can enter the yellow flag circle, and then the team will do it. Accept and let it participate in the competition.

This is Open Robotics ROS 2. So we let them go from dash to Foxy, which is the basic middleware using crypt. This is something like Cyclone DDS with Zenoh for V2X on Cisco radios. Xerox is built as a galaxy, so this is a zero-copy thing, and I will talk about it later. Then there is the Autoware Foundation, which includes LiDAR localization, wire control interface, and so on. I think the place we arrived is that all teams are using ROS 2. Most use Foxy and cyclone. Some teams use Autoware autopilot packages. Then TUM actually made some upgrades to gain a competitive advantage.

Sebastian Huch: Well, so I think you want us to say, Joe, we are using ROS 2 Galactic, right? So at the beginning we also used ROS 2 Foxy, but then we discovered that we encountered some problems, especially when using the rosbags implemented in ROS 2 to record some data. Here we have a huge acceleration to ROS 2 Foxy compared with ROS 2 Galactic.

Joe Speed: As we all know, rosbag2 was destroyed in Foxy. So your friends Apex.AI, Dejan and many of them are from TUM, so RA is very close to the TUM team. Therefore, Apex asked ADLINK, Bosch, and Tier 4 to provide engineering support and funding for the company Robotech.ai and Warsaw to automate Volvo trucks. Therefore, they refurbished the rosbag to increase its speed in the galaxy by six times so that it can record everything in the ISE race car. Because you are talking about it is six cameras, the speed is up to 150 frames per second. I have 3D Flash LIDAR. So I have all these high-bandwidth sensors, and I have to write them to disk, otherwise I don't have my test data. I don't have my training data.

Roland Meertens: So this is actually about hardware write speed limitations.

Joe Speed: Well, these are two things. So how is its software and its efficiency in capturing and writing? So Robotech did some smart things with double buffering. Therefore, it is a right of the disk to collect all the small messages together and then do so. Therefore, it is more efficient to do a small number of large permissions than a large number of small permissions. Then there is ADLINK, we basically try to provide the fastest hardware. Therefore, each car had a capacity of 3 TB at the time, which was the fastest NVMe SSD we could get. I am now considering using FireCuda PCIe Gen4 to refresh. It is the fastest NVMe SSD in the world. So I am discussing updating it with Seagate.

Roland Mertens: Okay. This allows you to obtain all the data needed for off-vehicle processing or off-vehicle analysis. How does it help you?

Sebastian Huh: That's right. So in one run, usually about 20 minutes, I think we recorded an average of 20 pure raw data. This is mainly data from lidar, so the point cloud is very large. We used those point clouds. So basically we just use the point cloud we recorded to test our algorithm offline. But of course we also recorded all GPS data, we can optimize our trajectory.

Florian Sauerbeck: In addition to our previous closed-loop simulation using limited reality and sensor data. It also allows us to perform some kind of open loop data replay with our software. But so we got actual data from the actual racecourse.

Roland Meertens: This way you can match the simulation with actual events. Is that right?

Sebastian Huh: Yes, that's right. So this is a point, once we get the real data, we can also adjust our simulation and adjust the simulated sensor model, or adjust the noise model of the LiDAR sensor. But we can also use real data to make adjustments. For example, we use neural networks for object detection in other racing cars. Here, we can use only data to train this neural network.

Joe Speed: I have a theory, but... Florian, Sebastian, tell me if I am right or crazy. Object detection is important, but object classification is not because if there is an object, it is a racing car.

Sebastian Huh: That's right. Then we also had this object to avoid the race at the end of the high-speed running. And there is only one object here. There is only that kind of tower on the track. So classification is not important to us. So once there is an object, we know, well, we must avoid this object. We have to get around this object, we don't care if it is a car or a tower, we just don't have to enter this object.

Joe Speed: So these towers, and the huge inflatable devices they put on the track. So cars must avoid these large inflatable toys. They opened up a blocked lane.

Roland Meertens: What approach did you take? Do you just use a common deep neural network based on vision or how do you train it? Where do you get your training data?

Sebastian Huch: We used a neural network based on point cloud lidar data. We only use it for object detection in other cars, not for pylons. In this case, we used a normal clustering algorithm. But for object detection of another race using neural networks, we started to use the data we generated in the simulation for initial training. So those are the kind of perfect point clouds. We have implemented some very simple noise models here, but they are still perfect for those point clouds. We use these as initial training, and then once we get some good results in the simulation, we try to use the state of this neural network and use it on the real point cloud we recorded with rosbags. Then once the neural network detects something there, we can use those detections, fine-tune them manually, and then use these newly generated tags and point clouds as the new basis for our new dataset. This is an iterative process. So we have done a lot of loops here.

Joe Speed: There is also some learning here. Therefore, using LIDAR, they published a range of different conditions, things and reflectivity. More than a year ago, I pointed out to Clemson and IAC that Lidar does not like pure black because black will absorb it. They were like, "Oh, this is fun." I said, "Yes, you should use bright, reflective things." But the people at IAC, I think Indiana, they like... this car It looks like Darth Vader's car.

It looks like a Batmobile, with carbon black on it, which looks great. I thought, "Yes, but LIDAR doesn't like that." So when they started testing, they eventually realized that there were some problems. So one is that they are pure black. But on the other hand, if you see these racing cars, they are basically shaped like stealth fighters. Therefore, the design of the stealth fighter is non-reflective, so the sensor does not have a flat surface. This is for different reasons. So stealth fighters do this to escape. The car does this for aerodynamics, but it will give you the same result. So this is why one day you see all the cars turn from black to highly reflective white.

Roland Meertens: So you basically always drive under the radar. So the other thing I saw was that you actually had a spin during the test that caused the game, right?

Florian Sauerbeck: That's right. So it was actually the Thursday before the game, just two days before the final, when we no longer thought about software architecture, but more about the game you imagined. Therefore, please consider the tire temperature, track conditions, and reaching the limits of car performance. We increased our speed. On the same day, many parties started from Milan, and they turned out in the first round. Somehow, we are very confident that we might go a little faster than them. Then the same thing happened to us, just after the first turn, the car skidded at a speed of about 220 kilometers per hour. We were at the control station and we could only hear the sound of the tires. We were just waiting for the impact, but it did not come. Later we checked the data and the car was about 50 cm from the wall where it stopped moving.

So we are very lucky that this car did not suffer any damage today. In the end we also got some data that is very important to us, because we know where the limits of tires and cars are under these conditions at least on this day.

Sebastian Huch: So maybe I have to add, what happened here. So we start with a lower speed. I'm not sure, maybe it's about 50 meters per second. Then we increase the speed, one or two meters per second per half circle. Then as I mentioned, the car made a very beautiful 360-degree turn, but then we knew exactly that it was half a lap before everything was normal. So we know exactly the configuration and tire temperature limits, which is very useful because this is actually the last track day, or basically the Thursday before the race. But it only rains on Friday. So this is the last track day we can use before the actual race. Then we have about 48 hours to figure out what speed and strategy we want to use on the actual match day.

Roland Meertens: This is basically chaos engineering to ensure that cars collide so that you can learn how to prevent these collisions.

Sebastian Huch: Okay, but our goal is not to make the car really spin. I think this is also the maximum speed we want to drive today, so we won't increase it anymore. But in the end, I think it’s worth knowing the limit before the actual race, because then we can plan ahead of time how fast we can drive safely on the day of the race.

Joe Speed: The term team, they adjusted, and then Juncos Racing, Lauren and the team adjusted the car. Therefore, some changes were made to the suspension, and the rear arrow kit was changed to increase the downforce at the tail. So they all did this on Thursday night. Then on Friday, it rained all day. It's raining all day, it's not just a lost track day. It also washed away all the rubber on the track. So now you have a track, a track that is not as sticky as the day before. This is why they participated in the Autonomous Challenge on Saturday.

Roland Meertens: So you have to reduce your speed based on the data you have. This is a completely different situation.

Florian Sauerbeck: Yes, this is one of the countermeasures we did try to increase the speed, but we also tried to make the tire temperature higher by accelerating and braking on the straight. We also made some final adjustments to the controller. So we hope that we can obtain other limits or higher limits in terms of lateral acceleration than the previous day.

Roland Meertens: You mentioned that software before. You took some packages from the Internet on GitHub. How does this work? Can I build my own automatic racing car?

Florian Sauerbeck: I think if you have enough time and motivation and a car to deploy your software, you can do it. I think it is definitely possible. So there is a huge community. This is important for all teams, because in such a short period of time, if you can't build something, it's impossible to achieve such a thing. So the whole open source thing is very important to all teams. We also hope to give back to the community and open source the software we developed to meet this challenge.

Joe Speed: TUM team, great. They announced their intention to go, and then when they won, they did so. So they open sourced everything in the car the next day. Therefore, they immediately open sourced everything in the car. So now you have someone like Johannes Bates, who is the co-founder of the TUM racing team. He is now at the University of Pennsylvania and he is in charge of F-1/10th. Therefore, he is working hard to adopt the tomb software stack, integrate it with the free and open source SVL simulator, which is uniformly written like the TUM simulator, and then put it on AWS, which can be used by any university in the world to learn . Therefore, we really hope to open this ISC to not only qualified people, but also to all participating universities in the world. So this is a very exciting thing.

F-1/10th is a great thing, you can take a 1/10 scale remote control car, then you put a Jetson and a camera, and then you teach it to race. So we have an idea. If you think the Indi Autonomous Challenge is the pinnacle of autonomous racing, how can we make it accessible so that any student in the world, even high school students, can learn and participate in it? So if we can get the TUM stack, the entire ISC software stack running in these 1/10 scale karts, you will consider these. Since then, it has entered the SAE formula, student driverless things, such as the EV Grand pre-autonomous, which is a brilliant racing league. You take an electric kart worth $4,000 and let it drive itself, right?

Compared with a self-driving challenge car worth $1 million, it is very easy to obtain. But I think the whole thing will bring amazing achievements to the community. A long list of improvements have taken place in ROS and Cyclone, Zenoh and Autoware, and all these open source software packages taught and used in universities. As TUM and these teams work with the community and use the software, a long list of improvements has occurred.

Roland Meertens: Do you have to post a lot of questions on GitHub, saying that as long as my speed exceeds 100 miles per hour, your software will break?

Joe Speed: Well, yes, not that exact situation, but yes. So the open source community, we live in a stable diet of pull requests and GitHub issues, and this is why the community thrives. TUM is very helpful in feeding us.

Roland Meertens: After the Indy Autonomous Challenge, what is the next step? What is your next thing to do, or what is the next big thing we must focus on?

Sebastian Huch: As Joe mentioned before, there is a follow-up event plan, which will be held in Las Vegas in early January as part of CES. And there will be a game. There will be a multi-vehicle race where the participating teams will also participate in the Indy Autonomous Challenge, which will be held on January 7th. So we also plan to participate in this challenge. We have prepared everything we can use. We can use the software again for the software we have used in recent months. Of course, we have to make some adjustments. We have implemented a new map of the Las Vegas Motor Speedway in our own simulation. Similarly, before we actually enter the actual runway, test everything here in a simulation.

Roland Meertens: Suppose I am currently a software engineer working in banking systems or other jobs. How can I start? How can I transition to robotics? What is the best way?

Florian Sauerbeck: I think the most important thing is to expose you to real robots. So you can find many projects and open source projects on the Internet. I think the most important thing is to start and research something. Of course, you need to know some theoretical basics about robotics, but the most important thing is how all these applications work together? How does the sensor work? How do you get the data, how do you use it? I think the best place to start is to start your own small project.

Joe Speed: The instructions for making these scale model cars are all open source, so you can download the instructions directly. They are all online. You can order all the products you need from people like Mouser and Amazon. This is really an eclectic leak. So you already have an F-1/10 in Madurai at the University of Virginia with Johannes Bates, Lauer and Vincart. Chris Anderson and all his friends had donkey carts and DIY robot cars at the Berkeley track launch. There are jet robots, jet racing, deep racing. So there are many options at different price points and different performances. So anyone since high school. This is one of the lovely things. For the F-1/10 community, the largest F-1/10 community is in Stuttgart. So these are not all students. These are boring automotive engineers who want to do something interesting. So it's great to see all the communities and industry players are cooperating in this regard.

Roland Meertens: Okay, that sounds great. Then thank you very much for joining the interview podcast and thank you for listening. Have a nice day.

Florian Sauerbeck: Thank you for inviting us!

Sebastian Huch: Thank you for inviting us here.

Learn how to solve complex software engineering and leadership challenges. Attend QCon London in person (April 4-6) or QCon Plus online (May 10-20).

QCon brings together the world's most innovative senior software engineers across multiple fields to share their actual implementation of emerging trends and practices. Look for practical inspiration (not product promotion) from software leaders who are deep in the trenches in creating software, extending architecture, and fine-tuning their technical leadership to help you make the right decisions. Save your location now!

James Clark on how Ballerina handles network interaction, data and concurrency

Meenakshi Kaushik and Neelima Mukiri on the fairness of responsible artificial intelligence and machine learning algorithms

Event-driven scale architecture

Michelle Brenner builds Netflix workstations and enables artists to create from anywhere

Progress's Fiddler Everywhere provides developers with a modern solution to test and debug network traffic and Web API. Start the free experience.

A summary of the content on InfoQ last week will be published every Tuesday. Join a community of more than 250,000 senior developers. View example

You need to register for an InfoQ account or log in or log in to post comments. But there is still a lot to do after registration.

Take advantage of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

A summary of the content on InfoQ last week will be published every Tuesday. Join a community of more than 250,000 senior developers. View example

The international software development conference QCon will return in 2022 (face-to-face and online). QCon brings together the most innovative senior software engineers in many fields around the world to share their implementation of emerging trends and practices in the real world. Look for practical inspiration (not product promotion) from software leaders who are deep in the trenches in creating software, extending architecture, and fine-tuning their technical leadership to help you make the right decisions. Save your location now!

InfoQ.com and all content copyright © 2006-2021 C4Media Inc. InfoQ.com is hosted at Contegix, the best ISP we have ever worked with. Privacy Statement, Terms and Conditions, Cookie Policy