GASTON JOURNAL 2

last update 17/03/2003

HELLO WORLD !

Gaston's birth weight: 1.895kg

The IR-LED which sends the information from the ears-system to both RCXs.

The non-LEGO switch with a red LED inside of a brick to switch on and off the ears.

Ben and Scharel while programming the motor-control part for the mobile base...

... collecting some data about the base, the sense of rotations of the motors, the sign of the rotation-sensor values and the conversion to degrees.

With that program, GASTON horizontally turns its head towards the noise-source. The motor-control part slows down the motor-power when the deviation from the target-angle (=HEADING) gets small. This prevents the head from overshooting. Note that there is a new EARS-protocole:

1. the sensor first sends three RCX-messages 100
2. then it sends the time information RTL (right, top, left), e.g. it remotely sets variables 0,1,2 (red, blue, yellow) of both RCXs
3. the transmission is concluded with an RCX-message 101

A comparative test with and without motor-power control. Without there is a slight jiggling around the target-angle.

Luc and Max are reflecting about the tasks which will control the face.

There will be 7 tasks accessing the face. To prevent access-conflicts the programming will be done with the subsumption architecture.

The face will be controlled from the REAR-RCX. As pointed out, variables 0, 1, 2 (red, blue, yellow) are lost on both RCXs because of the EARS-protocole. The face-driver programs use variables 4 to 7.

GASTON is supposed to adjust its mood in function of the ambient light level.

A pause or stand-by modus will be active, if there is no stimulus anymore. After a while however, GASTON becomes hyperactive, it starts singing and dancing to attract attention. Any noise will make it happy. But rapid consecutive noises will drive it crazy.

We'll have 

1. temporary arbitrate-mouth-variable  (local var 47)
2. temporary arbitrate-eyebrows-variable (local var 46)

and

1. arbitrate-mouth-variable (global var 7), which infact  is the mouth's HEADING
2. arbitrate-eyebrows-variable (global var 6), e.g. the eyebrows' HEADING

The subsumption-procedure will operate:

if var 21<> none then var 47 := var 21

if var 19<> none then var 47 := var 19

if var 17<> none then var 47 := var 17

...

if var 9 <> none then var 47 := var 9

var 7 = var 47 (now var 7 holds the highest priority mouth HEADING-value without ambiguity ==> NO CONFLICT).

Do the same for the eyebrows values.

Some measured sensor-values: (depend on the initial potentiometer positions)

6/2/2003

The vertical neck driver is now working too. Both neck programs run on different RCXs.

Note that variable User3 normally will be used in BACK-RCX to store the CdS-sensor value. For this test we allowed its use here.

Click to see the short video (410kB).

PORT MANAGEMENT: 

14/2/2003  (colour changed the 28/2/03 (dark grey --> red); extreme values of neck horizontal sensor changed as well)

Some additional information about the motor-sensor couples:

Ben and Scharel finished the base drive controller:

Variable 3 holds the base heading. If the course deviation exceeds +180° (137rotations) the base has to turn to the left rather than to the right. In this case we substract 360°. Ex: d = 200° --> d' = 200-360 = -160. The turning angle to the left is smaller than the one to the right.

We now want GASTON to move its body towards the direction of its head and bring the head to zero position in the case of no response from the EARS-sensor. Therefore we always zero a timer, we loop as long as the IR-mail is different from the EARS complete-message 101. If the timer value exceed 100 (10 seconds) the HEAD-bearing is read, then transformed to base rotations through the formula:

base_rot += (head_rot - 57) * 75 / 48

Note that the mail-loop is not existing in standard ROBOLAB. We added it to the library.

Now we implement these sub.vis in a new test-program. Note that Variable 30 replaces the former Variable 3 (user3). The RCX sound-ressource is accessed via variable. In fact the RCX continuously whistles different tunes, but we control the ressource by muting or unmuting.

Another change is the new mouth-control, which is quicker than the former:

Max is taking notes. He and Luc work at the organization of the task-management.

List of NON-LEGO pieces or LEGO-violations

Mike Gasperi's multiplexer and sound sensor electronics
2 potentiometers (enlarged holes of a bracket and a 1x4 Technic brick with holes) The potentiometer-shafts have to be filed a bit to fit into the gears and bush.
CdS-sensor (cut a 1x4 plate
9V Battery
IR-LED in 1x4 Technic brick with holes (enlarged one hole)
Sound-sensor-switch placed inside of a 2x4 brick
Thin plastic disc added to Gear16 Neck-horizontal to prevent blocage. Shortened axle 8 to dimension 7 in neck mechanics.
The same plastic disc is added to the rotation-sensor block of the neck mechanics.
Left and right microphones glued to LEGO ears
Top microphone fixed to the top of GASTON's middle single hair, which is a LEGO ribbed tube.
Technic 12 Gear Bevel glued to short axle in neck vertical mechanics.
Cut LEGO ribbed tube which forms the mouth and add rests to the extrema.
This part allows access to the sound-sensor sensitivity regulator, a potentiometer which is soldered to the PCboard.
Some wires are fixed together

28/2/2003

Luc and Max are taking photo-shots for the future GASTON user guide, especially to explain the battery exchange procedure.

There is a discussion how to program GASTON's reaction on temperature. The group chooses the option that GASTON should start smiling at a temperature increase greater than 2°/ 20 sec and return to facial mood-expression when the decrease is at a rate larger than 1°/20 sec. Any changes between those limits will not affect GASTON. This approach allows an interesting introduction to the mathematical concept of the derivate.

This test-program works fine, but the reaction is a bit too slow. (CLICK = decrease; BEEPBEEP = increase) Unfortunately there is a loss of the fractional digits, when the temperature-values are stored into a container. To reduce the clock-rate here, requires a further decimal digit. The program has to be altered to compute itself the conversion from sensor-raw data to °C. Mike Gasperi gives the formula:

T [°C] = (785 - RAW) / 8

our tests don't gave the same result:

T= -20°C, RAW = 1023

T= 20.5°C, RAW = 607

==> T [°C] = (817,6 - RAW) / 10.27, 

and adjusted: T [1/10 °C] = (818 - RAW)

Thus, we can easily work with the raw-value directly, since we are not interested in the absolute temperature value, but rather in differences. We only have to put attention to the sign : if the raw value increases, the temperature actually decreases and vice-sersa.

This program provides a very quick reaction, if someone touches the temperature sensor. At a release, the measured temperature decreases slowly, but rapid enough to be distinguished from ambient temperature changes. With datalogging and some basic mathematical transformation we get:

The Front RCX will now be programmed accordingly. If the program registers any serious temperature increase a message (51) will be sent to the Rear RCX. The program on that RCX will change the facial-variables via subsumption. Now GASTON smiles. At a decrease, message (53) will be sent. The access to the face motors returns to the mood-task.

07/03/2003

Ben and Max while testing the base.

Today the work turned around adjusting the parameters for the temperature-program part. A similar program has been developped for the hand-lightsensor. Rapid changes of the light-intensity should produce a robot-reaction. Imagine GASTON occupied in a random-walk. A rapid change of lightsensor-values would advice him to stop, thinking he has met an object or a wall. This part still has to be well parametrized.

A third task was to program the DANCE AND SING -function in the case of absence of stimuli. A first radical solution was to select another program slot on FRONT-RCX, run this program, which would cause immediate stop of all the running tasks in the actual slot. The new program would have two tasks, the first to control the base for some dancing, the second to output a tune. After this choreographic program the RCX would select the old slot and start the main program.

Unfortunately this radical running and stopping programs caused the RCX to crash !! We even were unable to reboot the RCX correctly. Installing the firmware was no more possible. We had sort the batteries, press On/Off. Now we could re-use the RCX. This was not what we expected. So we had to change the point of view. Through a subsumption architectural approach we were able to implement the new feature into the more and more complex FRONT-RCX program. We introduced a control-variable called "DANCE_AND_SING_FLAG" =(variable USER17), which is continuously checked for its values. Only if its zero, the base-controller is allowed to adjust the robots base-position. At value 1, the robot starts singing and dancing. The flag is set if there is a timer-overflow, e.a. the robot did not get any message from the sound sensor. Remind that the intelligent noise-sensor first sends RCX-message 100, then remotely fills variables 0,1 and 2 (red, blue, yellow) with the sound precedence values, finally closes the communication by sending RCX-message 101. So, if there is no message 101 during a certain period (10sec) the base is ordered to turn towards the horizontal head-angle while resetting the horizontal head-angle to zero. This looks like the robot turns towards the position where it got the last sound signal. After 20 seconds (this will perhaps be increased), the robot starts singing and dancing. Once ready, the timer is reset and the procedure starts from scratch.

Note that the Path to My Data is found in the ..\Robolab\Engine\Vi.lib\Explorer\Code\Support vis.llb\Explorer Globals.vi. Note also that Robolab versions before 2.5.2bis don't accept an external path here.

The robot operates a square-dance. Note that here could be added some random to choose other movements. This is a suggestion for GASTON power-users.

All this leads to a global FRONT-RCX program which is already close to the final program. Note that some hardware-changes at the horizontal neck mechanism give us a new midth-position 42 and extreme values 4 resp. 80. We should perhaps global wire this value anywhere it appears. So if any other changes appear, we need only to change the value once.

Last programming work to be done:

• set IR-range to short on both RCXs
• disable auto-power-off
• add mulfunction checks and error codes
• Sending messages should only be done, if different to the old message AND if the noise-sensor didn't recently send message 100 !
• program a reaction for the hand-sensor-changes
• add a pause before dancing, the program might have stopped the motors in the base-control

Luc took some beautiful detail shots for the GASTON USER-GUIDE. Here some examples:

The chest CdS-sensor

Give hands

extreme left horizontal neck position

17/03/03

This finishes these journal-pages about a long and intensive Mindstorms-project. GASTON is ready for use now. There still remains some work to assemble the User Guide.

Main Page