31-03-2010, 06:58 AM
Robotics and Autonomous Systems
Project Report
Presented By:
Team members:
HeijkenskjOld, Hannes
Kalen, Martin
MalmesjO, Stefan
Abstract
This is a report of the project for the course 2D1426 Robotics and Autonomous Systems. It describes the ideas and the design of the Ad Hoc robot. It covers the main design goals, implementation and results.
The goal of the robot was to play table hockey, and above all to be able to score a goal. This was actually accomplished during the qualification round for a table hockey tournament. However, the robot never managed to score during any of the actual games. It was built of Lego bricks, and controlled by a micro controller.
The task at hand
The task of the project was to build and program a robot that could play table hockey with special rules, and that fulfilled constraints on the construction. The robot was to be built from Lego bricks and meccano, with the addition of whatever bits and pieces the constructors thought necessary. The teams were assigned two 12 V DC motors, one 6 V motor and an RC servo, which were used for locomotion and for manipulating the stick. The robot was controlled by a small 8-bit micro controller (see Appendix 1 - Parts List; PIC16F877 and [4]). To find its way on the hockey field, the robot could be equipped with a variety of sensors, such as Infra Red light sensors, reflex detectors and micro switches.
The constraints imposed on the robot were among others the following (for complete rules see [5] and [6, Part III]):
¢ Diameter of the body was to be less than 250 mm.
¢ No concave part on the body.
¢ The stick could be no wider or longer than the puck, and should not hide the latter's IR emitters.
¢ The stick could have no moving joints outside the robot's body.
Fig. 1 The hockey field
The hockey field (see Fig. 1) is a white surface, 2.4 x 1.2 m, with a black goal zone in both ends. The robot was not allowed to enter either goal zone, so some kind of sensing of the proximity to the zone was necessary. Both goals emit IR light with different pulse modulations, as does the puck. In order to be able to see each other, the competing robots also radiate IR (see Appendix 1 - Parts List; SFH485P and [3]) with modulation different from that of the puck and the goals.
To score a goal, the puck had to be put within 2 cm of the opponent's goal, without the robot entering the goal zone. Pushing or shooting the puck into the goal could accomplish this. If the robot entered the zone the goal was not counted.
Given these premises, the team designed, built and programmed the Ad Hoc robot. This report presents the design ideas, goals and implementation, and the final results and conclusions.
Design
The main goal of the overall design of the robot was to have a small, agile and fast robot, being able to outmaneuver the opponent and scoring a goal by driving the puck into goal with high speed. The team's goal for the robot was to have several behaviors, and then somehow weigh these together in order to achieve a "smart" result. To do this, vector summation was used, where each behavior contributed with one vector.
Sensing and sensory processing
Three different kinds of sensors were used in the construction; IR detectors (see Appendix 1 - Parts List; TSL261), reflex detectors (see Appendix 1 - Parts List; ITR8307) and micro switches. The input from these devices was used for decision making in navigation. The IR detectors were used to determine direction and distance to the goals, the puck and the opponent (see [2]). The reflex detectors were used to tell whether the robot were in a goal zone or not. The micro switches were used to detect if the robot had run into something. They were also used to determine whether the puck was in the possession of the robot or not. Two different code libraries were used for sensory input, bumplib and ir_servo.
IR
The robot had a separate processor, PIC16F876 (see [4]), which handled both IR signals and the R/C servo. This processor was preprogrammed so it could make out the difference between the four incoming IR signals: the puck, the opponent, the defensive goal and the offensive goal. These four targets continuously sent IR pulses, but they did so with different frequencies, so that they could be separated by the IR-PIC, and the targets distinguished.
Five IR sensors, TSL261 (see [2]), were placed on the robot. Two situated in the front (they were placed in 90° angle), twointhe rear (also 90°), and one forward facing sensor in the front. The four ones first mentioned, called "high sensors", were mainly used for estimating the direction to the target - but also the distance from it. The sole front sensor, called "low sensor", was used to measure the distance.
Fig. 4 Front IR sensors Fig. 5 Rear IR sensors and IR position beacon
Since the sensor values were sensitive to disturbances, and hence had a considerable amount of noise, mean value calculation over the two last readings was used, in order to get better values.
The exact angle to the target was never calculated. Instead, a relative measurement of the IR readings was done. First, the difference between the sum of the two rear sensors and the sum of the two front sensors was calculated. This way it was determined whether the target was in front of or behind the robot. Analogously, it was calculated whether the target was to the left or the right of the robot. The relative difference between the calculated values was used in order to calculate how much to turn each of the wheels. This worked rather well.
Whenever the need for calculating the distance to a target (for example a goal) arose, the way to figure it out was to use the strength of the IR readings. These were calibrated for each individual task, to fit accordingly. It would show that this was harder than originally thought, since the absolute value of the readings varied significantly from run to run.
IR filtering was controlled by the slave micro controller. The only thing that had to be handled in software was the interrupt generated when a complete byte had been sent on the serial line between the two processors (SPI) and to receive the IR data in correct order. This was done in the service routine in the ir_servo library ir_sevice_routine().
Reflex detectors
Under the robot, facing down toward the table, four reflex detectors were placed - one in each corner of the robot. These detectors sent out IR light, and measured how much was reflected from the surface of the hockey field (see parts list and [1]). This reflection was presented to the robot with a value between 0 (white) and 255 (black), after converting the analog signal with the PIC's built-in A/D converter. The reflex detectors were connected to the AN-ports (analog in). The function bump_poll_sensors() in bumplib was used to run the A/D converter to sample all reflex detector channels.
This information was used for estimating whether the robot was going into a goal zone or not, which was not allowed. Since the field had a black stripe for marking the middle of the field, the reflex detectors together with information from the IR sensors were used to estimate if the robot was in a goal zone or merely on the middle field stripe. So if the reflex detectors signaled black surface, and the IR sensors signaled goal proximity, then robot was positioned in a forbidden zone, and hence had to quit going in that direction.
Micro switches
The micro switches were used for tactile sensing. Attached to the micro switches the robot had antennae, which would depress the switches if it ran into something. Seven switches were used; one placed in each corner of the robot, one on the stick, and two in the front of the robot. The two in the front were used for detecting puck possession, and the others were used for obstacle detection. All bumpers and an optional emergency stop were connected to PORTB on the PIC. The function bump_poll_sensors() in bumplib was used to update bumper status, e.g. reading PORTB. As mentioned in the "Reflex detectors" section above, this function also samples reflex detectors.
Locomotion and navigation
There are different ways of moving a robot. The Ad Hoc robot was built with two wheels, which were run independently of each other using two separate 12 V motors. This made it possible for the robot to turn around on the spot if necessary, by running the wheels in opposite directions. In order for the robot to keep its balance, a small, smooth piece of Lego, placed in the front, was used for support.
For navigation the team used a behavioral approach. The idea was to program the robot with several behaviors, active at the same time. They were all to have their own will, and then some coordinator was to combine these wills, and produce some appropriate action for the robot. Each behavior should produce a "wish vector", telling the direction in which the behavior "wanted" to go. This way all the behaviors got to tell their wish, and then vector summation was used to calculate a final direction for the robot. Depending on in which state the robot was (having the puck or not) the different behaviors' wishes were assigned different weight, which were used in the vector summation.
There were five different behaviors in the robot.
¢ The find puck behavior - always wanted to go toward the puck, unless the puck already was in the robot's possession. If the robot for some reason didn't see the puck, it simply spun around, trying to locate the puck.
¢ The get puck to goal behavior - always wanted to go toward the offensive goal, as long as the robot had the puck.
¢ Avoid obstacles behavior - if the robot ran into something, this behavior tried to go in a different direction from the original one. It also stopped the robot from going into a goal zone.
¢ Avoid opponent behavior - tried to get the robot not to run into the opponent.
¢ Random behavior - produced a random (small) wish. This was to avoid that the other behaviors would sum up to a no wish, i.e. to wish the robot in exactly opposite directions. A small random vector wouldn't affect the behaviors normally, but in such a case it could add enough to get the robot out of the clash.
All different behaviors were implemented in the behavior module and the wish summation and actual motor speed settings done in the main file, function sequencer().
Manipulation
In order to be able to control the puck, the robot had a stick - seen in the figures below. The stick design was somewhat problematic, since the robot should be able to turn in different directions and still keep the puck (if the robot had it, of course). The team decided that the best way to achieve this was by swinging the stick over the puck, not just from the right to the left - which would have made us lose the puck more easily. In order to achieve this, an R/C servo was connected to the stick, to be able to steer it into the appropriate position at all times.
3
The appropriate position is dependent of the robot's current state. If in possession of the puck (which was determined by combining the information from the front bumpers and the IR readings), the robot should keep the stick on the opposite side from the direction in which the robot was turning. This would make the stick swing virtually all the time, if not suppressed by a turning rate threshold in the software. If the robot were to turn less than this threshold value, the stick swing was skipped. This proved to work rather well; the robot could turn pretty much without loosing the puck.
In the code, the check_club() function in the main program file was used to position the stick on the appropriate side of the puck. If the robot had possession of the puck and it was turning rather fast, the motors were stopped until the stick swing was complete. Otherwise, e.g. if approaching the puck from a distance, there was no need to stop the robot and move the stick all the time, so in this case the function would exit right away. This proved to be rather successful as fast movements from side to side were not carried out at all. The ir_servo lib was used for the actual servo position setting, as servo positioning was also controlled by the slave PIC and sent through the SPI interface used for IR data reception. The function servo_set_club() and the macros CLUB_LEFT and CLUB_RIGHT were used for setting the right position data to transmit on the SPI line.
Integration of the above
To put all this together, a state machine was implemented, which kept the robot in the correct state at all times. There were three states, but more could easily have been added, if needed. The three states were "Have puck", "Don't have puck", and "Score". The "Score" state was rather special, so a completely predefined movement was used for that one. The other two weighed all the behaviors' wishes together, and used vector summation to calculate a final direction vector. In both of these states, the most important behavior was to avoid obstacles (among other things because the robot was not allowed to enter the goal zones), so the weight of this behavior was greater than the sum of the weights of the rest of the behaviors. This way, the avoid obstacles behavior would always get its way. The avoid opponent behavior had a weight that was determined by switches on the motherboard (see section Electronics; DIP switches) with a value ranging from 0 to 3, setting the overall "aggressiveness" of the robot. The random behavior was set to a low weight, so it wouldn't interfere with the others too much. The only use for the random behavior was to avoid livelock, when all the other behaviors' wishes would add up to a zero vector.
¢ Don't have puck - here the find puck behavior was important, so the weight was set rather high.
¢ Have puck - now the robot's goal was to get the puck to goal, which is why the weight for that behavior was set
high.
The "statemachine" was implemented in the main program file, with behavior activation in the main() function and state control in the decice_state() function.
After the main loop had asked all the behaviors to tell their wishes, the sequencer was told to carry out the order. The sequencer then did the vector summation from all the behaviors' wishes. When it knew which way to go, it decided whether or not to swing the stick, and then it gave speed orders to the two wheels, so that the robot would move in the wanted direction.
The score state was activated whenever the robot was in possession of the puck, was facing toward the opponent's goal, and was close to it. In order for the robot to always try to score, regardless of the opponent's position, a completely separate movement scheme was programmed for this purpose. In order to accomplish this, the robot was set to the maximal speed possible (so the puck would get enough velocity to reach all the way to the goal when the robot stopped at the goal zone), and then kept an eye at the IR readings to know when enough proximity to the goal was achieved. When the robot got close enough - or when the reflex detectors signaled that the robot was in the goal zone - it would stop, and hope that the puck would get into the goal.
Software implementation
Behaviors
Each behavior described in Locomotion and navigation is implemented in a function in behavior.c (see Appendix 4 -Source Code). These functions calculate a wish vector, indicating in which direction the behavior 'wishes' to go. The behavior algorithms work as follows:
¢ behavior_get_puck() - This behavior uses the IR readings of the puck to determine if the puck is in front of or behind the robot, and if the puck is to the left or the right of the robot, as described in the section IR above. If the readings are too small on all sensors, the puck is not seen, and the wish vector is set to full right spin. If the puck is behind the robot, the y-component of the vector (forward-backward component) is set to zero, because the robot shouldn't back into the puck. When the puck is in front of the robot, the x-component (left-right component) of the wish vector is set to zero if below a certain threshold, in order to avoid an oscillating behavior when closing in on the puck. Otherwise, the largest of the x and y values is set to MAX_WISH, and the other is scaled accordingly.
¢ behavior_puck_to_goal() - This behavior uses almost the same approach as behavior_get_puck() when calculating where the target is. The main difference is that no consideration is taken as to whether the goal is behind the robot. This is because the vast amount of disturbances from other IR sources, which makes it virtually impossible to find the goal in a reasonable manner when the goal is behind the robot. Instead the behavior assumes that if the goal isn't in front of the robot, it can be found behind the robot, hence the behavior wants to stand and turn in order to try to find the target. On the other hand, if the goal is in front of the robot, the same scaling of the x and y vector components as in the behavior_get_puck() is carried out.
¢ behavior_avoid_opponent() - This behavior is the opposite of behavior_get_puck(), but when talking about the opponent, not the puck. The wish vector is calculated in the exact same manner, and then the direction is reversed in order to get a repelling conduct. One difference is that if the opponent isn't seen, the behavior doesn't want to turn around to try to find it. Instead a zero wish is produced.
¢ behavior_avoid_obstacles() - Tries to avoid running into obstacles. To accomplish this, the behavior investigates whether any of the micro switches has been depressed. If this is the case, the behavior wishes to go in the opposite direction from where the depressed switch is situated. The input from the front bumpers is suppressed when carrying the puck, since otherwise the behavior will interpret the puck as an obstacle. More important is the reflex detector inputs, used to avoid running into the goal zones. If any of the reflex detectors indicates that the surface is black, and the IR sensors give a strong goal signal reading, the behavior assumes that the robot is in a goal zone, be it offensive or defensive, and therefore gives a strong wish to go in the reverse direction.
¢ behavior_random() - produces a small random wish, in order to avoid livelocks. This wish is small enough not to disturb the other behaviors' wishes, but sufficient enough to generate a movement if all the other behaviors' wishes were to sum up to zero.
