• This diagram show the light sensors in blue, motors as brown and the wires connecting them as red. The effect is that when a light sensor is stimulated, it drives the motor that is connected to it. The end resulting motion is that when light input is the same for both sensors, the robot travels in a straight line.
• If the input is closer to the left sensor than to the right sensor, the right motor will drive faster than the left motor. The resulting motion is that the robot will turn toward the light.
• This image is a logical diagram of how a Braitenberg vehicle could be built. Modelled in this diagram is Vehicle Two which is intended to demonstrate the behavior of Aggression (as the robot will relentlessly pursue the light until it eventually bumps into it).

The robot was designed and programmed to exhibit characteristics from three of Braitenberg's vehicles:

• Vehicle Five - Memory and Logic. The robot has a software "latch" that triggers whenever the robot encounters an object that is not a threat. The object counter stops the program after five objects that are not threats have been found.
  • Memory is also used to assist the robot "learning" which evasive action has resulted in better threat avoidance. This is used to weight the odds of which direction to turn during evasion.
• Vehicle Seven - Concepts and Generalization. The robot accepts being around objects that are not considered threats, but when an object is a threat, an association is formed between the two that causes all objects to be interpreted as being threats.
• Vehicle Eight - Vision. Two Proximity Sensors are programmed in an array to provide a sense of an object's position and direction of travel (if it is moving).

Although this model is relatively small, it carries some interesting design principles:

• A differential connected to both sides of the drivetrain acts like a difference calculator, allowing the robot to detect when the robot has drifted off course. To accomplish this, one side of the differential is reversed and the housing of the differential is connected to a rotation sensor. If the rotation sensor detects motion when the robot should be going straight, the software compensates to bring the robot back on course.
• Belts are used instead of gears. This helps reduce the mechanical complexity of the robot and also makes the 'Direction Sensor' (above) easier to build by allowing one side of the drivetrain input to be reversed by simply putting a twist in one of the belts.
• "Sensor stacking" is a technique that connects more than one input sensor to a single input. When programmed correctly, the inputs can be read without interfering with each other. On this model, a total of five sensors are connected but use only three inputs.
• The Java 'Proximity Sensor' class is used on both light sensors. Through clever programming, both light sensors are monitored to provide data on the presence of an object, whether it is moving, and whether it is travelling from left-to-right or right-to-left.

• In this experiment, a threat is considered to be a very bright light. The robot's goal is to encounter objects that are not threats. When an object is encounter, the robot will evaluate if it is a threat. If the object is not a threat, the robot will add the discovery to its count of objects, change its course, and then continue in a straight line until it encounters another object.
• If a threat is encountered in the form of a bright light (but not the light source itself), the robot begins an evasive manouver by reversing, adjusting its course significantly while sounding an alarm, and then resumes its straight-line search.
• In order to try and get better at evading threats, the robot begins by alternating evasive actions left and then right, keeping track of which direction is more successful. This success rate is used to weight the odds of which direction the robot will choose to turn during its evasive action.
• If the robot encounters an object that is also a threat, then an association is made which states that an object can be a threat. The robot reverses its direction and attempts to avoid turn away from the location of the threat. Since this association is persistent, the robot will continue to associate non-threat objects as being a threat. In accordance with Braitenberg's models, this association "wears off" after some time.
• The end result is a robot that wanders around, stopping at objects and observing them for some time before moving on to the next object. When the robot encounters a threat, it tries to avoid it. When an object is also a threat the robot makes an assocation that causes it to avoid all objects, threatening or not. Once the association wears off, objects will again be regarded as non-threats.
• A red light on the robot illuminates to indicated is being threatened, a siren goes off and the robot makes evasive maneouvers to avoid further contact with the threat.

Click here for the handout that was provided to observers during the demonstration of this robot (PDF).

Click here for the report that was submitted with this assignment (PDF).

Tricycle Steering Platform with Liftarm

This model is currently being used as a testing platform for fuzzy logic navigation. The goal of this experiment is to ascertain the applicability of fuzzy logic in steering systems. The results of the experiment will be used for this robot's next role in the Web-controlled Robot application.

Features of this robot:

• Locomotion is attained by driving the two main wheels with a single motor through a bevel-gear differential.
• Equipped with a single-motor lift-arm, this robot will be able to pick up objects and re-locate them. The clever lift-arm design is adapted from Ben Williamson's "FetchBot". Thank you to Ben for his assistance with this design.
• A "Dual IR Proximity Detector" is used to find objects to pick up. This device, from Techno-Stuff Robotics, detects when an object is to the left, the right or directly in front of the robot.
• A rotation sensor is connected to the motor that drives the steering fork at the rear of the robot. This allows the use of the Java "Servo" class to achieve a high degree of accuracy for steering control.

Liftarm Lego Robot Seen from the front, with the liftarm in its fully up position. The Proximity Sensor is visible in the front, near the bottow. The Lego Brick is facing rearwards to accept commands from Internet users via the IR transceiver.
Liftarm Test This short video is testing the robot's liftarm.

Differential Drive Robot

Outwardly, this is a typical differential drive robot (left side and right side driven independently, using differences in wheel speed to control turning). On the inside, however, its quite unique: even though wheels are at the front of the robot, the motors are both at the very rear. This gives the robot better weight distribution but also allow two touch sensors to be mounted inboard to monitor the speed of the axles.

By monitoring axle speeds, the robot can sense when it has deviated from going straight and can then compensate by slowing down one motor or the other. A very similar concept to this is used with the "Direction Sensor", programmed for the Braitenberg project.

Short, but tough This robot was made to be quite robust (as robust as Lego can be) by using beams and arms to reinforce construction. Internally, motors mounted at the rear and drive a worm gear and axle up to the front wheels. Each axle has a coupler on it with irregularities which hit the touch sensor twice per axle revolution. This slideshow has three images.
Popping the hood This image shows the two internal touch sensors that monitor the speed of the drive axles. For those not familiar with Lego robots, the touch sensors are located near the bottom left and bottom right of this picture and are immediately beside the two blue axles. In testing, this system worked very well. However, it made quite a racket when it ran.

Tricycle Steering Platform Prototype

Much longer than the current version of this robot (above), this robot was made to test some building and motor/sensor implementation designs. In many ways, it is the same as the final version with the exception of being longer, taller, less stable, heavier and doesn't have a rotation sensor on the steering.

Instead, a touch sensor is used to detect when the steering arm is set to dead center (vehicle going straight). The major problem with this is that there is no way to tell exactly how much the steering arm has turned - only through timing can any level accuracy be attained.

SensorMUX.java

The robotics accessories experts from Mindsensors have developed many ways to extend the power of Lego robots. One of their simple yet innovative devices is the Sensor Multiplexor, which allows multiple touch sensors to share the same input.

This Java class for Lego robots is designed to support the 3-into-1 Passive Multiplexor. Normally, a touch sensor is a boolean, or binary, device. What the multiplexor does is convert the three boolean values into eight different values.

By monitoring the sensor value in software, thresholds can be sensed that allow any combination of the three inputs to be detected. In order to get the most accurate values, a small program can be executed to read the values for all eight possible combinations. This class has already been 'calibrated' to my particular multiplexor but would likely work for all of them as their tolerances are quite good. Note: I apologize for the following listing to be in this format - I've used HTML's <PRE> </PRE> (preformatted text) tag but due to the many ">" and "<" signs used in this code, the listing is unreadable when enclosed as preformatted text.

/*________________________________________________________________________
SensorMUX.java
Version 1.0
Chad Therrien, I-Circuit Engineering
LEGO Mindstorms RCX 2.0
Class for MindSensor passive 3 port MUX for boolean operation
Revision Notes:
1.0 - First version. RANGE array needs to be calibrated to the
specific values desired. The method getRawValue() will return
the values to use (they are slightly different for each individual
multiplexor board, due to tolerance differences in the resistors
used to generate the readings).
Note: Default values have been tested on multiple boards and may work
without modification, as the class allows ranges to be used).
________________________________________________________________________*/
import josx.platform.rcx.*;
import josx.robotics.*;

public class SensorMUX
{
private Sensor muxSensor;
private int reading;
private final int [][] RANGE = {
{1000,1023},
{340,375},
{605,640},
{281,294},
{761,794},
{305,334},
{503,545},
{248,276}};

public SensorMUX()
{
this.muxSensor = Sensor.S1;
reading = 0;
}

public SensorMUX(Sensor muxSensor)
{
this.muxSensor = muxSensor;
reading = 0;
}

public void activate()
{

}

public void passivate()
{

}

public boolean S1()
{
reading=muxSensor.readRawValue();
reading+=muxSensor.readRawValue();
reading+=muxSensor.readRawValue();
reading = reading / 3;
if((reading>RANGE[4][0] && reading<RANGE[4][1])||
(reading>RANGE[5][0] && reading<RANGE[5][1])||
(reading>RANGE[6][0] && reading<RANGE[6][1])||
(reading>RANGE[7][0] && reading<RANGE[7][1]))
return true;
else return false;
}

public boolean S2()
{
reading=muxSensor.readRawValue();
reading+=muxSensor.readRawValue();
reading+=muxSensor.readRawValue();
reading = reading / 3;
if((reading>RANGE[2][0] && reading<RANGE[2][1])||
(reading>RANGE[3][0] && reading<RANGE[3][1])||
(reading>RANGE[6][0] && reading<RANGE[6][1])||
(reading>RANGE[7][0] && reading<RANGE[7][1]))
return true;
else return false;
}

public boolean S3()
{
reading=muxSensor.readRawValue();
reading+=muxSensor.readRawValue();
reading+=muxSensor.readRawValue();
reading = reading / 3;
if((reading>RANGE[1][0] && reading<RANGE[1][1])||
(reading>RANGE[3][0] && reading<RANGE[3][1])||
(reading>RANGE[5][0] && reading<RANGE[5][1])||
(reading>RANGE[7][0] && reading<RANGE[7][1]))
return true;
else return false;
}

public int getRawValue()
{
reading=muxSensor.readRawValue();
return reading;
}
}

Proxsens.Java

This class is used in the Braitenberg project (above) for the purpose of giving the robot an idea of where an object is and if it is moving (and in what direction it is moving). The purpose of the class is to monitor the proximity sensor and return a value which states there is either no object near the sensor, an object near the sensor, or that there was an object near the sensor.

This class has been modified from the original demonstration, which also incorporated the Mnemtrix class, Mtrix.java, which has not been posted here pending further testing.

/*________________________________________________________________________
	ProxSens.java
	Thread that instantiates the Proximity Sensor class.  Two of these
	are instantiated in ProxLight to form the object sensor array
  ________________________________________________________________________*/ 
import josx.platform.rcx.*;
import josx.robotics.*;

public class ProxSens extends Thread
{
	private ProximitySensor p;
	private boolean proxFlag;
	private int rescount = 0;
	public ProxSens(Sensor inSensor)
	{
		p = new ProximitySensor(inSensor);
		proxFlag = false;
	}
	public ProxSens(Sensor inSensor,int thresh)
	{
		p = new ProximitySensor(inSensor,thresh);
		proxFlag = false;
	}
	
	public int proxWarn()
	{
		//1 = resid; 2 = prox
		if(proxFlag)
		{
			proxFlag=false;
			rescount=10;
			return 2;
		}
		else if(rescount>0)
		{
			rescount--;
			return 1;
		}
		else
		{
			return 3;
		}
	}

	public void run()
	{
		while(true)
		{
			try{p.waitTillNear(0);} catch (Exception e) {}
			proxFlag=true;
		}
	}
}

Sumo for Robots

This robot was built from a kit and was used in a competition of Sumo 'bots at Thompson Rivers University. It uses a fairly simple microcontroller that is not as complex as the Lego system but still can be programmed. There is no Java Virtual Machine for this device as it is not powerful enough, so programming was done in C.

Programming principles learned during the Braitenberg project helped program this robot to do some interesting things like using stationary rotations to "scan" for the other Sumo 'bot.

The competition was pretty short for this project as it was eliminated in the first round, but at least it won the first heat! The future for this robot is uncertain, but some ideas are being considered.

This slideshow has two images.