Racing radio-controlled tarantasses for 4 weeks
Hello! I am one of the creators of the race of radio-controlled tarantas .
www.redbullsoapboxrace.ru is an online project dedicated to the Red Bull Soapbox Race event and is a miniature tarantass racing.
A post was written about our project, and this is an answer to an invitation to talk about the project.
')
The idea was born in the kitchen over a cup of coffee, and how it all happened and how we managed to implement the project in 4 weeks, read on.
I publish a post at the request of Dmitry Maximov - the author of the idea and architecture of the project.
In fact, we did have only 4 weeks to launch the project, but, surprisingly, with a team of 6 people we coped with this task. For us, this was a good school of teamwork in extreme conditions.
The architecture at first glance is quite simple:
Considered several implementation options:
The last option went perfectly!
On the machine is installed on-board computer on Linux with 6 usb, which is connected to the microcontroller for DC motor (collector motor for movement) and the microcontroller for the servo drive (responsible for turning the front wheels).
Plus, a magnetic sensor is connected to the computer to record the lap time, and via usb - a camera and a wi-fi adapter.
It looks like this:
The only minus of phidgets was that we needed 7 sets for 7 machines, and that number in the complete set could only be bought in Canada.
From the very beginning, they planned to use this machine: Monster Truck from HCP Racing . The machine is professional, and it is easy to find spare parts for it.
Even before the start of the project, we consulted with the guys from Glavbot , who recommended cars with brushless motors, since the collector ones would have to be changed every 3 days at the planned load. But phidgets work only with DC motors, so I had to take a risk, which, by the way, was justified in the end - the motors, of course, had to be changed, but not often, and not because of the heavy load.
The machine can reach speeds of up to 16 m / s, and the racing room is 15 m long, so I had to figure out how to slow down:
The battery, which comes with the machine, allows you to continuously drive for about 15 minutes. The races are practically around the clock and we wanted to make sure that more people could ride, so technical breaks had to be reduced to a minimum.
As a result, we picked up a version of batteries that can hold a charge for up to 4 hours, but we, just in case, change them every 2 hours.
It seems with all the components decided, it was necessary to get everything, program and test.
UPD: As promised, we publish the remaining information about the project!
As I wrote earlier, we had to order fidgets from Canada directly from the fidget site. There were about 30 microchips in total, which would definitely hang on the Russian customs for a couple of months, so they drove through Finland with a double customs clearance. In July, according to the fidgets, a distributor will appear in Russia, but we didn’t have that much time.
When we had everything in our hands and we assembled the first prototype, the weight of the machine turned out to be 3 kg (excluding the hull) - we had to strengthen the shock absorbers so that the machine would not go on the belly.
In the end, it looked like this:
With the help of the program that came with the Windows fidget, we were able to test the work of the fidget, and immediately found several problems.
The Fijet camera transmitted the image in terrible quality, which constantly hung up at a resolution of 320x240 and 10 frames per second
At first there was an assumption that this was related to the fidget itself, so they decided to immediately use an IP camera so that the video went directly. But this option has made the machine another 500 grams, and this she could not withstand at the planned load.
We tried another UVC-compatible camera (Logitech HD Pro Webcam C920) with autofocus, Full HD image and hardware video codec in h.264, and the result was just great! It is true that the h.264 codec could not be used because it was not supported by fjetts. I had to stop at MJPEG.
We also tried a cheaper version of the Logitech HD Webcam C525 (now stands on the online broadcast from the track), but the video again began to freeze.
We also noticed that if there are wires next to the camera, the quality of the picture deteriorates significantly, so the camera body was not removed, although from an aesthetic point of view it would be better if the camera is in the machine case.
The length of all wires had to be shortened due to interference affecting the operation of the camera and wi-fi adapter.
Rides last 5 minutes, at the same time in the races can participate 5 machines. There are 2 spare machines that are activated if one of the 5 fails to pass ping.
Between races, 1 minute is allotted for switching control from one user to another.
Every 2 hours - a technical break for 30 minutes for the replacement of batteries and repair, if something went wrong.
Initially, we thought that the biggest problems would arise with video lags, or rather, with a delayed signal associated with the remoteness of the user from Moscow. Users who are farther than 200 kilometers from Moscow (where races are physically running) will definitely have problems with skating. Moreover, they will not even understand that a delay is happening: the machine just becomes poorly controlled - the user pressed forward, and the machine went only half a second later. This is not a big problem for moving back and forth, but it was critical for turns. But we considered it not right to limit participation, and did the following:
1) Anyone who lived within a radius of 200 kilometers could sign up for the near future.
2) Other cities could enroll starting from the end of the schedule.
There was no problem with the delay, but in any case there were no bad reviews at the beginning.
Later we expanded the possibility of recording for the near future for the entire central region.
For quality skating it was very important that the delay was minimal, so the options for broadcasting video from the machine through the media server disappeared.
There were options for the user to install a Java plugin for himself, but, firstly, he weighed a lot, and secondly, hardly anyone would install it himself. We also wanted to use the Flash element, but it required the presence of the security file crossdomain.xml on the domain with the video stream, and the httpd web server did not manage to configure the mime types for the xml files.
We stopped on the following version:
For FF, Safari and Chrome, we use the tools of the browsers themselves, which can support the MPEG stream. For other browsers, Java script with image update. As a result, the delay in the local network was 50 milliseconds (for reference, the machine becomes almost uncontrollable with a delay of half a second).
Sometimes it turned out that when connected to a typewriter, the DC controller was not connected, i.e. user could not go forward / backward. We have fixed this problem by reconnecting. Therefore, during the countdown and the first few seconds after the machine is in place, and after 10 seconds, finally starts to go.
A server is a regular computer with the following parameters:
- Intel Core i3-2100 processor
- motherboard GIGABYTE GA-H61M-S2V-B3
- RAM DDR3 DIMM Hynix - 4 GB
CPU load, if skated 5 machines, is not more than 10 percent.
We planned to use a dedicated 100 MB channel. In the end, we had the channel of 20 Mbit. With one-variable participation in the race of five machines outgoing traffic is about 7 Mbps. Inbound traffic is generally not significant.
First tried to use a home router from Trendnet. However, when three machines were connected at the same time, it began to hang. The position corrected the transition to the Linksys e1200 router from Cisco.
Periodically there are interferences in the wi-fi signal, and the ping of the machines either disappears or becomes unrealistically large. This happens every 2 days and lasts 5-10 minutes, then everything stabilizes. A clear pattern could not be identified. It is still interesting, what can this be included on Red October? :)
The biggest problem with management was related to the fact that the connection with the machine or the user periodically disappeared at the moment when the request was “forward / backward” - in this case the machine hung in the forward direction, stuck into an obstacle and burned the motor.
We thought about switching to another frequency of transmitting a wi-fi signal (5 GHz), but for this it was necessary to switch to a router and wi-fi adapters with 5 GHz frequency and install the appropriate drivers on the on-board computer. Despite the fact that the on-board computer is Linux Phidgets does not have a standard mechanism for installing drivers. Therefore, the idea of ​​switching to another frequency was abandoned.
At the beginning of the route was built, representing a figure of eight, with a smooth rise and steep descent.
A magnet was installed on the trigger (normal, for sharpening knives), which activated a magnetic sensor to record the lap time.
We planned to make a constant speed of the machines, limiting it to such a value that the machine would climb onto the slide without any problems. But faced with the dependence of the speed of the state of charge of the battery. After 4 laps, the machine could not climb up without increasing the speed, so it would be necessary to change the batteries or increase the speed every 4 laps.
We chose the second option in order to automate the process as much as possible and reduce technical interruptions. Speed ​​adjustment was made to the machine control interface. The user has the opportunity to add speed using the AZ buttons to climb the slide.
When the project was launched, it turned out that the climb is not very interesting from the point of view of skating - it is narrow, it is difficult to turn around if it crashed, and most users get stuck on it. The lift was removed and made a circular track with a small step, so that the user could not drive back.
While there was a lift on the track, we had to change the motors, because they were burning because of the applied voltage, if the machine did not move. Fans from laptops helped to cool the engine, but not always.
At some point, the motors in Moscow ended :-) I had to install a fuse that would break the contact between the controller and the motor when it was very hot. Unfortunately, this led to the fact that the user in the middle of the race just stopped and waited for the fuse to cool and recover. Now there is no such problem, since the route has been broken.
Fans used the most common from laptops:
In the first version of the assembly, the fans operated continuously, directly powered by batteries. But in this case, they quickly burned and, moreover, put the battery in, so the fans were connected to a separate port of the controller so that it turned on only when the machine was driving.
The body was made of solid foam, covering the top, and on the sides - the bumper of metal plates. In the process, our ears and fins flew off, and the eggs fell out of the nest, but the shells themselves remained intact:
Update 1 :
Maybe habreffekt, and maybe something else, but today 5 machines at the same time drove with difficulty. Put 2 routers - it became better.
Update 2 - about the lap time
Another interesting issue on the project was the choice of a time lapse system. There were several options.
Use a turnkey solution. For off-line radio controlled car competition, many clubs use My Laps professional time tracking system. The system consists of a decoder, transponders, which are installed on the typewriter and frame, fixing the intersection of the finish line. Moreover, if the machine crosses the finish line in the opposite direction, the decoder understands this.
However, My Laps is quite an expensive solution. We found an interesting alternative - the I-Laps system , which is almost as good as My Laps in terms of technical characteristics, but the price is several times cheaper.
I-Laps has its own competition software. However, it was not suitable for our purposes, since it was not possible to upload data from the system to show the time of each lap and the best lap time after the end of the race.
We also found DCD timeR - it looks like a very elegant solution, and for the price it was affordable. But the manufacturers said that they could not make an API for us so that we would upload the data to our website. It's a pity - we really liked this decision.
We almost got used to the idea that we would have to write integration with I-Laps ourselves, but it turned out that an analog magnetic sensor could be connected to the on-board computer. As the magnetic field increases, it sends a signal to the onboard computer. As a source of magnetic field, we used a magnet to fasten the tools to the wall. Gol asked a question about how we coped with the fact that the cars can move across the finish line in the opposite direction. While decided by the steps. More interesting solutions - put on each machine two magnetic sensors. Then by the sequence of their operation you can determine in which direction the machine crossed the finish line.
There are really a lot of people who want to go - we had to open the night hours for the races so that everyone could try. It is a pity, of course, that not everyone was able to drive normally, but this is only the beginning!
www.redbullsoapboxrace.ru is an online project dedicated to the Red Bull Soapbox Race event and is a miniature tarantass racing.
A post was written about our project, and this is an answer to an invitation to talk about the project.
')
The idea was born in the kitchen over a cup of coffee, and how it all happened and how we managed to implement the project in 4 weeks, read on.
I publish a post at the request of Dmitry Maximov - the author of the idea and architecture of the project.
In fact, we did have only 4 weeks to launch the project, but, surprisingly, with a team of 6 people we coped with this task. For us, this was a good school of teamwork in extreme conditions.
Week 1
Architecture
The architecture at first glance is quite simple:
Considered several implementation options:
- Ready cars with control over the Internet . This option was obtained in gold, so they refused it immediately.
- They applied to www.jokerracer.com , but they said that it took them half a year to create a project and it would take as much to re-raise it, and we had a little more than 3 weeks. By the way, they were just pokatushki, not a race. So, we can still wear the title of "First in the world."
- Aurdino, which at one end is inserted into the usb port, and the other clings to the console and transmits a radio signal to the machine. However, under the Arduino, development in a low-level language was required, and time was running out.
- Phidgets is a platform with a high-level API in more than 20 languages ​​and libraries for controlling engine controllers, cameras and all sorts of sensors.
The last option went perfectly!
On the machine is installed on-board computer on Linux with 6 usb, which is connected to the microcontroller for DC motor (collector motor for movement) and the microcontroller for the servo drive (responsible for turning the front wheels).
Plus, a magnetic sensor is connected to the computer to record the lap time, and via usb - a camera and a wi-fi adapter.
It looks like this:
The only minus of phidgets was that we needed 7 sets for 7 machines, and that number in the complete set could only be bought in Canada.
Cars
From the very beginning, they planned to use this machine: Monster Truck from HCP Racing . The machine is professional, and it is easy to find spare parts for it.
Even before the start of the project, we consulted with the guys from Glavbot , who recommended cars with brushless motors, since the collector ones would have to be changed every 3 days at the planned load. But phidgets work only with DC motors, so I had to take a risk, which, by the way, was justified in the end - the motors, of course, had to be changed, but not often, and not because of the heavy load.
The machine can reach speeds of up to 16 m / s, and the racing room is 15 m long, so I had to figure out how to slow down:
- If you put the resistors, then the machine will not go on the battery that has sat down. We celebrate.
- We thought to make the gearboxes, but we would have made a manual assembly, which, with the planned load, would break daily. We celebrate.
- Looked into the API fidgets and oh, a miracle! - it is possible to adjust the speed. On this and stopped.
Batteries
The battery, which comes with the machine, allows you to continuously drive for about 15 minutes. The races are practically around the clock and we wanted to make sure that more people could ride, so technical breaks had to be reduced to a minimum.
As a result, we picked up a version of batteries that can hold a charge for up to 4 hours, but we, just in case, change them every 2 hours.
It seems with all the components decided, it was necessary to get everything, program and test.
UPD: As promised, we publish the remaining information about the project!
Week 2: Build
As I wrote earlier, we had to order fidgets from Canada directly from the fidget site. There were about 30 microchips in total, which would definitely hang on the Russian customs for a couple of months, so they drove through Finland with a double customs clearance. In July, according to the fidgets, a distributor will appear in Russia, but we didn’t have that much time.
When we had everything in our hands and we assembled the first prototype, the weight of the machine turned out to be 3 kg (excluding the hull) - we had to strengthen the shock absorbers so that the machine would not go on the belly.
In the end, it looked like this:
With the help of the program that came with the Windows fidget, we were able to test the work of the fidget, and immediately found several problems.
Camera
The Fijet camera transmitted the image in terrible quality, which constantly hung up at a resolution of 320x240 and 10 frames per second
At first there was an assumption that this was related to the fidget itself, so they decided to immediately use an IP camera so that the video went directly. But this option has made the machine another 500 grams, and this she could not withstand at the planned load.
We tried another UVC-compatible camera (Logitech HD Pro Webcam C920) with autofocus, Full HD image and hardware video codec in h.264, and the result was just great! It is true that the h.264 codec could not be used because it was not supported by fjetts. I had to stop at MJPEG.
We also tried a cheaper version of the Logitech HD Webcam C525 (now stands on the online broadcast from the track), but the video again began to freeze.
We also noticed that if there are wires next to the camera, the quality of the picture deteriorates significantly, so the camera body was not removed, although from an aesthetic point of view it would be better if the camera is in the machine case.
The length of all wires had to be shortened due to interference affecting the operation of the camera and wi-fi adapter.
Week 3: Programming
Rides last 5 minutes, at the same time in the races can participate 5 machines. There are 2 spare machines that are activated if one of the 5 fails to pass ping.
Between races, 1 minute is allotted for switching control from one user to another.
Every 2 hours - a technical break for 30 minutes for the replacement of batteries and repair, if something went wrong.
Initially, we thought that the biggest problems would arise with video lags, or rather, with a delayed signal associated with the remoteness of the user from Moscow. Users who are farther than 200 kilometers from Moscow (where races are physically running) will definitely have problems with skating. Moreover, they will not even understand that a delay is happening: the machine just becomes poorly controlled - the user pressed forward, and the machine went only half a second later. This is not a big problem for moving back and forth, but it was critical for turns. But we considered it not right to limit participation, and did the following:
1) Anyone who lived within a radius of 200 kilometers could sign up for the near future.
2) Other cities could enroll starting from the end of the schedule.
There was no problem with the delay, but in any case there were no bad reviews at the beginning.
Later we expanded the possibility of recording for the near future for the entire central region.
Video
For quality skating it was very important that the delay was minimal, so the options for broadcasting video from the machine through the media server disappeared.
There were options for the user to install a Java plugin for himself, but, firstly, he weighed a lot, and secondly, hardly anyone would install it himself. We also wanted to use the Flash element, but it required the presence of the security file crossdomain.xml on the domain with the video stream, and the httpd web server did not manage to configure the mime types for the xml files.
We stopped on the following version:
For FF, Safari and Chrome, we use the tools of the browsers themselves, which can support the MPEG stream. For other browsers, Java script with image update. As a result, the delay in the local network was 50 milliseconds (for reference, the machine becomes almost uncontrollable with a delay of half a second).
Control
Sometimes it turned out that when connected to a typewriter, the DC controller was not connected, i.e. user could not go forward / backward. We have fixed this problem by reconnecting. Therefore, during the countdown and the first few seconds after the machine is in place, and after 10 seconds, finally starts to go.
Server
A server is a regular computer with the following parameters:
- Intel Core i3-2100 processor
- motherboard GIGABYTE GA-H61M-S2V-B3
- RAM DDR3 DIMM Hynix - 4 GB
CPU load, if skated 5 machines, is not more than 10 percent.
the Internet
We planned to use a dedicated 100 MB channel. In the end, we had the channel of 20 Mbit. With one-variable participation in the race of five machines outgoing traffic is about 7 Mbps. Inbound traffic is generally not significant.
First tried to use a home router from Trendnet. However, when three machines were connected at the same time, it began to hang. The position corrected the transition to the Linksys e1200 router from Cisco.
Periodically there are interferences in the wi-fi signal, and the ping of the machines either disappears or becomes unrealistically large. This happens every 2 days and lasts 5-10 minutes, then everything stabilizes. A clear pattern could not be identified. It is still interesting, what can this be included on Red October? :)
The biggest problem with management was related to the fact that the connection with the machine or the user periodically disappeared at the moment when the request was “forward / backward” - in this case the machine hung in the forward direction, stuck into an obstacle and burned the motor.
We thought about switching to another frequency of transmitting a wi-fi signal (5 GHz), but for this it was necessary to switch to a router and wi-fi adapters with 5 GHz frequency and install the appropriate drivers on the on-board computer. Despite the fact that the on-board computer is Linux Phidgets does not have a standard mechanism for installing drivers. Therefore, the idea of ​​switching to another frequency was abandoned.
Week 4: Test and Run
At the beginning of the route was built, representing a figure of eight, with a smooth rise and steep descent.
A magnet was installed on the trigger (normal, for sharpening knives), which activated a magnetic sensor to record the lap time.
Speed ​​adjustment
We planned to make a constant speed of the machines, limiting it to such a value that the machine would climb onto the slide without any problems. But faced with the dependence of the speed of the state of charge of the battery. After 4 laps, the machine could not climb up without increasing the speed, so it would be necessary to change the batteries or increase the speed every 4 laps.
We chose the second option in order to automate the process as much as possible and reduce technical interruptions. Speed ​​adjustment was made to the machine control interface. The user has the opportunity to add speed using the AZ buttons to climb the slide.
When the project was launched, it turned out that the climb is not very interesting from the point of view of skating - it is narrow, it is difficult to turn around if it crashed, and most users get stuck on it. The lift was removed and made a circular track with a small step, so that the user could not drive back.
Motors
While there was a lift on the track, we had to change the motors, because they were burning because of the applied voltage, if the machine did not move. Fans from laptops helped to cool the engine, but not always.
At some point, the motors in Moscow ended :-) I had to install a fuse that would break the contact between the controller and the motor when it was very hot. Unfortunately, this led to the fact that the user in the middle of the race just stopped and waited for the fuse to cool and recover. Now there is no such problem, since the route has been broken.
Fans
Fans used the most common from laptops:
In the first version of the assembly, the fans operated continuously, directly powered by batteries. But in this case, they quickly burned and, moreover, put the battery in, so the fans were connected to a separate port of the controller so that it turned on only when the machine was driving.
Housing
The body was made of solid foam, covering the top, and on the sides - the bumper of metal plates. In the process, our ears and fins flew off, and the eggs fell out of the nest, but the shells themselves remained intact:
Update 1 :
Maybe habreffekt, and maybe something else, but today 5 machines at the same time drove with difficulty. Put 2 routers - it became better.
Update 2 - about the lap time
Another interesting issue on the project was the choice of a time lapse system. There were several options.
Use a turnkey solution. For off-line radio controlled car competition, many clubs use My Laps professional time tracking system. The system consists of a decoder, transponders, which are installed on the typewriter and frame, fixing the intersection of the finish line. Moreover, if the machine crosses the finish line in the opposite direction, the decoder understands this.
However, My Laps is quite an expensive solution. We found an interesting alternative - the I-Laps system , which is almost as good as My Laps in terms of technical characteristics, but the price is several times cheaper.
I-Laps has its own competition software. However, it was not suitable for our purposes, since it was not possible to upload data from the system to show the time of each lap and the best lap time after the end of the race.
We also found DCD timeR - it looks like a very elegant solution, and for the price it was affordable. But the manufacturers said that they could not make an API for us so that we would upload the data to our website. It's a pity - we really liked this decision.
We almost got used to the idea that we would have to write integration with I-Laps ourselves, but it turned out that an analog magnetic sensor could be connected to the on-board computer. As the magnetic field increases, it sends a signal to the onboard computer. As a source of magnetic field, we used a magnet to fasten the tools to the wall. Gol asked a question about how we coped with the fact that the cars can move across the finish line in the opposite direction. While decided by the steps. More interesting solutions - put on each machine two magnetic sensors. Then by the sequence of their operation you can determine in which direction the machine crossed the finish line.
There are really a lot of people who want to go - we had to open the night hours for the races so that everyone could try. It is a pity, of course, that not everyone was able to drive normally, but this is only the beginning!
Source: https://habr.com/ru/post/146321/
All Articles