We build a robotank with Wifi control, a camera, a gun, blackjack, etc.
Hello. I still had an irresistible desire to share my achievement with the world. An achievement is a tank that steers through WiFi from a gamepad, transmits real-time video to a remote control, transmits sound from the remote control and to the remote control, and also has a gun with a laser sight from which you can shoot someone.
This post will be the first test, in order to understand whether it is interesting to anyone except me. In it I will describe the general structure, the technologies and devices used.
UPD: added video.
To start, a small video to attract attention. The sound comes from the column of the tank.
How it all started
Once upon a time I had a dream to make a robot on a tracked chassis, which could be used to steer remotely. The main problem was the lack of a direct tracked chassis. In the end, I already decided to buy a radio-controlled tank for disassembly, but I was lucky, in the store among the trash there was a Snow Leopard (Pershing) tank - USA M26 with burned-out electronics, but a fully functional mechanical part. It was exactly what was needed.
In pursuit of the chassis, two voltage regulators for collector motors, a tripod for a camera with two servos, a webcam with hardware support mjpeg and an external WiFi card TP-LINK TL-WN7200ND were purchased. A little later, a portable speaker, a Creative SoundBlaster Play USB speaker and a simple microphone, as well as a couple of USB hubs were added to the list of devices to connect it to the control module, which became the Raspberry Pi. The tower from the tank was dismantled, it was very inconvenient to steer it, since all the standard mechanics were built on conventional engines without feedback.
Immediately make a reservation that the pictures were taken when the tank was almost ready, and not in the manufacturing process.
Power and Wiring
I stuffed the largest Li-Po battery into the battery compartment, which got into it. She turned out to be a 3300 mAh two-can battery in a solid case, which is usually used in model cars. I was too lazy to solder, so the standard breadboard with a pitch of 2.54 was used for the entire switching. Later, a second appeared on the top cover and a train that connected them. For each of the two engines I had my own voltage regulator, which in the form of a bonus gives out a stabilized power supply of about 5.6 volts. Raspberry and a WiFi card were powered from one controller, the power from the second went to servos and a USB hub with peripherals.
Gotta make it move
It was necessary to somehow get it. Raspberry was not chosen by chance. Firstly, it allows you to put a normal full-fledged linux, and secondly, it has a bunch of GPIO legs, which can also generate a pulse signal for servo drives and stroke controllers. Such a signal can be generated using the ServoBlaster utility . After starting it, it creates a file / dev / servoblaster, into which you can write something like 0 = 150, where 0 is the channel number, and 150 is the pulse length in tens of microseconds, i.e. 150 is 1.5 milliseconds (most servos have a range of values 700-2300 ms).
So, we connect the regulators to 7 and 11 GPIO pins and run the servoblaster command:
# servod --min=70 --max=230 --p1pins=7,11
Now, if you write the lines 0 = 230 and 1 = 230 in / dev / servoblaster, then the tank will rush forward.
Connect the camera
Riding back and forth was cool, but I wanted to do it at least in the next room, and ideally through the Internet in general, so I had to set up a video in real time. On the Internet there was a simple project tinycamd. the project is a service that is controlled by http, can take screenshots and change camera settings. Not a lot, but I didn’t find anything better, so I had to recall C and add what the author didn’t implement, namely, broadcasting the MJPEG stream via HTTP (by the way, how to share the modified source with the world?). It is crucial that JPEG comes from the camera itself, the Raspberry processor is not enough for this. As a result, I connected to the tank via ssh, opened the video stream through the browser, rolled around the house and was happy until the channel sank. It was very funny at first to look at the frozen frame, and then to get everything that was stuck in accelerated mode. Streaming realtime video over TCP is evil.
Upgrades, improvements, etc.
Next, there was a long process of writing the server and client parts in Python using the pygame library to receive events from the gamepad, finishing tinycamd so that it would send the video stream over UDP and installing the camera on a tripod from servos so that you could look around. After which the tank went on its first trip around the office beyond the line of sight. And at that moment it came to understand that I would like not only to watch the video, but also to have a two-way audio channel, for example, to ask colleagues to open the door or call the elevator.
To play the sound, a cheap pocket USB speaker was used, which was bought at a supermarket for a stock. She was connected with a simple microphone via a USB sound system. The pyalsaaudio library came in handy for working with sound . After finishing the server and the client, it became possible to speak and listen in the process of dissecting the tank.
The next feature was the headlight. At some point, it became clear that the sensitivity of the camera can easily be missed and there is a chance to drop into the dark and not leave. The first idea was infrared lighting. A line of infrared LEDs was assembled, but, as practice has shown, there is no sense in them. Shine very poorly and a little. And finished infrared spotlights require 12v power (and I only have 2 banks, that is, 8v maximum), they consume a lot of current, bulky and expensive. As a result, it was decided to go into the visible range, two powerful white SMD LEDs and lenses were bought. To power the headlights, colleagues at work created a driver with current regulation, which was turned on through a field-effect transistor by supplying a unit to the GPIO leg of Raspberry. From now on, dark rooms are no longer an obstacle.
Battery, more precisely, its charge level
At all stages, it remained unclear how much more you can ride without killing the battery (Li-Po cannot be discharged lower than 3.3v per can). I did not find a way to measure the voltage using the GPIO of the Raspberry legs, so I put the Arduino Nano as a meter, to which I immediately connected an LCD screen with I2C adapter for the future. The battery is connected via a half divider to the Arduino analog leg, after which it remains only to calibrate the readings. Arduino traditionally communicates with the main module through the COM port, which Raspberry also has GPIO feet.
What a tank without a gun
One of the last details of the tank was the gun. The gun was bought there, in the store of radio-controlled models in the form of spare parts. True, it was intended for another model of the tank, but its essence did not change from this. The gun is pneumatic, has an engine cocking the piston spring, and a contact that closes when fired. I have so far refused to turn the gun horizontally so as not to tear down the entire body kit, which is attached to the top cover, and for the vertical one I used a powerful servo. To make it easier to steer, I made the gun turn in synchronization with the camera rotation. That is, where we look (vertically), there we shoot. To aim at the gun barrel, a laser LED from a pointer was attached. So that once again not to waste the battery and not to shine with a laser where it is not necessary, it was necessary to make the gun switched off. The shot process is also not entirely simple. It is necessary to turn on the motor power and wait for the contact to close, then turn off the motor. As a result, control of the shot and power of the servo and the laser was hung on an arduino, and the signal for the servo was generated by Raspberry. For the gun engine, it was also necessary to conduct a separate power wire and turn it on gradually using PWM, since otherwise the power supply noise arrives and the Arduino goes into reboot. For the supply of shells, that is, balls, a TicTac dragee box with a hole in the bottom was used. since otherwise, a power disturbance arrives and the Arduino goes into reboot. For the supply of shells, that is, balls, a TicTac dragee box with a hole in the bottom was used. since otherwise, a power disturbance arrives and the Arduino goes into reboot. For the supply of shells, that is, balls, a TicTac dragee box with a hole in the bottom was used.
Probably enough for the first time. If you like the article, I will slowly write details in the following posts. And a few photos in the end, as well as a fresh video. True, the quality was not very good, so I apologize to the aesthetes in advance. github link