Laser Tank - Basic tracked robot with Targeting Laser pod!







CURRENT IN AND OUT (meaning that you can track both battery life circles and charging) TEMPERATURE





It's been a while I was using only my Basic Stamps for building robots... But Basic Stamps lack both the speed and the flexibility for most applications even though the are perfect for learning structured programming and the BASIC language. So now the time has come for me to use AVR in my robots... AVR are nice microcontrollers with many features, like interrupts, timers and so on..., they are much faster that the Basic Stamps and the have bigger memory allowing us to write more code... Also they are very easy to use requiring only power to operate (and if you like a crystal - osclinator) and very easy to program (There are many nice circuits out there in Google... I just prefer the 10pin STK500 ISP). So in this project we'll be using the ATMEGA16 @16MHz. But as every project... it must have something special, something to be able to look different from other... But what???

I 've seen many robots with photosensors (photovore, photophobe), many linefollowers, many object avoiders, some heat seakers, sumobots, micromouse and others... BUT, very few had a battery monitor... Most of them run on a new or freshly recharged battery... If the battery was drained and wasn't simply enough capasity to feed the robot???

That's why I incorporate a Dallas Semi DS2438 in my circuit board... I don't like usually to advertise but this chip had everything... A current sensor, a voltage sensor, a thermometer and so other goodies we won't be needing...


Now navigation... Since it'll be a simple navigator - free roaming robot (with some extra features) I'll be using a simple IR_pair for the robot, but if I have time (aaa exams exams exams exams they are killing me!!!) I'll also include a Sonar... The pair will consist of a TSOP1907 and some single IR Leds...


And now it's picture time... Since I have assebled the case years ago and don't like to rip it up right now... I'll be showing some basic pictures of the case of the robot explaining how it was built and which are the thoughts for the future =P....

So here is an overview of the robot case:

Main Case Overview


And here is the front view of the robot... As you can see the case is quite close to the ground but our subject here is not machining clearly but programming the robot behaviors...

Front view


Here is the bottom view of the robot... It used to be used as a place for the batteries but as experience grow it teaches me to place the battery (and any other heavy thing) in the front of the robot to be able to climb hills with easy... But more details coming...

And the bottom of the robot


And here is the machining tips for the wheels!!! I got some servo cross-like horns cutted 'em to fit the inner of the wheel, placed a screw in an empty hole of the wheel and glue it for safety with some super glue!!! And finish... Also I kept the outter axis of the wheel (it was there from the time I bought this poor toy) and after shorting it a little, I fitted it back in. So the Case and the wheels are bond together making the locomotion system more stample than ever. NOTE: that the locomotion system that was with the toy was extremely weak that's why I placed in the servos!!!

Finally, and also very important, after mounting the servos to the case I jointed 'em with that golden pipes (don't know how to call 'em sorry). And here we are... the locomotion system and the case in finished!!! Now it's batteries' time...

And some of the wheels machingAnd the servos joints


And now the hardest part for me... mounting the batteries... Batteries usually are the heaviest part of a robot. Because we have a tracked robot, placing the batteries in the front is crusial for the balancing of our robot and it's ability to climb step hills!


By placing the batteries that way:

Battery holder


I hane the robot balancing it's weight at about the middle of the robot so it's just very ok!!! As you can see the holder is very simple just a part of a pcb mounted to the case with some screws and glue and so long pin headers to hold the battery. So with the battery, it should look like that:


battery mounted


And now the big deal... The electronics. I have been trying to use two microcontroller since the beginning but always something was about the fail... LCD fail, IR fail, frequency generator fail... And do on which I really hate to describe (my hours being lost for nothing). And the biggest of my problems... That f*ckin# TSOP were broken, they were old - yes, but broken??? AAggghh!!! All my Sunday for a pretty nothing... Uugghh, sorry for this but I think everyone can understand me... So, finally, I had 'em replaced with some nice Panasonic ones I had... (desoldered 'em from older boards I have made and almost never used...) Surpassing these promblems after many hours having been wasted I finished the main board consisting of a ATtiny2313 @ 20MHz that I won't refer to cause it's never used, the main processor which is an ATMEGA16 @ 16MHz, a simple regulation circuitry, a NE555 tuned at ~38KHz for the IR leds and the pride of the board! The DS2438!

Before I get any closer to the software I'll give the schematics...


So here are the schematics for the main board of the robot:



The regulation circuit consist of a simple 7805, some filter capacitors and some anti-current spike capacitors

And here it is:


And now the NE555 schematics:


So after all these the board should look like that:



And finally the board mounted on the case!!! I feel just nice...




This comes after a time I know... BUT... Many things dramatically changed on LASER Robot Tank so,

I got to do things almost from the beginning.





Yes, the remake guys... It was about time... See below...

Laser Tank was an old idea… Actually the pictures above shows version 2, which didn’t satisfy me at all. Although the basic functions did work, they didn’t work well…

Problems occurred… Many… The IR weren’t working well and the frequency they emitted wasn’t controlled by the microcontroller. Also, very very lite sensor background…

By controlling the frequency of the IR you can determine the detection range of your sensors…

In version 3 the IR LEDs are connected directly to the microcontroller. And not controlled by the NE555. For this we employ the 16bit timer of our ATMEGA8535, timer1.

We set the compare value so that our timer produces a 38 kHz to 44 kHz signal. NOTE that the higher the frequency the lower the detection range. This is because the higher the frequency is the smaller the wave length is. Shorter wave length means shorter travelling distance because the mean of travelling (which in our place is atmospheric air) remains the same.

The frequency is delivered on our OC1A pin which in ATMEGA8535 is PortD.5 which is connected to a system of transistor, playing the role of an amplifier with a variable gain.

This is for controlling the current through LEDs so we can further adjust their brightness and further more the detecting range.


But remind me why we wanted that frequency after all…

As object detectors we use two IR pairs. The emitter is a common LED… Not much to say really… The receiver is a TSOP1738… As it suggests 17”38” it can recognize a 38kHz carrier transmit. But this is for an ideal world where no wars occur etc etc etc…. In the real world the 38kHz filter is not perfect and let’s other frequencies pass… So the sensor will recognize a carrier from 36kHz to 44kHz maximum…


Now that we can control the distance that our sensors detect objects, we can basically do miracles… One great thing we can do is not only follow an object but also keep a steady distance between the object and the vehicle… Although I talk with such a pride about it I had some problems with the code… Although I had a steady distance between the robot and the object the follow the object code didn’t work so well…

First, we will explain how the whole thing works. In front of us (robot) there is a field, right? Right. We can separate this field of view, in smaller areas. Imagine the closest area just in front of the robot. Consider that objects in this area can always be detected by the sensors. A little further there is an area that objects are detected, but not always. Even further there is an area that sensors can hardly detect an object. Are we straight that far? Nice. But if the frequency of the IR pair is fixed we just see if there is an object in a certain area in front of the robot, right? Right! Nice… We can use this in our advantage. Imagine now the far area that sensors hardly peak up. If we set the frequency close to 36 kHz, we have a wide detection range, right? Right! But if we set the frequency close to 44 kHz, we won’t pick up an object that far, right? Right! Now imagine the area in the middle. If the 36 kHz could pick objects in the far area, it is certain that it picks up any objects closer. When we are close at 40 kHz we begin to lose any sights of objects. So approx. the 40 kHz means the middle zone. At the zone just in front of the vehicle, objects are detected by all three frequencies. So we can now tell the robot to act alike.

If an object exists in the far zone, the robot wants to come closer. If the object is just in the middle, the robot likes it. So it stays just where it is. But our robot is afraid of objects… They may trigger its interest but it likes to keep its distance. So if the object is in the every frequency zone, it heads back…

Although object tracking is an interesting code, mine didn’t work well… I hope to fix that. In the existing code the objects acts well in the middle zone but it doesn’t act well in other zones. Not a matter… The point of LASER robot wasn’t just an object tracking code… You will see this later.

So what’s the point of this robot? Well, no more than code demonstrating. This robot was meant for a robot exhibition here in Greece at Athens Digital Week. So what do we demonstrate here? Microcontrollers. Yup! That’s right!!! What I haven’t reveled so far is that the robot uses two microcontrollers… Oh, yup!!! Two ATMEGA8535! And if so, how the whole show runs??? Well…. One microcontroller acts like HID (Human Interface Device) and the other microcontroller acts as SVC (Slave Vehicle Controller). Yeah, you think we got something here??? No… I’ll explain…


The two microcontrollers “talk” to each other via UART. What they say? How nice the weather is!!! I don’t fool you… please... Of course it can’t tell if it’s a lamp or the sun but that’s all right… It’s some basic photoresistors of course… Well, one of the functions embedded to the robot is to measure the sunlight (or just light) on its photoresistors.  One microcontroller is tasked to measure the light constantly on both photoresistors, compare their value and sent a string of data to the other… The string contains data which tell the robot where to turn to… The locomotion of the robot is based on two servos… So yes, the other microcontroller takes the data and produces two PWM signals which are made in software and not based on a hardware timer or PWM signal.

This is about robot tracking light… But the robot is also able to move its turret towards the light based on these photoresistors. For now light tracking is made in two dimensions. As soon as I get an extra photoresistor I’ll add it to the code.

But today, there is so much word about energy! Energy here, energy there, they make USB batteries (which cost to build is much higher than a simple NiMH and its charger… sorry I had to tell), they say we have global warming and all that……………. which I find at least funny……. Ok, I think we sidetracked a lot. The mean of all these was that I have included the DS2438Z IC to the party. The HID microcontroller is responsible for it. If you want details on the IC feel like paying a visit to the other site I wrote, Smart Battery Monitoring – DS2438Z. What we do with the IC? We measure the voltage of the battery of course.  When the battery drops below a desired voltage level, I immediately stop using the servos. But this only happens in free roaming mode… Free roaming mode? Mode? What?

Well, it’s true that constant reprogramming not only is hated my EEPROMs but also from programmers. And in our case, where this robot is supposed to be exhibited, the least you want is to reprogram it constantly in front of people… Not a chance! Period!

So how do we solve this problem. Well, you can embed many programs in one bigger!!! And how we change the programs in between. Well, that’s easy! First of all we got a 4x20 LCD to display whatever information about the programs. Still we need interface. Well, please, don’t expect much. I just use simple push buttons, in general IO, I didn’t want to get involved with interrupts because the tent to mess with LCD displays. So, there are three buttons, the one you can enter/enable and other two which are for up and down!!! Don’t be surprised if I tell you that all these are made by the HID microcontroller!

Now, let’s have a little talk about the modes. Mmm, many modes and that is good for an instance! Well, let’s name them: 

1.       Turret light tracking and rest of the robot still

2.       Select roaming modes

a.       Track light (photovore)

b.      Basic IR roaming with DS2438Z low battery hold

c.       Follow object (still the code needs work

3.       Free Roaming with IR and turret tracking light on its own will

4.       DS2438Z battery monitor report, anything else off

So here are all the modes, luckily for me I have explained them above!!!


Oh, I just forgot to mention… No Sonar… Scans take too long to consider it an active sensor so I keep it for something else!!! Well, this something is coming soon too! Yup, I’m high!!!