June 22, 2012 at 12:08 pm4-Week Race of Tarantasses
Hello! I am one of the creators of the race of radio-controlled tarantasses .
www.redbullsoapboxrace.ru is an online project dedicated to the Red Bull Soapbox Race event and is a miniature tarantula race.
A post was written about our project , and this is a response to the 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 really had 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 for team work in extreme conditions.
The architecture at first glance is quite simple:
We considered several implementation options:
The last option came up perfectly!
An on-board computer on Linux with 6 usb is installed on the machine, to which a microcontroller for a DC motor (a collector motor for movement) and a microcontroller for a servo drive (responsible for turning the front wheels) are connected.
Plus, a magnetic sensor is connected to the computer to fix the lap time, and via usb - a camera and a wi-fi adapter.
It all looks like this:
The only minus is phidgets - we needed 7 sets for 7 cars, and such a quantity in a complete set could be bought only in Canada.
From the very beginning we planned to use this machine: Monster Truck from HCP Racing . The machine is professional, and you can easily find parts for it.
Even before the start of the project, we consulted with the guys from Glavbot , who recommended machines with brushless motors, since the collector ones will 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, ended up being justified - the motors, of course, had to be changed, but not often, and not because of the heavy load.
The machine has a speed of 16 m / s, and the racing room is 15 m in length, so I had to figure out how to slow it down:
The battery that comes with the machine allows you to drive continuously for about 15 minutes. We had round-the-clock rides and wanted to make it so that more people could ride, so technical breaks had to be reduced to a minimum.
As a result, we picked up the option of batteries that can hold a charge of up to 4 hours, but we, just in case, change them every 2 hours.
It seems that they have decided on all the components, it remains to get everything, program and test.
UPD: As promised, we publish the remaining information about the project!
As I wrote earlier, fidgets had to be ordered from Canada directly from the fidget site. In total, there were about 30 microcircuits that would certainly hang at Russian customs for a couple of months, so they drove through Finland with double customs clearance. According to fidgets, a distributor will appear in Russia in July, but we did not have so much time.
When everything was on hand and we assembled the first prototype, the weight of the machine turned out to be 3 kg (excluding the case) - we had to strengthen the shock absorbers so that the machine did not ride on its belly.
In the end, it looked like this:
With the help of the program that came with Windows fidgets, we were able to test the fidgets, and immediately found several problems.
The Fidget camera transmitted an image in terrible quality, which constantly hung at a resolution of 320X240 and 10 frames per second.
At first there was an assumption that this was due to the fidgets themselves, so we decided to immediately use an IP camera so that the video would go directly. But this option made the machine heavier by another 500 grams, and this it 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 wonderful! True, it was not possible to use the h.264 codec, because it was not supported by fidgets. Had to stop at MJPEG.
We also tried the cheaper Logitech HD Webcam C525 option (now it’s on live broadcast from the track), but again the video began to freeze.
They also noticed that if there are wires near the camera, the picture quality deteriorates significantly, so they didn’t take the case off the camera, although from an aesthetic point of view it would be better if the camera is in the machine’s body.
The length of all wires had to be shortened due to interference affecting the operation of the camera and wi-fi adapter.
Arrivals last 5 minutes, at the same time 5 cars can participate in arrivals. There are 2 spare cars that are activated if one of the 5 fails ping.
Between races 1 minute is allocated for switching control from one user to another.
Every 2 hours - a technical break for 30 minutes to replace the batteries and repair if something goes wrong.
Initially, we thought that the biggest problems would arise with video lags, or rather, with a delay in the signal associated with the user's remoteness from Moscow. Users who are further than two hundred kilometers from Moscow (where the races are physically going) will definitely experience problems with skiing. Moreover, they don’t even understand that there is a delay: the machine just becomes poorly controlled - the user pushed forward, and the machine went only half a second later. For the movement back and forth, this is not too big a problem, but for turns it was critical. But we considered it inappropriate to limit participation and acted as follows:
1) Everyone who lived within a radius of 200 kilometers could sign up for the near future.
2) Other cities could sign up starting at the end of the schedule
This option did not solve the problems with the delay, but, in any case, there were no bad reviews at the beginning.
Later, we expanded the recording ability in the near future to the entire central region.
For high-quality skiing, it was very important that the delay was minimal, so the options for broadcasting video from the car through a media server were no longer needed.
There were options for the user to install the Java plug-in, but, firstly, he weighed a lot, and secondly, it is unlikely that anyone would install it for himself. They also wanted to use the Flash element, but it required the presence of the crossdomain.xml security file on the domain with the video stream, and it was not possible to configure mime types for xml files on the httpd fidget web server.
We settled on the following option:
For FF, Safari and Chrome - we use the tools of the browsers themselves, which can support MPEG stream. For other browsers, Java script with updating images. As a result, in the local network, the delay 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. the user could not go forward / backward. We fixed this problem by reconnecting. Therefore, during the countdown and the first few seconds after the machine stands still, and after 10 seconds it finally starts to drive.
The server is a regular computer with the following parameters:
- Intel Core i3-2100 processor
- GIGABYTE GA-H61M-S2V-B3 motherboard
- DDR3 DIMM Hynix RAM - 4 GB The
processor load, if 5 machines are skating, is no more than 10 percent.
We planned to use a dedicated channel for 100 mb. As a result, the 20 Mbps channel was enough for us. With the simultaneous participation of five cars in the race, the outgoing traffic is about 7 Mbps. Inbound traffic is generally not significant.
At first we tried to use a home router from Trendnet. However, while connecting three machines at the same time, it began to freeze. The situation was corrected by the transition to the Linksys e1200 router from Cisco.
Periodically, interference occurs in the wi-fi signal, and the ping of the cars either disappears or becomes unrealistically large. This happens every 2 days and lasts 5-10 minutes, then everything stabilizes. They could not reveal a clear pattern. It is still interesting that this could be included on Red October? :)
The biggest problem with the control was that the connection with the machine or the user periodically disappeared at the moment when the “forward / reverse” request was going on - in this case the machine was still suspended in forward movement, ran into an obstacle and burned the motor.
We thought of switching to a different 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 support for a frequency of 5 GHz and install the appropriate drivers on the on-board computer. Despite the fact that Linux is installed on the on-board computer, Phidgets does not have a standard mechanism for installing drivers. Therefore, the idea of switching to another frequency was abandoned.
At the beginning, the track was built, which is a figure of eight, with a smooth ascent and a steep descent.
On the descent, a magnet was installed (normal, for sharpening knives), which activated a magnetic sensor so that the lap time was recorded.
We planned to make a constant speed of cars, limiting it to such a value that the machine without problems climbed up the hill. But faced with the dependence of speed on the degree of charge of the battery. After 4 laps, the machine could no longer climb without increasing speed, which means 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 breaks. Speed adjustment was made in the control interface of the machine. The user has the opportunity to add speed using the AZ buttons to climb the hill.
When the project was launched, it turned out that the climb was not very interesting from the point of view of skiing - it is narrow, it is difficult to turn around if it crashed, and most users get stuck on it. The climb was removed and a circular track was made with a small step so that the user could not drive back.
While the lift was on the track, it was necessary to change the motors, because they burned due to the applied voltage, if the machine did not move. Fans from laptops helped to wait for the engine, but not always.
At some point, the motors in Moscow were over :-) I had to put a fuse that broke the contact between the controller and the motor with strong heat. Unfortunately, this led to the fact that the user in the middle of the race simply stopped and waited for the fuse to cool down and recover. Now there is no such problem, since the track was closed.
Fans used the most common of laptops:
In the first version of the assembly, the fans worked constantly, directly powered by batteries. But in this case, they quickly burned out and, moreover, planted a battery, so the fans were connected to a separate port on the controller so that it would turn on only when the machine was driving.
The case was made of solid foam covering at the top and on the sides a bumper made of metal plates. In the process, our ears and fins flew off, and the eggs fell out of the nest, but the hulls themselves remained intact:
Update 1 :
Maybe a habreffect, or maybe something else, but today 5 cars went with difficulty at the same time. We put 2 routers - it got better.
Update 2 - about the lap time accounting system.
Another of the interesting questions on the project was the choice of the lap time accounting system. There were several options.
Use a turnkey solution. For offline competitions of radio-controlled cars, many clubs use the professional system of time tracking My Laps. The system consists of a decoder, transponders that are installed on cars and a frame that fixes 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 practically not inferior to My Laps in technical specifications, but the price is several times cheaper.
I-Laps has its own competition software. However, it was not suitable for our purposes, since there was no way to upload data from the system to show the time of each lap and the best lap time at the end of the race.
More found DCD timeR- It looks very elegant solution, and the price was affordable. But manufacturers said that they could not make an API for us to upload data to our site. What a pity - we really liked this solution.
We were almost used to the idea that we would have to write the integration with I-Laps ourselves, but it turned out that an analog magnetic sensor can be connected to the on-board computer. As the magnetic field increases, it sends a signal to the on-board computer. As a source of magnetic field, we used a magnet to attach the tools to the wall. Gol asked a question about how we dealt with the fact that cars can move through the finish line in the opposite direction. So far we have decided with the help of a step. A more interesting solution is to put two magnetic sensors on each machine. Then by the sequence of their operation, you can determine in which direction the machine crossed the finish line.
There really are many people who want to ride - we had to open night hours for rides 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 tarantula race.
A post was written about our project , and this is a response to the 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 really had 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 for team work in extreme conditions.
Week 1
Architecture
The architecture at first glance is quite simple:
We considered several implementation options:
- Ready-made cars with control over the Internet . This option turned out to be gold, so it was abandoned immediately.
- They contacted www.jokerracer.com , but they said that it took them half a year to create the project and it would take as much to raise it again, and we had a little more than 3 weeks. By the way, they just had a ride, not a race. So, we can still carry the title “First in the World”.
- Aurdino, which is inserted into the usb port at one end, and clings to the console with the other and transmits a radio signal to the machine. However, under Arduino, development was required in a low-level language, and time was already 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 kinds of sensors.
The last option came up perfectly!
An on-board computer on Linux with 6 usb is installed on the machine, to which a microcontroller for a DC motor (a collector motor for movement) and a microcontroller for a servo drive (responsible for turning the front wheels) are connected.
Plus, a magnetic sensor is connected to the computer to fix the lap time, and via usb - a camera and a wi-fi adapter.
It all looks like this:
The only minus is phidgets - we needed 7 sets for 7 cars, and such a quantity in a complete set could be bought only in Canada.
Cars
From the very beginning we planned to use this machine: Monster Truck from HCP Racing . The machine is professional, and you can easily find parts for it.
Even before the start of the project, we consulted with the guys from Glavbot , who recommended machines with brushless motors, since the collector ones will 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, ended up being justified - the motors, of course, had to be changed, but not often, and not because of the heavy load.
The machine has a speed of 16 m / s, and the racing room is 15 m in length, so I had to figure out how to slow it down:
- If you put resistors, then the machine will not go on a depleted battery. Notice.
- They thought of making gearboxes, but we would have succeeded in manual assembly, which, under the planned load, would break daily. Notice.
- Looked at the fidget API and oh, a miracle! - it is possible to adjust the speed. On this and stopped.
Batteries
The battery that comes with the machine allows you to drive continuously for about 15 minutes. We had round-the-clock rides and wanted to make it so that more people could ride, so technical breaks had to be reduced to a minimum.
As a result, we picked up the option of batteries that can hold a charge of up to 4 hours, but we, just in case, change them every 2 hours.
It seems that they have decided on all the components, it remains to get everything, program and test.
UPD: As promised, we publish the remaining information about the project!
Week 2: Build
As I wrote earlier, fidgets had to be ordered from Canada directly from the fidget site. In total, there were about 30 microcircuits that would certainly hang at Russian customs for a couple of months, so they drove through Finland with double customs clearance. According to fidgets, a distributor will appear in Russia in July, but we did not have so much time.
When everything was on hand and we assembled the first prototype, the weight of the machine turned out to be 3 kg (excluding the case) - we had to strengthen the shock absorbers so that the machine did not ride on its belly.
In the end, it looked like this:
With the help of the program that came with Windows fidgets, we were able to test the fidgets, and immediately found several problems.
Camera
The Fidget camera transmitted an image in terrible quality, which constantly hung at a resolution of 320X240 and 10 frames per second.
At first there was an assumption that this was due to the fidgets themselves, so we decided to immediately use an IP camera so that the video would go directly. But this option made the machine heavier by another 500 grams, and this it 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 wonderful! True, it was not possible to use the h.264 codec, because it was not supported by fidgets. Had to stop at MJPEG.
We also tried the cheaper Logitech HD Webcam C525 option (now it’s on live broadcast from the track), but again the video began to freeze.
They also noticed that if there are wires near the camera, the picture quality deteriorates significantly, so they didn’t take the case off the camera, although from an aesthetic point of view it would be better if the camera is in the machine’s body.
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
Arrivals last 5 minutes, at the same time 5 cars can participate in arrivals. There are 2 spare cars that are activated if one of the 5 fails ping.
Between races 1 minute is allocated for switching control from one user to another.
Every 2 hours - a technical break for 30 minutes to replace the batteries and repair if something goes wrong.
Initially, we thought that the biggest problems would arise with video lags, or rather, with a delay in the signal associated with the user's remoteness from Moscow. Users who are further than two hundred kilometers from Moscow (where the races are physically going) will definitely experience problems with skiing. Moreover, they don’t even understand that there is a delay: the machine just becomes poorly controlled - the user pushed forward, and the machine went only half a second later. For the movement back and forth, this is not too big a problem, but for turns it was critical. But we considered it inappropriate to limit participation and acted as follows:
1) Everyone who lived within a radius of 200 kilometers could sign up for the near future.
2) Other cities could sign up starting at the end of the schedule
This option did not solve the problems with the delay, but, in any case, there were no bad reviews at the beginning.
Later, we expanded the recording ability in the near future to the entire central region.
Video
For high-quality skiing, it was very important that the delay was minimal, so the options for broadcasting video from the car through a media server were no longer needed.
There were options for the user to install the Java plug-in, but, firstly, he weighed a lot, and secondly, it is unlikely that anyone would install it for himself. They also wanted to use the Flash element, but it required the presence of the crossdomain.xml security file on the domain with the video stream, and it was not possible to configure mime types for xml files on the httpd fidget web server.
We settled on the following option:
For FF, Safari and Chrome - we use the tools of the browsers themselves, which can support MPEG stream. For other browsers, Java script with updating images. As a result, in the local network, the delay 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. the user could not go forward / backward. We fixed this problem by reconnecting. Therefore, during the countdown and the first few seconds after the machine stands still, and after 10 seconds it finally starts to drive.
Server
The server is a regular computer with the following parameters:
- Intel Core i3-2100 processor
- GIGABYTE GA-H61M-S2V-B3 motherboard
- DDR3 DIMM Hynix RAM - 4 GB The
processor load, if 5 machines are skating, is no more than 10 percent.
the Internet
We planned to use a dedicated channel for 100 mb. As a result, the 20 Mbps channel was enough for us. With the simultaneous participation of five cars in the race, the outgoing traffic is about 7 Mbps. Inbound traffic is generally not significant.
At first we tried to use a home router from Trendnet. However, while connecting three machines at the same time, it began to freeze. The situation was corrected by the transition to the Linksys e1200 router from Cisco.
Periodically, interference occurs in the wi-fi signal, and the ping of the cars either disappears or becomes unrealistically large. This happens every 2 days and lasts 5-10 minutes, then everything stabilizes. They could not reveal a clear pattern. It is still interesting that this could be included on Red October? :)
The biggest problem with the control was that the connection with the machine or the user periodically disappeared at the moment when the “forward / reverse” request was going on - in this case the machine was still suspended in forward movement, ran into an obstacle and burned the motor.
We thought of switching to a different 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 support for a frequency of 5 GHz and install the appropriate drivers on the on-board computer. Despite the fact that Linux is installed on the on-board computer, Phidgets does not have a standard mechanism for installing drivers. Therefore, the idea of switching to another frequency was abandoned.
Week 4: Testing and Launching
At the beginning, the track was built, which is a figure of eight, with a smooth ascent and a steep descent.
On the descent, a magnet was installed (normal, for sharpening knives), which activated a magnetic sensor so that the lap time was recorded.
Speed adjustment
We planned to make a constant speed of cars, limiting it to such a value that the machine without problems climbed up the hill. But faced with the dependence of speed on the degree of charge of the battery. After 4 laps, the machine could no longer climb without increasing speed, which means 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 breaks. Speed adjustment was made in the control interface of the machine. The user has the opportunity to add speed using the AZ buttons to climb the hill.
When the project was launched, it turned out that the climb was not very interesting from the point of view of skiing - it is narrow, it is difficult to turn around if it crashed, and most users get stuck on it. The climb was removed and a circular track was made with a small step so that the user could not drive back.
Motors
While the lift was on the track, it was necessary to change the motors, because they burned due to the applied voltage, if the machine did not move. Fans from laptops helped to wait for the engine, but not always.
At some point, the motors in Moscow were over :-) I had to put a fuse that broke the contact between the controller and the motor with strong heat. Unfortunately, this led to the fact that the user in the middle of the race simply stopped and waited for the fuse to cool down and recover. Now there is no such problem, since the track was closed.
Fans
Fans used the most common of laptops:
In the first version of the assembly, the fans worked constantly, directly powered by batteries. But in this case, they quickly burned out and, moreover, planted a battery, so the fans were connected to a separate port on the controller so that it would turn on only when the machine was driving.
Housing
The case was made of solid foam covering at the top and on the sides a bumper made of metal plates. In the process, our ears and fins flew off, and the eggs fell out of the nest, but the hulls themselves remained intact:
Update 1 :
Maybe a habreffect, or maybe something else, but today 5 cars went with difficulty at the same time. We put 2 routers - it got better.
Update 2 - about the lap time accounting system.
Another of the interesting questions on the project was the choice of the lap time accounting system. There were several options.
Use a turnkey solution. For offline competitions of radio-controlled cars, many clubs use the professional system of time tracking My Laps. The system consists of a decoder, transponders that are installed on cars and a frame that fixes 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 practically not inferior to My Laps in technical specifications, but the price is several times cheaper.
I-Laps has its own competition software. However, it was not suitable for our purposes, since there was no way to upload data from the system to show the time of each lap and the best lap time at the end of the race.
More found DCD timeR- It looks very elegant solution, and the price was affordable. But manufacturers said that they could not make an API for us to upload data to our site. What a pity - we really liked this solution.
We were almost used to the idea that we would have to write the integration with I-Laps ourselves, but it turned out that an analog magnetic sensor can be connected to the on-board computer. As the magnetic field increases, it sends a signal to the on-board computer. As a source of magnetic field, we used a magnet to attach the tools to the wall. Gol asked a question about how we dealt with the fact that cars can move through the finish line in the opposite direction. So far we have decided with the help of a step. A more interesting solution is to put two magnetic sensors on each machine. Then by the sequence of their operation, you can determine in which direction the machine crossed the finish line.
There really are many people who want to ride - we had to open night hours for rides 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!