Android + Arduino + 4 wheels

I didn’t think it would twist me like that, but there was a rather sharp attack of robotics. Well, like any self-respecting victim, I will try to infect as many people as possible.

How the insanity developed, I decided to describe in the article. It turned out long, but maybe someone will be interested. I think the article is aimed at those who have not yet practiced in robotics.

Here is the result. The video is vintage, it was shot by the owner of the iPhone, and they are, after all, entertainers, you know. I left the sound offscreen deliberately, so that everything buzzed as if for real.


The following couple of paragraphs is exclusively lyrical, and can be skipped by a stern technical reader.

It all started with lunch at the office. There were several of us, and one employee asked if anyone had a hobby. We thought, thought, and suddenly realized that no one had a hobby. Of course, there is a craving for programming, there are sports, families and friends, but so that sticking houses out of matches, cutting boats or collecting stamps - no, this did not happen. I don’t know whether it was from greed or some other feeling, but the thought of the absence of my favorite thing stuck in my head. Rise, the way to work, work, the way home, a maximum of an hour with a family (everyone has business!), A dream ... At night, apparently, some kind of reset occurs, and the next morning a new iteration begins. That employee seemed to have stuck a posting with feedback in my head. And not just me. The victims of that dinner, as it soon became clear, were two. The topic of interest to both of us was robotics. As a child, I was a radio amateur, I graduated from the institute with a degree in robots, robotic systems and complexes, and now I am a software developer. Such a hobby is just made for me. Where have I been before?

In the office, we called for the creation of robots and RoboBatta, but there were no more volunteers. There were sympathizers, but there were two participants left. We decided that everyone will make his own robot and on the appointed date (the deadline is about two months), we will clash in battle. The sense of beauty and the rejection of violence forced us to abandon the sledgehammers, grinders and other instruments of savages in favor of the IR gun and IR receiver. Although over time the idea of ​​RoboBatta ceased to touch me, because now I had a robot (my charm, of course) and a lot of plans for its development, I must admit, the fact of holding RoboBattle really spurred me on time. It was a great motivator, he forced to seek time and rush.


Well, now to the point. I would like to describe how the manufacture of my robot progressed, what problems I encountered, how I solved them and the most common question for me: how much money it all cost me.

Initially, I assumed that I would use the Arduino platform for the control system (in the future brain) of the robot. My “opponent” was moving along the same path. The topic was new to us, so rummaging through the Internet, we found that the Arduino world has everything: Ethernet Shield, Bluetooth Shield, Motor Shield, gyroscopes, accelerometers, and a whole bunch of other sensors and interface cards that can be useful to geeks like us. But the more I looked for useful nodes for my robot, the more I became convinced that I already have it. In a smartphone. I have HTC Sensation with Android 2.3.4 on board. And there already is: Bluetooth, WiFi (even a WiFi router), a camera, a flashlight, a huge display, sound, a microphone, microUSB, memory, a gyroscope, a compass. And here I decided that the brain of my robot will move to a smartphone. And Arduino will perform the functions of the spinal cord.

This architectural solution has a big minus - it seems that at the end of the article I will have to include the cost of my smartphone in the cost of the robot, but I already had a smartphone, and I could not go past the advantages that he gave me. In addition, I was interested in the topic of programming for Android OS at work, and such a solution came in handy. My robot is not yet ready for autonomous actions, this is the topic of further development of the project, so another layer was born in robot control - a simple client program that generates control commands and transmits them via a TCP socket to an Android application. Such a program can be written for any platform, as long as it is possible to establish a connection through a TCP socket. Now I have written a simple .NET application using XNA. To control the robot, I use the gamepad from the XBOX 360.


I’ll sketch about someone busy with something.

Arduino sketch features:
  1. Establish a connection with an Android application.
  2. Reception and execution of commands received from an Android application.
  3. Reception of signals from the sensors of the robot and the transmission of these signals to the Android application.

Android app features:
  1. Establishing a connection to an Arduino sketch.
  2. Establishing a connection with a .NET application.
  3. Receiving commands from a .NET application.
  4. The execution of part of the accepted commands that are not intended for the Arduino level. For example, playing sounds, turning on the headlight (camera flash), changing faces on the smartphone display, etc.
  5. Command transfer to Arduino.
  6. Reception of signals of sensors from Arduino.
  7. Responding to sensor signals. For example, playing a sound when a shot from an IR gun hits my robot.
  8. Transmission of sensor signals to a .NET application.

Features of the .NET application:
  1. Establish a connection with an Android application.
  2. Input Processing (XBOX 360 Gamepad).
  3. Team building.
  4. Transferring commands to an Android application.
  5. Receiving sensor signals from an Android application.
  6. Displays the current state of the robot.

I didn’t have big problems with the software implementation of functions, except for me that programming in Java (the level of an Android application) was new, but these are my personal difficulties. Sketches on Arduino did not cause any difficulties - a very simple language (Wiring), a very tolerable development environment. What I had to tinker with was controlling the robot. I wrote the application in C #, and it is still very simple and simple, but I had to modify the robot control algorithms twice - I could not immediately achieve good robot control. But I’m getting ahead of myself, I’ll write about it below.

My plan

I considered the deadlines to be rather tight or I was so slow, so I made myself the following plan:
  1. Mastering the Arduino controller.
  2. Assembly of the cart, installation of electronics on it.
  3. Arduino programming, stand-alone command execution.
  4. Cart control via USB PC.
  5. Connect Arduino to an Android smartphone.
  6. Transferring commands from a PC to a smartphone.
  7. Gun and hit sensors.
  8. Final assembly.
  9. Hairstyle, documentation.

Mastering the Arduino Controller

I needed the first item of the plan to “warm up”. We had to understand what Arduino was, install a development environment, get comfortable with a new language, write a couple of test sketches. For experiments, I purchased a ready-made set of "Matryoshka X" . Please do not take the link as commercial advertising, but Amperka turned out to be a very convenient resource. There is a lot of training information, video tutorials, a forum. Having played enough with the LEDs, it's time to move on.

Assembly of the cart, installation of electronics on it

What I wanted from the mobile platform of the robot: that it was small enough for convenient maneuvering in the apartment, that it was playful and that the carpets, sills and wires from the extension cords it encountered were not an impenetrable obstacle for it. Well, and, of course, there should be enough space for Arduino electronics and a smartphone. Underneath all this, such a four-wheeled platform came up wonderfully .

In addition to four motors with gearboxes, a platform set of electricians includes a toggle switch and an external power connector. The connector is compatible with the Arduino Uno power connector and was very useful later in testing.

Here is my first photo of the cart:
Photo trolley

Five AA batteries are installed here in the bundled holder. As it turned out later, I began to miss the batteries for four engines, two servos and electronics. And then all the charm of my cart was revealed. I got hold of 12-volt Ni-MH battery packs. So it turned out that instead of a standard 5 AA holder, two battery assemblies of ten AA cans in each can fit in the trolley. These are 20 cans of AA! I turned on the assemblies in parallel, getting 12 V and 2200 mAh. True, now I had to spend money on a charger for this mini-monster. And again the external power connector came in handy. I now use it to charge the robot battery.

Photo of a trolley with two battery assemblies

An additional pleasant bonus of the platform is the regular place for mounting the servo drive.

The only drawback of the trolley that I encountered was the loose mounting of the wheels on the gear shafts. When assembling, the wheel mount seemed reliable, but during the first tests of the robot on the carpet, the wheels began to fall off. The design of the wheel did not imply screwing it on - just a tight fit, I did not want to glue the wheels, so I had to drill them and fix them to the gearbox shaft with ordinary screws. Fortunately, there are holes in the shafts of the gearboxes.

Wheel refinement

Arduino programming, standalone command execution

So, in the next step I wanted to get movement from the platform. For this, I purchased “Motor Shield v3” from “”. It allows you to control four DC motors or two stepper motors, and it also has connectors for two servos. In addition, motor shield supports SPI. It seemed to me then a wonderful option, even redundant - I needed to control two servos and only two DC motors (for the left and right side, the front and rear motors are connected in parallel). Moreover, I managed to control the motors and servos, and I even closed this item of my plan.

Problems with “Motor Shield v3” started later. When I purchased a USB Host Shield from DFRobot to pair with a smartphone, I began to have conflicts over the Arduno digital outputs used. I tried the usual control mode for this motor shield, and SPI - the best I achieved was the control of motors and servos, but I had no more free outputs. But still it was necessary to control the infrared gun. As I understand it, the problem was purely software. The libraries that I used are taken there, on They are dated December 2009. The site indicates that the modification of the library for working with SPI has not been tested on stepper motors, but in the near future, they promise to do it. And God would be with them, with these stepper motors, only the date of the library is 2009. It looks like the project is abandoned. I honestly looked at the source, sighed, and I realized that I don’t want to delve into it at all. Another time somewhere in the future somehow another time sometime later. Of course, I could get by with just one servo drive, but I really did not want to limit myself.

In theory, to control two engines I need four legs of the controller, two more I need for servos, one for firing from an IR gun and four for controlling USB Host Shield. Total eleven legs. I did not use the zero and first legs - these are the TX and RX of the Arduino Uno serial port. Generally speaking, they can be used, but this enterprise is risky, as I understand it - you must be prepared to reprogram the controller. So I left these legs alone. It turns out that I went over all thirteen legs of the Arduino Uno. That's just to force “Motor Shield v3” to use two legs per engine or four legs SPI-bus I failed.

I had to purchase another motor shield. Manufacturer DFRobot. The name is not particularly original: “2A Motor Shield For Arduino”. But it is simple and for control it needs only four Arduino digital outputs (two of them must be with PWM). Even a finished library is not needed. True, there are no connectors for servos on it, but these are trifles.

Cart control via USB PC

At this step, I formulated the robot command system and, you can say, I got the almost final version of the Arduino sketch. When connected via a USB port, the Arduino connects like a regular serial port. Commands to it can be transmitted by any terminal client. At first, I used the Serial Monitor, which is part of the Arduino IDE. I got tired of injecting teams quickly, and for tests I wrote a WinForm application with three sliders (for controlling engines and a horizontal servo drive) that allowed me to check my sketches and conduct the first experiments with robot control.

The command system is simple: all commands are five-character, with the first two characters representing the command itself, and the remaining three characters - digital, determine the value of the parameter. For example:
LF190 - the left engine forward (left forward) with a speed of 190 (speed is set from 000 to 255);
HH045 - set the horizontal angle of rotation of the head (head horizontal) to 45 degrees.

Connect Arduino to Android Smartphone

Then I had to learn and torment. At first, I thought that connecting an Arduino to Android would be as simple as connecting to Windows. In the Android application I will receive the serial port and I will write commands for the Arduino to it. So easily it did not work. It turns out that the COM port in the Android device is hidden somewhere far away. I admit that I did not understand something - I did not have time for research. Studying the issue, I found the project “android-serialport-api” . There's even a section on serial port activation on HTC phones. And three models are considered: Dream, Magic and Hero. Mine is not here. What else stopped me was that for activation the first thing to do was “Root your phone”. I have not rutted my phone, and so far I'm not really going to.

Therefore, I went along another found by me, and already pretty well-trodden path by all: Android Open Accessory Development Kit . Everything is described in sufficient detail in DevGuide, the only thing I didn’t like was some crazy DemoKit example given there. An example includes everything that is possible at once: connection, definition of connection, data transfer, reception, control of several LEDs, motors, work with a joystick, and quite sophisticated (at least for me) activity in an Android app. Having not mastered the source code of the example from the first call, I found a simplified version of it and everything immediately fell into place.

Having bought and installed USB Host Shield from DFRobot, I managed to transfer commands from my Android application to an Arduino sketch, but then I was immediately covered by two problems. One described above is some kind of conflict with my first motor shield (I'm sure the problem is in the motor shield control library from But the second I still could not solve. It will be great if someone tells me what to do. USB Host Shield is the host in the USB connection (sorry for this conclusion). This means that the power comes from the USB Host Shield to the smartphone. And my overgrown smartphone starts to overeat the cart that is so often malnourished by a battery like Crohn or five AA batteries. So the idea was born to put the batteries. 12 V and 2200 mAh are a great help in powering motors, servos and a smartphone, but I really want to exclude the smartphone from this food chain. Nothing could be found in the phone options. It seems that there will be no software solution without rooting the phone again. Then I had only a hardware solution to the problem. The USB cable contains four lines: power, ground, transmission line and reception line. The first idea - cutting food - failed. After that, the smartphone stops detecting connections to the USB host. Digging again on the Internet, I found a person who solved this problem. After that, the smartphone stops detecting connections to the USB host. Digging again on the Internet, I found a person who solved this problem. After that, the smartphone stops detecting connections to the USB host. Digging again on the Internet, I found a person who solved this problem.Simon Monk succeeded in disconnecting the charging of its Nexus One when connected to a USB Host Shield in a similar bundle with Arduino. To do this, he installed a 1 kΩ resistor in the context of the power line of the USB cable. He received this resistance empirically when the definition of connection (accessory detection) was already working, and the phone’s charge had not yet begun.

I put a kilo-ohm resistor in the section of the line and tried to connect a smartphone. The connection was detected, and immediately began charging the battery of the smartphone. Then I set the variable resistor to 10 kOhm. The effect is the same. Now I added another 10 kΩ sequentially - accessory detection did not happen. And the charging did not start. There was a moment of triumph, I began to slowly lower the resistance with a variable resistor, and on 16 kilo-ohms the smartphone detected Arduino. At the same time, charging began on the smartphone. Crash. I still conjured a bit, unsubscribed to Simon in a comment on his post, so there the last comment hangs from Dmitry and so far has given up. In the end, with 2200 mAh we somehow winter.

What Simon pays attention to, and I completely join him, is that we do all the experiments with the cable and our own telephone at our own risk. I should have said that.

Unscheduled surprise - Arduino power interference

So, I got the following configuration: a smartphone with my test application is connected to three floors of the boards - USB Host Shield, Motor Shield and Arduino Uno. My test application on a smartphone sends commands to the cart to rotate the engines in different modes (change of speed, direction) and rotate the servo to different angles. And then suddenly collapse again. Sometimes the commands are executed, and sometimes the trolley behaves like crazy - it turns the wheels in different directions, then it shakes the servo-drive, and these seizures have nothing to do with the transmitted commands.

It was strange that I had not encountered this problem before. Studying it, I realized: in the new configuration, the power is supplied from one source - both the power of the engines and the power of the electronics. And before, I always powered Arduino with a separate source: either a Kron battery or a USB cable from a PC. The experiment with an additional power source confirmed my theory. Apparently, according to the Arduino power supply, there are pickups from running engines. I looked what they write about it. People, I understand, have such a problem in the world of quadrocopter guides, it is a world of powerful electric motors, and, perhaps, I was drawn into it due to the inclusion of my engines in two parallel pairs. The current doubled, the interference intensified, and my cart pulled toward the quadrocopters.

I opened the topicon a forum in Amperka, but people with similar problems did not encounter there. I really did not want to use two power sources - this is somehow strange. I understood that it was enough for me to put a filter on the input for Arduino power, but my technical abilities weren’t enough for this, and the time for further search has long been over. The only thing I managed to find from solutions to such problems is here. I decided to take a chance and bought a TEN 8-1221 DC-DC converter. The converter converts the input 12V into + 5V and -5V with a common contact of 0.8A each. I made -5V common and got + 5V and + 10V. 10V went to power the Arduino and through its stabilizer to the USB Host and Motor Shield chips. And I used 5V to power the servos to unload the Arduino stabilizer a bit. As before, I applied the same 12V to the motor shield terminals for external power supply to the motors. But now I was hoping for a filter built into the DC-DC converter. I was lucky, and my hopes came true. Now the cart diligently executed all the commands of the test Android application.

Transferring commands from PC to smartphone

Here, for my happiness, everything went smoothly. The idea was this: for the interaction of a PC and a smartphone, either an external WiFi router is needed, or HTC Sensation itself can act as a router. This is convenient, then you can control the robot even in the forest. I intentionally chose WiFi rather than Bluetooth or, for example, XBee because of my far-reaching plans. For communication, the Android application opens the server socket, then the .NET application establishes a connection and sends commands to the robot. Everything was simple.

A useful option for my phone was that it can be switched to “airplane” mode, and all communications will be disabled, and then turn on the WiFi router. I don’t know if this is a developers mistake or a pledged utility, but I like it. I can turn off GSM, 3G, Bluetooth and still use WiFi. I didn’t even make an Android service, but managed the Android application.

Gun and hit sensors

Here, too, everything turned out without a hitch. The role of the gun is performed by the TSAL4400 IR LED, and to fix the hit, I used the TSOP31236 photodetector. IR LED works at 100mA, and peak 200mA. The maximum allowable current on the Arduino digital output is 40 mA. Therefore, I recommend putting a transistor to control the IR LED. The binding of the photodetector is indicated in its datasheet .

I send the IR signal (shot) and receive the IR signal (hit), of course, in an Arduino sketch. For this I use the IRremote library .

To narrow the infrared beam, I placed the LED in a metal tube (I used part of the broken telescopic antenna section).

Photo guns

Final assembly

At this point, all the basic and hardware and software problems were resolved, but I managed to find myself another rake. It so happened that before that I had only one servo drive (DF05BB with a rotation angle of 180 degrees). The head of my robot should turn in a horizontal and vertical plane, so I took care of buying a second servo. I did not find exactly the same, but I found a more powerful one with a rotation angle of 360 degrees. I thought a great option for the horizontal plane. When I bought it, it turned out that I did not pay attention to two words in the description: “continius rotaiting”. This means that the servos do not spin 360 degrees, but simply spin. You can control the speed and direction of rotation, but you cannot control the angle of rotation. Before, I did not know about the existence of such servos. I had to look for another,

The next step is to install a vertical servo and mount for the phone. As I already wrote, for mounting the horizontal drive on the trolley there is already a regular installation place, and for the vertical I purchased a special bracket .

Servo Mount

Servo Mount

The holder for HTC Sensation: HTC Z710e (Z710ECAR01) was ideal for installing my phone . I bought it specifically for the robot. The screw caps for fastening to the bracket of the vertical servo turned out to be recessed and do nothing to harm the back wall of the phone case.

Phone holder mount

There was not much free space under the phone holder, and not every microUSB connector fit there. The proprietary USB cable connector from HTC fit, and the cable itself is pretty soft. I had to shorten it. On the other end, I put a USB-A (male) connector for connecting to a USB Host Shield.

Now about the IR gun and IR receiver. The mount for the gun barrel is made from improvised means: for this role, the part from the semi-toy clamp perfectly fit. I fixed it on the left of the phone holder so that the gun does not interfere with the tilts of the robot head and the use of the “hardware” buttons of the smartphone if they are suddenly needed (the buttons are on the right). As I already wrote, the barrel is made of a telescopic antenna, and its sections are fixed by a heat shrink tube. I didn’t get too sophisticated with the IR receiver - in this form I need it only for RoboBattles, and then it can be removed (in general, the gun too). Therefore, I just stuck the receiver with double-sided tape on the back of the robot.

Well, a few words about electronics. For mounting a DC-DC converter, I bought a proto shield prototype board., at the same time it was soldered to the IR receiver harness for cutting off false positives. On it I also installed connectors for servos and a power connector for all my electronics. The 10-volt output of the DC-DC converter is output directly to the Vcc and Gnd pins. Those. I do not use the Arduino Uno power connector. The 5-volt output of the DC-DC converter is output to the servo connectors. It turned out four "floors" of boards. The fourth floor didn’t want to fit in the cart, I had to put small spacers to raise the top panel of the platform.


To enter the light the robot needed a face and, of course, a tail. I'm the same computer artist, so I have only Paint at hand. Somehow he painted four faces: satisfied, dissatisfied, angry and killed to death. Then he tweaked the management program to change the mood. By the way, having tried both of them, I can say with confidence that programming is much easier. The tail spun from a copper wire, stuffed into a heat shrink tube and sandwiched between the back and the USB connector. Added sounds of a shot and a hit. We need more sounds for every mood.

Tail with all that

In principle, this could already be done. But one more thing haunted me - robot control. The implementation seems to be workable, but something was wrong. According to tradition, the left stick of the gamepad controls the movement. Right - overview, i.e. rotation of the head. Management flaws were there and there.

First, for those who are not in the know, a few words about the joysticks. The gamepad joysticks at least under XNA give x and y coordinates ranging from -1 to +1. The point (0, 0) corresponds to the central position of the joystick. Moreover, the extreme positions of the joystick correspond to a circle with a radius of 1.

Now about traffic control. The trolley has no steering wheels, so the turn occurs like a tracked vehicle. The idea is best explained by example. Suppose we want to make a smooth right turn while moving forward. Then the left wheels should continue to rotate without changing the speed, and the right wheels should slow down. The joystick will be in a forward and right position and will return the x and y coordinates in the range from 0 to +1. Consider the state of the joystick as a vector with a beginning at the point (0, 0) and an end at (x, y). The idea is to represent the vector module as the speed of the left engines, and the product of the module by the sine of the angle that it forms with the x axis, as the speed of the right cart engines. The x axis is perpendicular to the direction of travel. It turns out that at angles close to 0 degrees (the joystick in the right position),

By the time of “combing” this idea was already implemented. Moreover, a reversal mode was already added, when when the left trigger of the gamepad was clamped and the vector angles were small, a different algorithm worked with the X axis - the motors on different sides of the cart rotated in different directions with the same speeds equal to the vector module.

But one thing was not enough for ease of management. The values ​​of the speeds throughout the above trigonometry varied from 0 to 1. I proportionally converted these values ​​into values ​​from 0 to 255 to specify PWM on the motors. At low values, the engines only buzzed with different keys, and then they picked up speed quite sharply to the maximum. And intuitively, it was perceived as discomfort when driving the cart. The solution was to add a nonlinear dependence. For small values ​​of the coordinate, for example x, f (x) should grow rapidly. As x approaches 1, the growth of f (x) should slow down. Same for y coordinate. The circle function with the center at the point (1, 0) and the radius 1: f (x) = sqrt (2x - x ^ 2) quite suited me. After adding this transformation in both coordinates, the control became less sharp and more predictable.

And now about the right joystick and head rotation. My shortcoming was that I converted the coordinates of the joystick into the angles of rotation of the head in proportion. Those. the central position of the joystick corresponded to 90 degrees horizontally and 90 degrees vertically. This is the direction of looking forward. I’m lying with the vertical, because I introduced a software restriction on the vertical angle of rotation, and this was not 90 degrees, but the middle of the amplitude of the vertical deviation. But now it doesn’t matter, we will count 90 degrees, because my servos rotate from 0 to 180 degrees. And what happened: with the joystick coordinate (1, 0), the head is turned to the right (0 degrees). At the coordinate (0, 1), the head is turned up (0 degrees). But if the joystick deviates not horizontally or vertically, but diagonally, the head will no longer be able to get to zero degrees through either one or the other servo. The joystick area is a circle, therefore, for example, the coordinate (1, 1) will not be available. Hence the conclusion: the circular region of the joystick with the center at the origin and a diameter equal to 2 must be “stretched” to a square region with the same center and side equal to 2. I solved this problem for the first half of the first quadrant (from 0 to 45 degrees), other solutions obtained by reflections. In short, the following came out: I solved this problem for the first half of the first quadrant (from 0 to 45 degrees), the remaining solutions were obtained by reflections. In short, the following came out: I solved this problem for the first half of the first quadrant (from 0 to 45 degrees), the remaining solutions were obtained by reflections. In short, the following came out:

x '= sqrt (x ^ 2 + y ^ 2)
y' = y * x '/ x
where (x', y ') are the new coordinates, extended for the square, but only for the first half of the first quadrant.

Well, that’s probably all. Correcting manageability, went to boast in the office.


I would like to warn you if you have a desire to enjoy the process of creating a robot, show your imagination, brag to your friends before it’s too late, I advise you to go to the heading “Plans and conclusion”. This section bothers me.

First, at the cost of the parts of the robot itself:
Date of purchaseprice, rub.Name
10/21/20112,590Four Wheel Platform
10/21/20111 990Matryoshka X (Arduino Uno + prototyping details)
10/26/20111,200Servo and bracket for it
11/01/20110Battery packs 12V, 1100mAh 2 pieces (presented)
11/01/2011850Car Mount for HTC Sensation
11/07/20111,690USB Host Shield
11/21/20116902A Motor Shield
11/21/2011290Proto shield
12/01/201193IR receiver TSOP3123
12/01/2011thirteenIR LED TSAL4400
12/05/2011886DC-DC converter TEN 8-1221 TRACO
all period1,000Small things (flux, wires, shrink tubes, batteries, etc.)
Total12 572

Here is such an amount. Prices Moscow. True, parts can also be ordered in Chinese online stores. There, the prices differ strikingly: it turns out to be two, or even three times cheaper. But you have to wait a long time. I did not have much time, although, admittedly, I would not have endured.

Now what have I bought or already had and without which the robot will not go:
Date of purchaseprice, rub.Name
10/29/20111,290XBOX 360 Gamepad
11/25/20113 850Universal Charger IMAX B5
long18 900HTC Sensation (средняя цена по Москве на 19.12.2011 по Яндекс маркету)

Планы и заключение

After two months of midnight work, when I went through everything described above, my wife asked me: “No, I understand everything, but that you just won’t buy a radio-controlled machine?”

I will skip the paragraph.

Yes. So far, what I have is early to call a robot. I understand it. But I think that it will be a robot. The next topic that I am interested in raising is the transfer of video and audio stream from a smartphone to a PC. Well and back.

What I would like to do next is to develop the autonomy of the robot. Now that the mobile platform is ready, on the "shoulders" of the robot is a rather powerful "head" with a high-level programming language, plus you can find ready-made open algorithms for recognizing sounds, images, faces, dizzying prospects open up. I'm afraid to even look so far. If it turns out interesting, I will write further.

I hope my experience, the bumps stuffed with me and a detailed grab card will serve someone.

UPD: The project has been transferred to the service. The name of the robot Mitya has already been fixed in the family and among my friends, so the project is named: robot-mitya .
I opened to view all the source code. Here are all three levels of programming a robot: a sketch for Arduino, an Android application and a Windows application. Subversion is used as the version control system. The tag folder contains a fully working release of version 1.0.0. I checked its performance “from scratch”, downloading the source codes of projects from the server, compiling them and executing them on a robot. In the Trunk folder, as always, the current project branch.
Arduino sketch written in arduino-0022 IDE version. I posted the version of the IDE with the libraries I use in the downloads section .
When writing the Android application, we used the Eclipse IDE for Java Developers development environment of Indigo Service Release 1 with the Checkstyle code analysis plugin installed. The only concession that I allowed myself in the Checkstyle settings was to increase the maximum line length from 80 to 160 characters. The rest of the settings were left unchanged.
To develop a Windows application, Microsoft Visual C # 2010 Express was used. To analyze the quality of the code, StyleCop was used. The express version of the studio does not support embedding extensions, but the use of StyleCop is possible due to the possibility of its integration with MSBuild. The topic is wonderfully described in the article.StyleCop & C # Express .
Good luck

Also popular now: