Date: 08 01 2009
Duration of activity: 3 hours + (about 2-3 hours for homework)
Group members participating: Anders D., Renata + (all group members for homework)
1. The Goal
The goal of this lab session is to start to actually write code in order to implement the layers that were identified in the last lab session.
2. The Plan
- Test how
MotorLayermethods work on the robot.
- Test how
CalibrationLayermethods work on the robot.
3. The Results
3.1. Motor layer
setSpeed(MotorPort motor, int speed)assigns a speed value to a particular motor. If the speed is positive---motors go forward (i.e. towards higher coordinates); if the speed is negative---backward. The method is not complicated therefore works pretty straightforward.
getTachoCount(MotorPort motor)gets a tacho count value of some particular motor/axis.
getCurTachos()gets the last seen tacho values of the three motors.
MotorSpeed()is a class constructor. Safety break---triggered when one of the corner buttons is pressed---will turn of all motors, and
setSpeedhas the responsibility only to start the motors again, if they are going in the right direction.
This is the lowermost layer. Basically the two basic responsibilities are: Count tachos and set speeds to the motors. Tacho values are returned either for a particular motor or for all motors at once. The idea with the safety buttons is that whenever any of those are touched, motors have to stop. Under normal circumstances, these buttons have to be touched during calibration time; if the sensors are touched in other circumstances, something must have gone wrong. Thus, the sensors delimit the working area of the robot.
3.2. Calibration layer
getCoordinate(MotorPort motor)returns the current coordinate (in millimetres) for the given motor.
setSpeed(MotorPort motor, int speed)sets the motor speed of the given motor. The speed is in the interval [-100;100]. Zero means stop-and-brake; as opposed to stop-and-float.
reCalibrate()starts an interactive re-calibration of the axes. While the calibration is running, the coordinate progress is hidden from the interfacing layers:
getCoordinate()returns cached results, and setSpeed does nothing.
reZero()clears and re-sets the values of min and max tacho count.
This is a layer on top of the motor layer. So far, it can ``get'' coordinates of where the motors are, re-set tacho counts and run calibration. At least this is what this layer suppose to do. These methods still lack testing, therefore, more precise conclusions will be made along the way. The primary responsibility of the layer, when seen from above layers, is to handle the tacho-to-millimeter conversion (and indeed, the layer's implementation underwent a conversion to do floating-point arithmetic in order to conserve precision of the floating-point millimeter values.)
There were some issues to be resolved with the days work:
When uploading our first draft of the source code, the NXT brick kept on throwing an exception, making us reach for the battery pack. We kept on commenting parts of the source out, in the end deducing that the method
public double getCoordinate(MotorPort motor)was the one causing problems. As it turns out, lejos doesn't support double, and is encouraging the use of floats instead. We had similar problems when trying to use the method
static long currentTimeMillis()on
java.lang.System. The return-type was
long, but doing arithmetic on a
longwould make the brick throw exceptions.
For developing reasons, the interface was changed to use
int, because we knew this was supported. But making a note that the return type should be something with more precision.
When using a touch sensor, it makes sense to use
isPressed(), because one expects a binary answer. The touch sensors (at least the RCX-style ones) do not return a binary answer, but a number in some interval. This phenomenon we know is controllable, but for now, we don't investigate it further.
Today's work was the first attempt to make the robot do something according to the written software methods. It took some time to test and to pick out all the mistakes so the simple methods from the motor layer would work. For this moment, the calibration layer does only ``something'' by being able to move all three platforms at once (which, we might add, has its own sort of charm to it). To make things work properly, more adjustments will be needed in this layer.
The MotorLayer also needs to implement a way to handle touch sensor events.