Artificial Intelligence Planning and Decision Making NXT robots co-operating in problem solving authors: Lior Russo, Nir Schwartz, Yakov Levy
Introduction: On today s reality the subject of artificial intelligence and machine decision making is being researched by many institutions across the world. in that research process there is use of robotics. In this project we will deal with the subject of robotics.robotics is the branch of technology that deals with the design, construction, operation and application of robots and computer systems for their control, sensory feedback, and information processing. Taking under consideration that robots help our lives every day, we would like to examine the ability to combine robots abilities to a bigger decision maker planner which will be able to operate all of the robots tasks in a synced, logical based manner. The work will be based on the Lego Mindstorms NXT robots. Lego Mindstorms NXT is a programmable robotics kit released by Lego in late July 2006. There are a few programing possibilities to work with Lego Mindstorms NXT for example NXT-G, C# with Microsoft Robotics Developer Studio, BricxCC, lejos NXJ etc. In our project we will work with the lejos NXJ. lejos NXJ is a high level open source language based on Java that uses custom firmware developed by the lejos team.
Motivation: Show that 3 individual robots with different abilities can work together to achieve a certain goal. Each robot has a different ability, all the robots must cooperate. The robots have only simple logic, they can perform only simple tasks as: Move Forward Rotate left/right Activate a sensor The actual logic is in a main server, the server communicates with all robots via Bluetooth. The server is the brain. The server knows at every single moment the state of the world: Where every robot is located The direction of every robot. Saves information that was discovered in the past, according to this information it decides what to do next, in other words: it decides which command has to be sent to each robot. Concrete Goal: Solve a maze. The maze contains: Free paths Free paths are tiles that the robots can go through Wall A permanent obstacle, The robots can t go through, this obstacle can t be removed. Balloon An obstacle. This type of obstacle can be removed.
Platform: Hardware: Mindstorm NXT Robots Communication: Bluetooth Software: Lejos framework for java: Lejos is a framework for java for working with NXT-Robots. The Lejos framework support communication with only 1 robot, we had to modify and recompile it to support multi-robot communication. The lejos framework can be downloaded from here: http://lejos.sourceforge.net/ Robots Abilities Alice Vision Ability, Alice uses the NXT Ultra Sonic sensor, with this sensor she can tell whether a tile is a free tile or an obstacle. She can t classify whether it s a balloon or a wall. Bob Color Identification, Bob can tell the color of an object. With this information our planner can classify obstacles to balloons or walls. Black color for a wall and red for a balloon. Colin Popping motor. With this special motor colin can pop balloons. World Modulation Our world is module into a 8x8 board. Every tile can be: Unknown Is a tile that have not been explored yet Free Paths Wall Balloon In addition, every robot contains a location and direction. The direction can be one of the following: Up, Down, Left or Right
Algorithm: States: Initial State Initial state is the state that we start our run from. In other words our planner will start solving the maze from this point. Goal State is a state of a run that satisfies the goal State Space World module: we would like to module the real world into the program. therefore we ve created a a world state that is known by the Planner and a GUIModule which shows in which tile each robot stands and to what direction it face. the Planner is aware of the state of the world and reflects it to the GUI, in order for the Planner to be aware of the state of the world we had to overcome a few problems encountered due to the gap between the world with physical limitation to the world described by the desirable world of accurate actions.. problems: solutions: 1. The robots doesn t move straight when moving forward. 2. The robots doesn t turn in the exact angle requested in the task. 3. The sensors of the robots will work in certain range only.
The main solution to all of our problems was to mark each tile frame with black stripes. using the light sensors localized in front of each robot before the front wheels. the sensors will be apart of the moving and turning tasks of the robots. In each task the robots will align to the black stripe and by that will make sure they are located in the front end of the tile. This alignment will lead to straightening the robots to the direction of the next movement to perform and also will make sure the front color, ultrasonic sensors and pin motor will be close enough to the tile in front of the robot and will be able to perform the acquired task accurately enough to give the expected results. Tasks Our server can send tasks to our robots via Bluetooth, the tasks are one of the following: Move forward task o Pre Condition: The robot is not a in front of an obstacle, edge or unknown tile o Post Condition: The robot location will be changed according to his direction Rotate task o Pre Condition: None. o Post Condition: The robot direction will be changed. Vision Task o Pre Condition: The robot has Ultra Sonic Sensor, the robot is standing in front of unknown tile o Post condition: If the tile in front of the robot is an obstacle then the tile will be marked as unknown obstacle If the tile in front of the robot is a free tile then the tile will be marked as free Color identification Task o Pre Condition: The robot has a color sensor, the robot is standing in front of unknown obstacle o Post Condition: If the color sensor returns Black color the in front of the robot will be marked as a wall If the color sensor returns Red color the in front of the robot will be marked as a balloon Pop a balloon Task o Pre Condition: The robot has a pin motor and he is standing in front of a balloon o Post Condition: The tile in front of the robot changed from Balloon tile to Free tile Waiting Task (Tells the robot to rest for 0.5 second) o Pre condition: None. o Post Condition: None.
Algorithm - Planner Our server contains the world modulation as we described above. The server has an algorithm that decides which task to send to which robot at every moment, this algorithm is called Planner. At the beginning our planner gives the robots tasks in order to explore the world. For example, it will give Alice move tasks and vision tasks in order to explore every unknown tile. The planner will explore the world with the Right hand method : The planner will send Bob To unknown obstacle tiles and then gives him Color Identification task, this is in order to determine if the tile is a wall or a balloon. The planner will send Colin to Balloon tiles and then gives him Pop a balloon task, this is in order to clear the obstacle. If a part of the maze is totally explored, then the planner won t send robots to this part (Exploitation) Source Code Lejos http://lejos.sourceforge.net/ lejos is a Java based replacement firmware for the Lego Mindstorms. We implemented our Maze Solver in java, we used the lejos library. Lejos library doesn t support more than 1 robot- Lejos sends instruction to the lego inner framework via NXTCommand class. The problem is that this class is a singletone, in lots of lejos classes we can find this line: private static final NXTCommand nxtcommand = NXTCommandConnector.getSingletonOpen(); In our case it won t work, we need multiple robots, hence, we need multiple NXTCommand instances. We changed the lejos library, we changed the NXTCommand declaration to: private NXTCommand nxtcommand = null; Every class that needs the NXTCommand, has it own NXTCommand, and we pass to him the NXTCommand in the constructor.
Classes Logic hanadling classes MasterMind - this is the main class. Here the main function is found. This class make all the process going on. At the beginning it initialize the: - Robots classes - World State - The planner. Every time a robot finish a task, The master mind is notified (Master mind implements the TaskListener interface), He asks from the planner for the next task for the specific robot and gives the robot that task, All of this is done in the function: taskfinished Planner - this is the Brain of the MazeSolver. The planner contains the gettaskforrobot this function is called every time a robot finishes his task and asks for his next task. The planner contains the world state. according to the WorldState and the robot abilities it decides which task to give him. Eventually the gettaskforrobot returns a Task class Task classes Task Task is an abstract class. A task represents a simple task like going forward, rotating and so on. Task should contain only technique implementations, not the logic. All Task in our project should inherit from this class. Every task contains the Robot associated to the task. public void updateworldstatepreaction(robot robot, WorldState state) This function is called before the task is executed public abstract void updateworldstateafteraction(robot robot, WorldState state) This function is called after the task is executed. The following classes inherit from Task: MoveTask Contains a direction and speed. For simplicity we have only 3 options: rotate left, rotate right and move forward. After every move Task we correct the robot direction by moving it until he meets the black line. 90% of the way we move with high speed, than we go on with a much lower speed until we meet the black line, for that we wrote the moveuntilmeetblackline function. updateworldstatepreaction Before we start to move we logically lock the tile we are attempting to move. updateworldstateafteraction - After we finish the move, we logically unlock the previous tile location. ExplodeTask Explode ballon task. When executed the robots will pin anything in front of him. updateworldstateafteraction We will mark the tile in front of the robot as unknow. We don t mark it as Free tile because first we want to check the balloon explosion succeeded. VisionTask Check if the Tile in front of the robot is free or not. updateworldstateafteraction if The tile is free then we marked the tile in front as free. Otherwise we marked it as unknown onstacle WaitingTask The robot waits 0.5 second. This task is given by the planner when there is nothing to give the robot at the moment. ColorTask This task is given to identify obstacle.
updateworldstateafteraction If red color returned, we mark the tile in front as a balloon obstacle, else we mark the tile in front as a wall obstacle World state classes (World modulation) Robot - The Robot class represents a robots. The robot class contains a RobotState class, A Task class (m_currenttask) and RobotState - The robot state class contains the state of the robot: The robot location, robot angle. It also contains boolean that indicated the robots abilities: HasUltraSonicSensor,HasFrontColorSensor,HasPinMotor WorldState- the world state class contains the modulation of the world. It contains 2 demotions array of Tiles Tile - tile represents a tile on the board. A tile contains the following members tiletype - which can be: unknown, free, wall, checkedwall or redballoned. (wall in other word is unknow obstacle ). RobotState - the robot that is inside the tile. Null means that the tile is empty LockedByRobot - The tile is locked by this robot. If null, that mean that nobody is locking this tile. LockedByRobot is different than RobotState, The robot doesn t need to be inside the tile inorder to lock it, for example if a robot moves from tile x to tile y, in the moment he starts his move he locks tile y. GUI classes GUIModule - the GUIModule responsible for showing us a graphical view of the world state, the GUIModule contains a 2 demotions array of BoardTileLayout. BoardTileLayout - responsible for showing a graphical view of signle tile