breaking news

MARS MISSION III

BREAKING NEWS FROM THE SCIENCE FESTIVAL 2005

31/10/05

Here the definite statistics of the participation:

Participation statistics	Sa 22/10	Di 23/10	Lu 24/10	Ma 25/10	Me 26/10	Je 27/10	Ve 28/10	Sa 29/10	Di 30/10/05
File uploads (to local-museum)	5678	8824	5280	3820	3721	2246	3459	7488	7128	47644	78,39%
File uploads (to external)	124	3094	2154	3087	2536	1479	268	295	101	13138	21,61%
Successful log-ins	74	112	29	24	47	38	39	97	70	530
Successful robot-programs	497	578	443	254	218	187	201	426	412	3216

Conclusions:	1. About 1/5 of the file requests came from outside.
	2. The external participants came from foreign countries in the majority of the cases. 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.
	3. A single log-in assigns the robot to the remote user for 5 minutes. Thus there has been an effective robot-
	control for 2650 min = 44h10', which represents a mean of 4.9 hours a day
	4. The number of participants actively controlling the robot (530) can be divided into 424 local users and 106 external
	users =(4:1). The ratio is confirmed by the different IP-addresses.
	5. In several e-mails people from outside complained that the rover was constantly occupied. This criticizing especially
	concerned the weekends during which the robot was run by local users nearly all the time.
	6. The foreign participation only happened after the announcement in the LUGNET news-ring.

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, Laurent, Paul-Nicolas.

28/10/05

Some quite impressive server results from Oct 22th to Oct 27th:
- 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 yet.
"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 !

27/10/05

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 !

26/10/05

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 !)

25/10/05

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 is maintained.
No server incident !
Definitely the CMUCam2 module consums too much power !!!

24/10/05

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 BUTTON TWICE.
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.

23/10/05

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 :

Terence, Yves, Thierry, René enjoy.

Paul-Nicolas explains.

ASIMO searches its reference points.

22/10/05

Luxembourg Science Festival 2005 has started. Special guest : Honda "ASIMO" !!!
RoverX 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.
During 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.
The 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.
There 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.)
The 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.
"Human intervention on Mars" had to happen several times, when the meteorite fell into a bad position.
No server problem.
If they run the rover with the grabber arm open, "hit obstacle" messages might be generated.

LINKS: