MARS MISSION III
BREAKING NEWS FROM THE SCIENCE
- Here the definite statistics of the
uploads (to local-museum)
uploads (to external)
About 1/5 of the file requests came from outside.
The external participants came from foreign countries in the majority of
the cases. Identifyable participating countries :
Australia, Belgium, Czekia, Denmark, France, Germany, Great Britain,
Spain, Switzeland, Syria, United States of America. Other particpants
could not be localized.
A single log-in assigns the robot to the remote user for 5 minutes. Thus
there has been an effective robot-
for 2650 min = 44h10', which represents a mean of 4.9 hours a day
The number of participants actively controlling the robot (530) can be
divided into 424 local users and 106 external
=(4:1). The ratio is confirmed by the different IP-addresses.
In several e-mails people from outside complained that the rover was
constantly occupied. This criticizing especially
the weekends during which the robot was run by local users nearly all the
The foreign participation only happened after the announcement in the
- Some screen-shots form Sunday Oct 30th :
- Great honor: we had the chance to talk to Mrs Mukai,
the famous Japanese astronaut ! She has admired our simulated Mars project.
- Thanks to all the sudents that helped to keep
everything running : Terence, Jacques, Jean, Yves, Thierry, Luc, Kalong,
- Some quite impressive server results from Oct 22th to
- 342 log-ins, 1 log-in = user pilots robot for 5
minutes ==> RoverX3 was directly controlled during 4.75 hours a day.
- Identifyable participating countries : Armenia,
Australia, Belgium, Czekia, Denmark, France, Germany, Great Britain,
Luxembourg, Netherlands, Poland, Spain, Switzeland, Syria, United States
of America. Other particpants could not be localized.
- 42043 individual file requests !!!
- 2177 commands were sent to the robot.
- The weekend will probably attract many people.
- The "fatal error" problem could not be fixed
- "Never change a running system!". Now, after
a few changes of RXC-Main program the grabber-arm sometimes opens, when a
new user is logged in and sends its first program. Don't know why !
- The rover touched the wall and wasn't evacuated during
a certain time. This caused Main-RCX to change to "fatal error"
state resulting in a definite stop of the main motor control task to prevent
the robot from desperately forcing a stuck position. There should be a
possibility to completely reboot the program from an administrator-command
without physically pressing the RCX run-button twice !
- Since there is nobody to shut down the rover RCXs at
the museum closure, Main-RCX looses its firmware over night. There was no
precaution against this. Cam-RCX however disposes of an auto-shut-down
mechanism, if the RCX voltage reaches 6.5V. ==> Added a similar program
module to protect the firmware.
- One part of the grabber motor stuck error may be
explained by a damaged LEGO electric connector. (The first one since 1999 !)
- We had many battery problems today, but apparently
nobody to replace the empty ones. RCX-Main fell into "low battery"
state, which reduces the number of vital robot functions. The communication
- No server incident !
- Definitely the CMUCam2 module consums too much power
- It seems that the grabber motor stuck error may appear,
if the robot is moved forward with the grabber arm open. This also means
that the grabber almost touches ground. The bumpers are very sensitive and a
"hit obstacle" event might be triggered. Now the Cam-RCX that also
controls the grabber arm tries to move the arm, but the motor does not turn,
due to mechanical forces. After a one minute try to drive the stalled motor,
the program switches to a secure mode to protect the motor and the RCX from
high current. The error may only be manually recovered. INSTRUCTION TO
OPERATORS: GRABBER MOTOR STUCK ERROR CONDITION ==> PRESS THE CAM_RCX RUN
- We have a server incident at 11h43 (GMT+1) today. The
reason was: an unauthorized person manually stopped both servers at the
museum by entering LabVIEW and opening a file dialog window without closing
it -apparently on both servers. Being in the same threads than the server
programs, all server activity has been stopped that way.
- "Bad communication" appears about every 10
minutes. After some tests, we may conclude that the reason MUST be a strong
disturbing 433MHz signal. I think the best is to ask the radio amateurs, if
they are able to localize the source. (Friends, another cup of coffee?)
- The console in the museum looks like this:
- The 8-tooth gears cause some troubles, if the robot
turns around and the wheels are exposed to extreme friction forces. Since
the arrangement of the gears is angular and not in a straight line, the
8-tooth gear might be forced out of the teeth of one of both 24-tooth gears,
depending on the direction.
- Our telemetry works over 433MHz ! After research under
sever scientific conditions :), we must review our "definite"
localization of the troubles. The radio amateur group sends on 430MHz and
436MHz. Their 10W carrier does NOT disturb our RF communication. (Hey
colleagues, our apologizes ... don't forget the coffee !) So, we still don't
know who is disturbing that powerfully on 433MHz.
- Got some visits on the site from US friends. Hey Tonya
! Great ! (After announcement on LUGNET.)
- Some problems occured on the rover's left gear train. A
3-axle with stud lost the 24-tooth gear and caused a stuck in the train
--> must replace this fixation by a better one.
- There were so many local visitors that we had no time
to change the camera parameters. Anyway, even with new batteries, the
Cam-RCX voltage drops below 6.5V after about 2 hours of operation.
This causes the Cam-RCX to switch over to a power-economy mode that only
maintains the grabber function and the communication to the Main-RCX.
- The rover produced a single grabber motor stuck error.
The reason was a loose connection after a battery exchange.
- Here some photos :
Yves, Thierry, René enjoy.
searches its reference points.
Science Festival 2005 has started. Special guest : Honda "ASIMO"
was only accessible from outside for a few moments, since so many local
visitors controlled it from a console that is placed in front of the
simulated Mars environment.
the previous test phase there was no problem with the radio communication.
But today often the web-server had to announce "Bad
communication". After several hours of searching, we definitely found
the source of the troubles. No, it wasn't any hidden bug, neither was it
hardware failure, nor RF waves from the neighbour remote robots that might
not have RF-protected motors. The origin was a powerful 70cm amateur radio
sender that is localized in the "Neumünster" building next door
at the radio amateur desk. The hams participate at the Science Festival
too... (Hi, guys !) The sender radiates a carrier to
demonstrate the propagation of electro-magnetic waves. Problem: our
telemetry data are transmitted on the ham 70cm band ! (We apologyze, guys, to
be the intruders !!! Need a discussion later!) So, everytime they
demonstrate their device, our communication breaks down.
CMUCam2 module suffers from a fundamental disadvantage : it consumes too
much power ! 200mA at 9V are far too much for a long operation time.
Consequence: the alcaline batteries from "Main-RCX" may last for 2
days, but the ones from "Cam-RCX" only have a 4 hours lifetime.
are some problems with the CMUCam2 white balance and the autogain that are
switched on all the time in the current Cam-RCX firmware. This ends in
missing the "meteorite" more often than finding it. --> We'll
try to only activate the white balance and the autogain at start. (The spots
produce reasonable light intensity.)
ROBOLAB254 camera overview program that captures the "satellite"
picture from the Mars terrain and that should add a graduation plus the
robot position data didn't work because of a missing dll (NiVision.dll).
However, everything worked fine in ROBOLAB 252.
intervention on Mars" had to happen several times, when the meteorite
fell into a bad position.
they run the rover with the grabber arm open, "hit obstacle"
messages might be generated.