16 December 2005

I checked out the code from svn://info.science.uva.nl/home/web/research/ias/software/svn/DAT/branches/jurgen.
RobotControlCMD.exe is the DT2005 release, RobotControlCMDOptimized.exe contains the modules of Jurgen. Unfortunally, RobotControlCMDOptimized failed on an olelink assertion.
Rebuild failed because bash.exe was not in the path. Added C:/cygwin/bin to Tools->Options->Directories->Executables. Rebuild the executable RobotControlCMD.exe, which works now.
The Panorama module sends its debug images as imageProcessorBall (cluster) and imageProcessorGoals (signature) and the final result in imageProcessorScanLines which you can select right mouse button for each of the four images of View->Vision->ImageViewer.

12 October 2005

I checked the code, but leaveWalkCycleSections is only generated, and never used in any module or RobotControlDialog, so I think the patch is save.
I also checked if the vector_n code could replace the std:vector<int> code, but the vector_n code of the Germans can only work with fixed N, while leaveWalkCycleSections is used to store which walks are applicable (and is explicitely dynamic).

OdometryData has on Windows a size 48, the vector<int> leaveWalkCycleSections 16. The struct has an alignment of 8, so 4 bytes are filled after int walkCycleDissection (size 4). Seems that vector<int> is also 4 bytes larger for Windows.
Changed in Visual Studio the alignment from 8 to 4 (Project->Settings->C++->CodeGeneration or -Zp4). RobotControl crashed directly.
Adding #pragma pack( 4 ) for the class OdometryData resulted in a warning for many affected include-files. RoboControl still crashed.
Protecting only OdometryData with #pragma pack( push, Aperios, 4 ) and a corresponding pop worked for the alignment problems after walkCycleDissection, but the problem with std::vector<int> remains.
Patched MessageQueueBase, so that for a data element of 44 bytes (hopefully only OdometryData), only the first 28 bytes are copied (ignoring leaveWalkCycleSections).
After selecting a blue robot, the self-locator works reasonable, twice validities above 0.5 are reached. See .

Moved the standard-library port down in VisualStudio Tools->Options->Directories->Includes and Libraries. According to OpenSceneGraph only version 4.5 works with VisualStudio 6, but a 'make install' failed. When the port is needed (FireSimulator of RoboCup), the directory can be moved above the standard library of Microsoft again.
The assert of fails on s=48, readPosition=0 size=40.
OdometryData inherits from Pose2D, which has size 24 (3 doubles), plus walkCycleDissection and a vector leaveWalkCycleSections (ints).

Started RobotControl EntropyOriginal.
Created new logfile for single Aibo
Created stick from DT2005-soccer-debug and UvA-paper.
Connect. Change from Module Settings the BehaviorControl to DT2005-LightingChallenge.
Select sendPercepts. Record for 3600 sec (button right from infinity). Start after 180 sec (clock left to save to stick after a few seconds). Send. Record (circle button two rows up, left from game).
Save to stick. Replay log-file with as Module Settings only the Self-locater, parse localisation results in Excel. Forth row is validity.

The results were as bad as the week before. That supprises us, because the Aibo played quiet well, and direct inspection of the self-localisation results showed reasonable results.
We recorded the log-file wrong, we also should select sendOdometry!
Odometry leaded to asserts in Robocontrol. Odometry and Percepts were out of synch, result looked still awfull.
Recorded only Percepts on stick after 120 seconds. It is clear when that happens, the Aibo frees for 5 seconds when writing, and continues afterwards.
Also Odometry leaded again to asserts, only Percepts were used. Line 99 in LinuxMessageQ.