# Society of Robots - Robot Forum

## Software => Software => Topic started by: pomprocker on September 09, 2008, 02:34:50 PM

Title: indecisive robot algorithm
Post by: pomprocker on September 09, 2008, 02:34:50 PM
So is there a rule of thumb for setting up a decision line between your robot making one decision or the other?

Currently my robot can't decide if it wants to go left or right and ends up running into the wall! lol

Its kind of hard to explain in detail, but I have a sharp IR mounted on a scanning servo, on a diff drive robot.

If the IR sees something to the left, make the robot go right, and sees something on the right make the robot go left.

I'll post code and maybe a video later, but I need to wait until I get home tonight. Maybe I just need to think this through a little more.

Title: Re: indecisive robot algorithm
Post by: pomprocker on September 10, 2008, 03:01:07 PM
I was reading through the Sharp IR mapping tutorial on here last night.

Are there any spoonfed tutorials out there on this?

I can't even comprehend how to calculate speed of robot, angle to turn, angle of the scanner, and distance of the object.

My brain turns to gobbeley goop.

I've looked through the source code of fuzzy, and the iRobot Create mod listed on here.

???
Title: Re: indecisive robot algorithm
Post by: Webbot on September 10, 2008, 06:22:20 PM
I was reading through the Sharp IR mapping tutorial on here last night.

Are there any spoonfed tutorials out there on this?

I can't even comprehend how to calculate speed of robot, angle to turn, angle of the scanner, and distance of the object.

My brain turns to gobbeley goop.

I've looked through the source code of fuzzy, and the iRobot Create mod listed on here.

???

Congratulations on your 'wall seeking' robot  :D

A lot of your questions depend on whether you have 'one or more' fixed Sharp sensors - or one sensor mounted on a servo that swivels around. Which is it?

Quote
Currently my robot can't decide if it wants to go left or right and ends up running into the wall! lol
If every loop in your main code is making the decision afresh then you can get this problem. So you need to detect when your sensors are in this scenario and make a decision on which way to turn that will stay consistent until you are out of the situation.
Title: Re: indecisive robot algorithm
Post by: Admin on September 16, 2008, 11:53:48 AM
Quote
So you need to detect when your sensors are in this scenario and make a decision on which way to turn that will stay consistent until you are out of the situation.
pomprocker, you're robot has passed the level of being aware of objects in the way, and now needs to make sense of the objects and make intelligent decisions based on that data.

Write a program that uses the Sharp IR to identify the *shape* of the object (ball, box, chair leg, etc). Then have it capable of identifying multiple objects next to each other. Then have your program detect the distance between those two objects. My Sharp IR tutorial explains it all.

That'll give your robot a wealth of new information to do more intelligent things (up to your imagination).
Title: Re: indecisive robot algorithm
Post by: benji on September 16, 2008, 03:08:31 PM
when you do a scan you are getting polar data (both angle and distance)
you can turn this to cartesian data (x , y) and have a matrix of the area around
then you can make the robot choose a target based on somthing and run the wavefront algorithm to find shortest path to go there

now your robot is way more intelligent  ;)
Title: Re: indecisive robot algorithm
Post by: Ro-Bot-X on September 16, 2008, 07:43:52 PM

I can't even comprehend how to calculate speed of robot, angle to turn, angle of the scanner, and distance of the object.

To calculate speed, traveled distance and angle of turns you need encoders. Encoders are sensors mounted on the motors or wheels that will generate a number of pulses for a wheel rotation. There are simple encoders (one pulse line) and quadrature encoders (2 pulse lines). With the latter you can also detect which way the wheel is turning.

The easiest way to do it is to mount a mouse scroll wheel directly on the robot wheel. One simple encoder is enough for the basic stuff. The scroll wheel will output 24 pulses per revolution. If you mount it so the scroll wheel touches the tire of the robot wheel, you will have more pulses per robot wheel revolution (but you have to calculate or count them). Attach one pin to the ground and the other to the external interrupt pin PD2 (INT0) or PD3 (INT1) and use a pull up resistor (the internal pull-up resistors of the microcontroller are fine). Then you can use interrupts in code to count the pulses.

To measure the traveled distance you have to calculate you wheel circumference, divide it by the number of pulses per revolution and you will get the distance the robot will travel for one pulse. Then you multiply that with the number of pulses and you will get the traveled distance. My robot's wheels have 160mm circumference and the encoder outputs 32 pulses per wheel revolution, so the traveled distance per pulse is: 160/32=5mm.

To calculate the speed, you will have to count how many pulses the encoders will generate for one second of travel time, then multiply that with the distance per pulse. In my case the encoders output 160 pulses per second, that means 160*5=800mm/s or 0.8m/s.

To calculate the turn angle, you need to measure the distance between the robot's wheels. Then multiply that with 3.14 to get the distance the wheel will travel for a complete 360 degrees robot turn. Divide that with 360 to get the traveled distance per degree. And finally multiply that with the traveled distance per pulse. To simplify calculations, I calculate the distace between the wheels so the distance per degree is 1mm, and the wheel diameter so the distance per pulse is an integer number of millimeters (also depends on the number of pulses per revolution). So, my wheel's diameter is 50.95mm, the distance between the wheels is 114.65mm, encoders output 32 pulses per revolution, I get 5mm travel per pulse and 5 degrees turn per pulse.

I hope this helps.
Title: Re: indecisive robot algorithm
Post by: Ro-Bot-X on September 16, 2008, 09:38:06 PM
Ok, about the object angle and distance.

If you are using the \$50 robot board and code, you have those magic numbers for servo position (25-35-44). Each number coresponds with a servo horn position, starting from the 25=left=0 degrees, 35=middle=90 degrees, 44=right=180 degrees. So you have about 10 degrees for each servo position.

You start from the left and take a sensor distance measurement for each servo position. This is what benji was telling you about the polar data. To actually build a map you need to transform this data into cartesian data using trig functions sin and cos (from a lookup table). You round up the coordinates or transform them into smaller unit division, for instance, measure the distance in cm and transform it (after doing the math) in mm. After that, you need to determine in which cell the coordinates belong to. Then you can mark on your grid the cells that contain objects. But this is a cell grid that is different from the map grid, because it is centered around the scanning servo, with negative x coordinates to the left and positive x coordinates to the right. If you know the robot's position on the map, you can use that to recalculate the coordinates of the obstacles and mark them on the map (add the obstacle x and y coordinates to the robot map coordinates).

So you know how far the robot travelled on the map and where are obstacles around it. Now comes the part where you decide where the robot should go...

Edit: After I went to bed I realised it is not that simple to just add the object coordinates to the robot coordinates on the map, you have to account for the robot's heading on the map. If it is North, then yes, it's that simple. If it is another direction, then you have to calculate again using trig functions...