As a preamble, I’ll say that since such an article was already there, I was not going to write about the camera in the first place. The camera was made, just for the sake of interest, training skills and working out the technology of remote control of physical objects. A little later, I used this system as a vivid example accompanying the review on another resource (and in fact, as a cheat to pull up the votes). It was a real beta test, which revealed a bunch of flaws. For this many thanks to all those who are not indifferent, who helped someone with advice, and who helped with a piece of code.
At the same time, the visitors who played with the camera, in addition to not having passed the hour so that they didn’t remember Habr, also began to be actively interested in the device of the whole thing, technical details, software implementation and of course cost.
This is what made me an article. And so as not to repeat, I decided to focus on the cost, because the author of the previous topic on this topic, as I recall, the final cost resulted in something in the region of 5000r. ')
About the cost of my crafts: read below.
So, "how to call a ship, so it will float," once wrote the headline about cheapness - I will match the prose, so that the details - then, and first about the cost.
Let's go on prices *
* All prices are given with discounts. About discounts - separately, later.
Required kit :
Arduino Uno (or nano) - $ 15.29
Servo (steering) SG90 2x2.37 $ = 4.74 $
Webcam 3.01 $
Total : $ 23.04 (about 750r , at the moment)
Additional set (laziness + buns):
The screen from Nokia 5110 is 250r (complete with Nokia itself and the power supply unit, bought a couple of years ago, we will assume that it is for this purpose that one can actually be found twice cheaper, or even for free)
MegaShield v4 to Arduino - $ 5.86
Wiring connectors - $ 2.86 (40 pieces for this price, actually used 7)
Ultrabright superb blue light for the backlight of the screen - 5p / pc (preferably 4 pcs., I have done wrong)
Total : approximately 550r
Total: 1300r
About implementation
Everything was done from scratch. I didn’t repeat what I already had, firstly because of training considerations, and secondly I didn’t have an Ethernet module at that time, I decided that it was all too difficult (MySQL was tied there) and this solution is for me definitely not suitable.
About tasks Tasks I have identified the following:
See picture / video
Have the ability to control the camera
To be able to control the size and quality of the video or image, and not “already on the client side”, but “still on the server side, at the client’s command”. Such a need arose due to the fact that “large and wide intyrnet” is not available to me everywhere.
Provide an acceptable "realtime"
Have a reserve for the future - load control 220V, etc. Actually for the sake of it all was started, because ready-made solutions or terribly expensive, or do not provide such an opportunity.
About problems During the implementation of the questions have such a plan:
The video either loads the processor in case of multiple users, or it gives a delay of 5-10, i.e. does not provide “realtime”, which is why it is impossible to immediately determine the adequacy and overall performance of the management
Using the broadcast service, although it greatly relieves the server in the case of a large online, does not provide the necessary reliability, and, again, gives a delay
A special server for broadcasting a video stream requires certain skills that I do not yet have
Using the display by changing images does not provide high fps, and also constantly refers to the hard disk, which, with a large number of users, can cause picture lags not because of the processor load, but because of the disk access
About solutions
It was decided to use as a display - pictures
To exclude a hard drive from the process of issuing pictures, RamDisk is installed, on which the webcam image “lays down” twice per second
For issuing pictures decided to use php and gdlib
Updating the image is initiated by the client via javascript and ajax, and occurs without updating the page itself.
Pretty lyrics!
How does it look
Everything looks more than modest
It works like this:
Arduin, if anyone has not seen
Megasheed with wiring
"Sandwich" in profile
"Sandwich" full face
Lcd
She's the back view (pins and conder)
In the collection
Assembly 2
Collective farm - wiring system and strings (camera mount)
Where do without him
How does the hardware
The webcam is connected via USB to the computer. Arduino is also connected to the computer via USB. All external devices, due to the exceptionally low current consumption, are connected directly to the Arduino, it has been working around the clock for a month and a half, with 10 users online at the moment of the lowest load.
How software works
On the client side, a clean web interface, without any plug-ins and lotions. Only html, css, and javascript (+ ajax).
Server side
The server itself is Apache
Script Handler - php
Accepting images from the camera - any of the easiest available, free or self-made program for saving images from a webcam
Picture storage - RamDisk, utility for creating a disk partition in RAM (Russian version of RAMDisk "Enterprise" is free for localized systems)
In order not to register direct local paths in php, a folder with a picture is mounted in the www folder using juction (Mark Russinovich's free utility)
The transfer of control from the Internet to Arduino is implemented using a proxy program as follows: the php script creates a UDP socket and sends a datagram to a specific port, then the proxy program listens to this port and receives incoming messages and sends them to the Arduino COM port (you can even without processing). The choice of UDP is called solely to simplify the system; UDP does not require any acknowledgments and checks about the delivery-sending, either from the client side or from the server side.
On the side of the Arduino
Itself (why "itself"? Because "payment") Arduino
Sketch inside it - standard examples from the standard set of arduino-0022 servo and serial + library found on the Internet for the display, modified to an acceptable form (in terms of Cyrillic and Latin at the same time)
At the moment, the megashild is a plus, purely because of the convenience and cultural appearance - in this embodiment I did not solder any wiring (except for the board to the display)
The system withstood all the invasions and raids, as well as more than 120 users online. There were cases of management failure that occurred due to my flaws in the proxy program, in particular due to insufficient error handling, while the software part of Apache and Arduino was held up with dignity.
Be attentive to the little things
I want to note the problems with the software part that happened because of my own carelessness / lack of information / lack of observation:
The first thing I was seriously tormented with was that the Arduino receives the first byte from the line sent to its virtual COM port separately and everything else separately. What sophistries I just did not try - and with arrays and with a bunch of checks ... Though you kill yourself. Solution to the problem? It came unexpectedly and suddenly, at the moment when I did not think about it: Sleep 2 after reading each byte. EVERYTHING!
The second problem - a serious load on the server, it would seem, out of nothing, arose because the update of the picture was done on a timer, without waiting for the actual fact of loading the picture (or download error). This way a bunch of "extra" requests were sent.
Third: FireFox turned out to be the most correct and capricious browser, and made me learn to write valid code. For example, the OnClick event on the Option element should not work. And it works, everywhere except for firestone.
The fourth, completely implicit and rarely pop up: periodically the picture “broke”. As it turned out, this happened at the time when the file was busy writing. Those. check file_exists () passed, and the file remained locked. Checking is_writable () didn't help either. I had to organize a cycle by the presence of an error and inside it to work out the reading of the file “to the bitter end”.
Remaining flaws
There are some.
Firstly, these are the “left” symbols described in the letters, sometimes appearing at the end of the message on the screen. In fact, these are management teams. The ears of this bug grow from the fact that if you actively spam or press buttons, the com-port buffer does not have time to read Arduina completely and subsequent messages fall to the end of the buffer. The solution is, but not yet made.
Secondly, this is a periodic drop in a UDP socket in a proxy program with large online. What is the reason - I do not know. It does not appear immediately. Dies and does not "otkiss". Helps close the socket and bind in a new way. Perhaps the curve is guilty species windsock.ocx. To rewrite this business on API in a BASIC, somehow laziness. So far, one of the “clumsy” solutions is seeing the reset and socket rebind on the timer, every, say, half an hour.
About discounts
It is well known that in China - cheaper. The main thing is to know the places where it is cheaper, and how to get an additional discount. It makes no sense to write here - too much text with pictures, besides, known to the majority. Therefore, in order not to provoke ardent opponents of the fight against spam and other “referrals”, I’ll note the necessary minimum - this is a 15% discount on BiC, consisting of a one-time coupon by 10% and a discount for the first purchase of 5% when entering a recommender + hint, how to use this system repeatedly. All interested, can familiarize with the full information under the link on a page with, actually, the camera.
Links
Camera, working copy , for those who have not yet seen and not played enough The topic in which the link to the camera was leaked to Habr ahead of time Ramdisk juction Sources (simplified, in order to avoid) client part, server (php) and web-arduino-proxy program (VB 6.0)
Apache, php, or some combination builds, etc. - to your taste.