Simple robot project ATtiny2313 microcontroller used robot body for a cheap remote controlled toy car is made up of the robot’s four sides LED sensors placed somewhere when it hit the back çekliy direction…Electronics Projects, Toy Car Modification Made Simple Robot Project ATtiny2313 “avr project, microcontroller projects, “
Simple robot project ATtiny2313 microcontroller used robot body for a cheap remote controlled toy car is made up of the robot’s four sides LED sensors placed somewhere when it hit the back çekliy direction change somewhere else until you hit continues 🙂 motor drives the car as on the original circuit drive partition (sm6135w) used There is a simple transistor circuit .. schema, in addition to a distinct beauty of this pressure sensor circuit diagram drawings, source code through ATtiny2313 find. Also check ATtiny2313 floor designed as a simple set of experiments can use it in different projects, each floor of the circuit works ..
I admit honestly, initially I, like many, had seen enough of the websites / forums on robotics and wanted to make myself a useful robot – a vacuum cleaner (well, what else is simple and useful you can think of, if I do not participate in any competitions and I don’t even know Is there any kind of robot-building activity in my city?). But life taught us not to rush into the pool with my head right away, so for the beginning it was decided to assemble a simple, super-cheap robot – for testing. Since I somehow figured out the electronics, the problem began with the mechanics (chassis, body, suspension) and the choice fell on a toy car, as the most affordable version of the chassis, which does not require much effort to upgrade to fit my needs. At the local bazaar, in the ranks with children’s toys, a seller was found who agreed to sell me a cheap car on a radio control for a cheap price (without a remote control,
Then the creative process began …
Obstacle sensor on 3 LEDs
I admit honestly, I am a beginner in electronics and have just been repeating other people’s finished designs before. I came across an article (http://habrahabr.ru/blogs/arduino/55470/or forum68 / topic6768.html) that a conventional LED can be adapted as a light sensor. Krutenko principle is this: power is supplied not to the anode (as usual), but to the cathode, charging the parasitic capacitance between the LED and the legs of the microcontroller; After a few milliseconds, the parasitic capacitance is charged and the power from the cathode is removed, and the corresponding microcontroller output is transferred to the input and the time required for the microcontroller’s signal to fall into a logical 0, which depends on the LED illumination (the stronger the LED is illuminated, the faster the parasitic capacity on his leg). Collected. Checked It worked. People in the network also makes sensor modules based on such LEDs. They work on that
As they say, I thought for a long time …Joke. A thought occurred to me, but why only a light sensor? Why not an obstacle sensor? It seems to be a simple idea – to light one LED to the second (both LEDs look in the same direction) and if the light is reflected from an obstacle, then the discharge time of the LED sensor will decrease significantly. There is only one problem. Such a sensor is completely unprotected from external “flare” (i.e., the illumination of the “terrain” is not taken into account, for example, during the day and at night it will be radically different). Therefore, it was decided to add a second LED sensor, which would not be illuminated by the LED headlight, but would “measure” the total illumination, knowing that the readings of the obstacle sensor can be correctly interpreted. For,
The board was drawn, the construction was assembled The control program is super simple: if the discharge time of the LED sensor forward is less than that directed upwards, then there is an obstacle (otherwise, there is no obstacle).
Engine management module (engine driver)
In the machine itself, there was a handkerchief responsible for receiving, transcoding, and then controlling the movement of the machine. It was assembled on the Chinese chip SM6135W (this is a specialized receiver chip for radio-controlled machines, analogue of the RX-2B, which itself decodes commands received over the radio channel into 4 commands: FORWARD, BACKWARD, LEFT and RIGHT). Each of the commands corresponds to the chip output (LEFT and RIGHT turn the front wheels left / right). At first, the idea to pretend to wire commands for this chip was set on fire, as if they were received over the radio channel, but the test attempts did not succeed (firstly, the command system is not described on the chip itself (I will not say anything as I read the data in Chinese in translation google), an analog was found – the date is shit on the RX-2B (analog)
Due to the failure to use the SM6135W native chip (the advantage was the ability to control the motors over one wire, with some complication of the control program), I dropped this mikruhu and redid the control to direct control of the microcontroller of the FORWARD, BACKWARD, LEFT and RIGHT commands directly from the microcontroller ports ( at the same time, 4 microcontroller legs were involved, but in general I had enough legs).
Because of this, the control of the engines is also simple – we set 1 on the corresponding leg of the microcontroller (to move forward on the FORWARD leg, to back on the BACKWARD leg, to the left on the LEFT leg and to the right on the RIGHT leg).
Microcontroller board ATtiny2313
Either I do not like excesses, and the task was to make the test robot as cheap as possible, the choice fell on the ATtiny2313 microcontroller (calculations showed that there were enough legs, although literally all legs were involved, except for RESET and one pin of the PORTD port). The microcontroller board was completely taken from the site RoboZone.su (http://robozone.su/2009/06/30/prostaya- … y2313.html). (PS: In general, many thanks to the authors of the site, I started to look at them with their designs and still often look there). The only difference is that the outer quartz was not set (again, both as superfluous and to make the structure cheaper). The built-in one is quite enough (frequency stabilization is of no use to the robot, and the debugging was also successfully passed from the built-in generator through the COM port).
It was decided to use 4 obstacle sensors (one above each wheel). 4 sensors with two outputs per each (cathode of the LED pointing up and LED pointing forward) took 8 legs (all PORTB), 4 legs of the PORTD port took commands to control the driver of the engines from a radio-controlled machine, 2 ports are used to debug the program via COM-port .0 and PORTD.1), and even involved PORTA (START and STOP buttons). So almost all the legs of the microcontroller were in business.
In the process, it turned out that for some reason (I don’t know exactly why so far) on the PORTB.5 stem (responsible for the SCK signal when programming), the signal level never drops to logical 0 (although if you touch the voltmeter probe, then everything starts to work), so PORTB.5 was moved to PORTD.6 (the only free leg of the port PORTD). But this is for those who decide to see the outcome of the nickname of the firmware, so as not to be surprised.
The issue of power was resolved using 4 batteries of 1.2 volts each (total 4.8 volts). Initially, the machine was designed for 6 volts (4 AA batteries), but somehow I didn’t want to supply 6 volts to the microcontroller (although I read what I had to withstand), and the idea of being able to charge batteries repeatedly attracts much more than disposable batteries buying two extra batteries cost as much as the rest of the machine with mechanics and electronics combined, but perhaps it says more about the cheapness of the robot itself).
The whole structure is assembled on a piece of transparent plexiglass lying in a flat, which was later supplemented with a bumper made of a plastic lid from a can of mayonnaise (because it was tired to unbend the “crumpled” LEDs while debugging the program). The plastic bumper cover was surprisingly excellent. Tough enough and at the same time quite elastic. In a word, although from what it was, perhaps it would have been better not to do it.
When the motors were turned on and off, noticeable drawdowns were observed on the power supply, up to the reset of the microcontroller, so that a 2200µF / 16 Volt capacitor was added to the power supply (I didn’t know how to correctly calculate the required capacity, so I just picked up the “random” capacious, not sickly and not expensive) . Enough for the eyes (although it seems that the battery power is more stable and less prone to voltage subsiding than the test power through the KR142EN5A, which I fed to the robot while debugging on the table in stationary conditions (wheels in the air).
In addition to the “native” battery compartment, located under the bottom of the machine, another one was added on top, connected in parallel, to be able to install 8 batteries (giving a total more current), because practice has shown that this voracious baby eats enough many (40 minutes of active driving sits a set of batteries).
In principle, the tasks of the robot did not stand any. So far, just goes without bumping into obstacles. So the program turned out to be simple. The sensors are polled sequentially (at first I tried polling in parallel, but apparently the “ground” is common for all microcontroller legs, because for all the LEDs the discharge time was always exactly the same). But a consistent survey of sensors is also quite enough. Typically, the discharge time of the LED sensor in cloudy weather is about 7-10 milliseconds. Those. All 8 LED sensors can be polled for 80 milliseconds, which is about 12.5 polls per second. Robot large FPS and not needed. In addition, measures have been taken to prevent “freezing” on the survey of sensors. (the fact is that in complete darkness, the LED sensors can be discharged to 2-3 seconds, which of course is unacceptably slow for a robot, but if the sensor looking forward is not discharged in 7-10 milliseconds, as in cloudy weather, then it probably already doesn’t light up due to the obstacle of the neighboring LED, and therefore there is no sense to wait any longer and the general “illumination” doesn’t worry us in this case, t. to. Obviously there are no obstacles).
The movement of the robot can be described by the words “where it is free to go there.” Those. if both front sensors do not show any obstacles, go ahead. If the obstacle is in front of the left, then the food is still ahead, but we turn to the right (what if it is the leg of a chair and we have time to go around it?), Etc. Similarly, we act when we go back, and we go back, if both front sensors show obstacles. If the obstacles show all 4 sensors (well, we drove into a corner between furniture), then turn off the engines and wait until the “developer” carefully rearranges to free space.
I admit honestly, the sensors on LEDs are certainly not as protected from illumination as the sensors on TSOPs, but the presence of a second LED that measures the total illumination all the same clearly improves the situation. The only case when the sensor incorrectly interprets the situation is when, for example, the Sun from the window in the morning / evening at a small angle lights up the LED pointing forward more than upward, but this usually happens with one sensor out of 4 (the Sun cannot light up the sensors directed forward and directed back at the same time?). It is solved by directing all 4 sensors in different directions (for example, front sensors at an angle of 120 degrees between themselves and rear sensors at an angle of 120 degrees between themselves). Thus, the Sun, even being low above the horizon, “mistakenly” lights up no more than one sensor, and when the machine goes “to” the Sun,
With indoor lighting (a lamp on the ceiling), without light or in daylight, the device behaves adequately (there is no such that the LED pointing forward is more illuminated than the one that is directed upwards when there is no obstacle). Although with a bright sun, of course, the “range” of detecting an obstacle falls sharply (the LED light gives a weak “additive” to the already strong background illumination). At night or in the dark – generally behaves well. If you give the robot a name, then I would probably call it “The Bat!” (Bat) for the most adequate work in the twilight and darkness and the desire to “slip away” from direct Sunlight into the shade.
Power supply of 5 volts for 6 volt engines is enough. Although the soft carpet goes with difficulty. The pitfall to which I ran into the engine driver was the following: it’s understandable that you cannot simultaneously send opposite FORWARD and BACKWARD or LEFT and RIGHT signals, since This causes a fault in the engine driver. And this possibility was programmatically excluded. But it turned out that if the signals change quickly (and the microcontroller operates at 8 MHz), then there is still a short-circuit (apparently, the transistors in the driver do not switch so quickly), and the current flowing in the motor windings must be “extinguished”. So before each change in the direction of the engine, the controller first pauses 0.7 seconds, and only then changes the direction of rotation of the engine. 0.7 seconds was chosen experimentally (I do not know how to count them either).