Progress Details

The team has been working individually and has just started to combine their various aspects of the project.

Ted

Week 9

• Finalized and standardize design of slaves
• Completed program for slaves

Week 8

• Built remote control interface for evaluation of localization code
• Constructed prototype retrieval program
• Built a prototype goal grabber

Week 7

• Perfected handyboard/RCX control interface

The principle focus of my portion of the project is the interaction between the 'master' and 'slave' robots. This entails several things: The slave robot programming is first on my list of priorities, because while other members of the team are working on more important parts of the project, I know that the slaves are vital to the success of the project as described, and I don't want them to be forgotten. Programming is always subject to Murphy's Law (that is, anything that can go wrong, will go wrong), and if everything else works I know we wouldn't want the project to tank because the slaves don't work. Included in the slave programming is their calibration, which changes with nearly every structural change to the master robots. Incidentally, the chassis construction for the masters and all construction of the slaves is also within my sphere of responsibility.

The other main aspect of my portion is the master-slave communication. Once again, I refuse to let the slaves fall by the wayside, and so I constantly need to keep them in communication, both with the masters and with my teammates. The LEGO RCX system has a very powerful infrared emitter/lens configuration, which is both a blessing and a curse. I concern myself with things like handshake protocol and blind signal seeking as part of this work. Also, I am working on communication between our mobile brain power, the Handy Board, and the RCX, which may be wired or IR, depending on which system we can get to work.

Rich

Week 9

This week I worked on reconfiguring the HB to use the wireless card instead of the camera in order to begin testing our communications software. I also wrote new code that accessed Ted’s movement program on the RCX box that will manage movement now so that a slave can follow the Master, instead of the original routine the HB used. Work progresses on the drivers for the SPI UART but I’ve hit some snags regarding how to write to the UART’s programmable register to configure it.

Week 8

• Researched SBI port programming
• Reasearched data sheets for MAX3110E UART
• Began configuring registers on UART
• Began analysis of handyboard IR port

Week 7

• Continued improving sonar circuitry
• Sensor circuitry is moved from the breadboard to a PCB. Soldered down, the circuit is compact, reliable and can be carried on the robot, allowing for free movement
• Further testing shows that the Sonar has a large blindspot on the emitter side of the module, leading to reduced tracking on the right side of the robot. Tracking within the arena is poor at angles greater than 45 degrees. It seems that the sonar is being reflected too well off our wall surface and not returning a consistent reading.
• Program is written and tested in the arena to change the cycle of tracking. Instead of moving and accessing the camera everytime, now the camera will only be accessed after the Sonar determines an object is in front of the robot. This reduces the amount times the camera is accessed and improves battery life significantly. The risk is that the sonar hasn’t proven to be consistent and placing a higher priority on the Sonar may cause the robot to miss the target more. However, tests are positive and the robot actually shows more reliability in finding the target.
• Researched possible solutions to the lack of I/O options
• Found the MAX3110E, a UART with an SPI interface and built-in RS232 voltage level shifting. This way the HB can have another Serial I/O that won’t require the Wireless cards to be modified.
• Determined what variables needed to be returned by both the Host PC and the HB
• It was decided that in order for localization and pathfinding algorithms to work, we must know which direction the robot is facing. The simplest way to do this is to attach a digital compass. I found the Devantech CMPS03 digital compass capable of interfacing through an I2C protocol or PWM.

Week 6

• Completed LEGO Active sensor circuitry for use with the HB
• Tested this with both the Lego 9v Light Sensor and Mindsensors Sonar, tests show that the sensors are functional in a digital sense but has poor bias. This leads to the inability for the Sonar sensor to accurately determine distance. I will attempt to experiment with different pull up resistor values to find a better sensor response.

Week 5

• Finished CMUCam integration
• The CMUCam is fully wired and working. A simple program is created to store the average color value of a target placed in front of the robot during initialization and then attempt to search for that color in the arena. Program has limited success. I also wired and configured a small output port from the CMUCam to any normal television. This way we can see on a screen what the robot sees in order to aid in target design. More work is needed to adjust threshold values for our lighting conditions to improve detection.

Week 4

• Began CMUCam preparations
• Modified SCI drivers on the HB to work with the CMUCam
• Work on CMUCam is delayed because of parts inavailability

As far as what I’m doing, I’m currently getting three systems integrated and operational. The wireless communication, the CMUCam2, and the Ultrasonic distance sensor. The wireless cards are RTCom RS232-HS wireless transceivers, capable of transparent integration into any existing wired serial link.

The CMUCam2 is aSX52 microcontroller interfaced with an OV7620 CMOS camera. These can be interfaced to any master microcontroller or PC through a standard serial port. The CMUCam2 is small enough to add simple vision to embedded systems that cant afford a high size or power requirement needed by standard computer based visions systems.

The UltraSonic Prioximity Sensor or USPS by Mindsensors was designed for the LEGO Mindstorms system. Being originally designed for the Minstorms system, the sensor operates on only 2 lines, a combined power/signal line and a ground wire. The combined line needs to alternate between power and signal at millisecond periods. The Handyboard cannot handle this so an external dual transistor driver circuit must be constructed.

All these systems combine to proved the eyes, ears and brain of the Master robots of our multi robot system.

Imrul

Week 9

• Continued transporting D* to C++ and implementing with existing localization software

Week 8

• Modifying D* algorithm for integration with existing localization code

Week 7

• Got simple A* planning to work with out mapping and started working on D* coding

Currently working on research/programming path planning, mainly D* and A* algorithms. The D* algorithm is a dynamic version of the A* algorithm whose arc cost parameters can change during implementation making D* more efficient. Also looking at graph theory to find/ alter an algorithm that would most efficiently connect nodes so that the path planning code has endpoints to direct its motion in searching for the target.

Louis

Week 9

• Began adding serial communications code to existing localization software
• Drafted communications protocols

Week 8

• Modified localization software to recognize major obstacles
• Completed software to recommend headings to chief robots
• Began work on comm interface for wireless card

Week 7

• Finished modifying existing Allegro code for OpenCV
• Analyzed project goals and means and eliminated need for visual beacons
• Began code for directional recommendation

Week 6

• Continued modifying field analysis for use with OpenCV

Week 5

• Began learning to use the openCV library for computer vision
• Modified existing functions from Allegro vision program for use with openCV

Week 4

• Using Allegro, implemented basic color segmentation and identification on still images
• Failed to adapt Allegro to work with video inputs
• Began website construction

Week 3

• Implemented basic D* pathfinding
• Failed to find suitable sonar beacon system
• Began research on localization via colored target on robots with an overhead camera
• Finished basic information container

Week 2

• Began early construction of a container program for world information using the Allegro Graphics Library
• Derived and implemented functions for location based on 2 static sonar beacons within world conatiner
• Began basic research on pathfinding with emphasis on D* Search Algorithm

Week 1

• Outlined individual goals in relationship with project.
• Began preliminary research on localization

I have been focusing on the storing of environmental data and localization of robots within the system boundaries. All locations are classified in a 2D rectangular array as unknown, goal zone, or obstacle. Each of these are also given a number representing the certainty about this classification. Prior to the beginning of the experimental trials, the master computer will be given a map of all obstacles. In order to find the goal areas the computer will instruct the chief robots to look in probable locations and then report back, updating the map as the search continues. As the chief robots are capable of navigating obstacles by themselves, the master computer is only required to recommend which path to take when presented by a choice. Some preliminary work has been done with using the D* search algorithm for path planning, but this process is very computationally expensive as the localization grid increases in resolution.

In order to determine the position of each robot at any point in time, a method of localization is required. While we originally hoped to use a pair of sonar beacons that could triangulate the robot's positions, we could not locate an appropriate system. Instead, I know working on developing a system for tracking the robots via an overhead camera. Each robot will be identified by a colored circle on it's top. The origins of the system will be determined by a set of four identically colored "beacons" which the computer will locate and calculate the robot's positions relative to.