Started
Labbook March-June 2007.
20 February 2007
- Added C# language package to Visual Studio 2005 Professional on pc-unreal.
- Could load mialsharp.csproj, compile and run. MialSharp is a separate program,
which reads in logfile (always 'foo.log'), which contains the information from all the patches from the Manifold. The information are the absolute positions from the robot and the absolute positions of the scanpoints. The information about one scan is written for each call to QtManifoldRenderer::renderScan.
- MialSharp analyses the logfile with two function-calls: slam2Mial and partDetection.
- slam2Mial creates the polynomes for blackwall, sunshine and shadow.
- partDetection finds the frontiers and the path to the frontiers, and draws the colorful.png map.
- Received MailStorage.cpp and MailStorage.h from Ji.
7 February 2007
- Checked the effect of loop-closing on the accurracy. Run './MapMetric -a day4_run2/UvA/tag_id_pos.log -r day4_run2/UvA/rfids-before.log -p day4_run2/UvA/positions.log -d 6 -m 10', with the following result:
- 61 tags detected!
- reasonable tags: 597, outliers: 1233
- Tags within range: 243
- Tags reported: 243
- RMS Error: 0.121018
- The merit index is: 0.987898
- The loop-closure increases the accuracy with a factor 10. Run './MapMetric -a day4_run2/UvA/tag_id_pos.log -r day4_run2/UvA/rfids-after.log -p day4_run2/UvA/positions.log -d 6 -m 10', with the following result:
- 61 tags detected!
- reasonable tags: 668, outliers: 1162
- Tags within range: 243
- Tags reported: 243
- RMS Error: 0.0155216
- The merit index is: 0.998448
- With the range set on 10m (-d 10), 330 tags are reported, and the RMS is resp 0.0655485 and 0.00840715 (merit index 0.993445 and 0.999159).
- The original MapMetric still gives RMS Error: inf
- The hotel-loop is generated with DM-compWorldDay4b. Tried again with commande 'OutlierCorrected/MapMetric -a day4_run1/tag_id_pos.log -r day4_run2/UvA/rfids-before.log -p day4_run1/UVA_positions.log -d 6 -m 10' :
- reasonable tags: 1533, outliers: 297
- Tags within range: 136
- Tags reported: 136
- RMS Error: 0.0543236
- The merit index is: 0.994568
- The difference between before and after loop closure is now only minimal:
- reasonable tags: 1487, outliers: 343
- Tags within range: 136
- Tags reported: 136
- RMS Error: 0.0527092
- The merit index is: 0.994729
- The original MapMetric still reports Inf.
- The original MapMetric calculates the wrong abs_adj_matrix, with many 0 and Inf. When this is corrected, the difference between loop-closure is 0.0108993 vs 0.0497272 (5 times as bad).
- This is no flaw of the MapMetric. For the hotel-loop, RFID 11021 is the one in the upper-left corner. The estimate of this tag is good: the x-location is for tag,before,after: -61.3,-61.3,-61.8. The RFID 11024 is the one in the lower-left corner. The x-location is for tag,before,after: -62.8, -61.5 and -49.6. The distance-error between 11021 and 11024 is 4.4 meter.
1 February 2007
- Ji noticed that the agent becomes sensitive to the starting position when the behavior and motion is switched on, as done in revision 404.
31 January 2007
- Started a run with the stanford-gates1 dataset, to compare our exploration algorithm with the one from Latombe. The command 'debug\agent.exe =i standford-gates1.log -f player -c 181beams -x 127.0.0.1' worked for 362 scans. At scan 363 the scan-matcher returned nan, and couldn't recover. Copied some settings of intel to stanford, but still there is a problem around 'sync 1106955339.622' / position -01.062 -00.435 +4.102.
- Problem seems to occur due to a shift of one MAX_RANGE point to a second MAX_RANGE point back to one MAX_RANGE again. I commented out some points in stanford-gates-first400.log, and the algorithm was able to process 10 scans more.
- Tried stanford-gates-second-half.log, but the algorithm fails after 18 scans.
- Tried stanford-gates-after400.log. Algorithm fails after 2344 scans. Created stanford-gates-400till2400.log (actually contains 1581 scans). Still, the result is quite bad:
- Tried to process Sieg-Hall dataset from the University of Washingtion, as used in Figure 3.8 of Cyrill's thesis. Running the agent failed, because CXXABI_1.3.1 couldn't be found (used by /usr/lib/libstdc++.so.6). Recompiled with gcc-4.0.0. Agent started, but returned with a Fatal IO error.
- Problem with CXXABI was due that /usr/lib/libstdc++.so.6.0.3 (uses CXXABI_1.3) was loaded. Added the library-path to gcc-4.1.1 pkg, and now /usr/local/arch/gcc-4.1.1/lib/libstdc++.so.6.0.8 (uses CXXABI_1.3.1) is loaded). Still the same Fatal IO error, when the main spawned QApplication app.
- Tried to find the error with the debug-libraries of Qt, but finally decided to run qtdemo. This application also failed, because I run the application remotely. Started Exceed on pc-vlab10, and both the qtdemo as the agent could start up.
- The agent was able to process the first 100 scans, but the map looks terrible. Better to stick to the Intel Lab and Freiburg dataset.
25 January 2007
- Switched the behavior on in UsarAgent::Notify. Build a new debug\agent.exe.
qualification1_X10112.log -s -52.0,-5.0,-4.0 127.0.0.1 -c c
li>The robot to the center of the labyrinth, near RFID 10112: 'debug\agent -x -o qualification1_X10112.log -s -52.0,-5.0,-4.0 127.0.0.1 -c robocup'. The robot was not able to pass the first bend. The robot climbs the hedge in the front, retreats, turns left and right, climbs the hedge on the right and falls on his back. The first bend is in the middle of RFIDs 10165, 10166, 10178, 10179: (x,y,phi)=-38.5,-1.6,-1.2.
- Started the robot at the first bend, near RFID 10178: 'debug\agent -x -o qualification1_X10178.log -s -38.5,-1.6,-4.0 -r 0.0,0.0,-1.2 127.0.0.1 -c robocup'. The robot tried to evade the second bend, and climbs the hedge in the right and falls on his back. This is more or less on RFID 10189: (x,y)=(-35.28,-8.28).
-
- Continued in front of the first bend, on RFID 10189: 'debug\agent -x -o qualification1_X10189.log -s -35.28,-8.28,-4.0 <-r 0.0,0.0,-1.2> 127.0.0.1 -c robocup'. The robot was able to take the second bend, but failed at the T-junction.
- Started on the original start location of qualification1. The command: 'debug\agent -x -o qualification1.log -s 13.0,5.0,-4.0 -r 0.0,0.0,1.57 127.0.0.1 -c robocup'. The robot stays nicely on the sideway. It passes the side-street without accidents. On the other side it is attracted by victim Ali, but is not able to climb the sideway (doesn't fall). On the end it was able to climb the sideway, but the shocks were so big that the controller stopped after 17 minutes. The robot was still presented when it stopped. Loop closure found 217 gaps, 193 around victim Ali, 24 around victim Ray. The maps before and after are equal, because the rendering stops near the police-car where Ray is hidden behind. Ali is even one police-car further, not visible on the map.
24 January 2007
- Tried to rerun qualification-day1 to see what the current score was:
- Started server with command 'ucc server DM-compWorldDay1?game=USARBot.USARDeathMatch?TimeLimit=0?GameStats=False -ini=USARSim.ini -log=usar_server_day1.log'.
- Started client with command 'usar_c.bat'.
- Started agent with command 'release\agent -x -o qualification1.1.log -s 13.0,5.0,-1.0 127.0.0.1'.
The robot started on the sidewalk, looking at the wall. The processing started only after I switched from spectator to player and back. The robot didn't move. I turned him around with command d, but was not able to move him forward with command w. According to Bayu the robot doesn't move because the exploration-behavior is switched off in UserAgent::notifyUpdate since version 306 (20 Augustus 2006).
- Started agent with command 'release\agent -x -o qualification1_inside.log -s -44.0,11.0,-4.0 -r 0.0,0.0,-1.57 127.0.0.1'. This was in the staircase, next to the gardendoor.
- Moved the robot a little bit back (y=11 -> 16m): 'release\agent -x -o qualification1_inside.log -s -44.0,16.0,-4.0 -r 0.0,0.0,-1.57 127.0.0.1'. This was in the corridor, in front of the staircase.
- Moved the robot a little bit to the front (y -> 6m): 'release\agent -x -o qualification1_inside.log -s -44.0,6.0,-4.0 -r 0.0,0.0,-1.57 127.0.0.1'. This was in the garden, to the right of the entrance of the labyrinth.
- Moved the robot to the front of the labyrinth: 'release\agent -x -o qualification1_inside.log -s -52.0,1.0,-4.0 -r 0.0,0.0,-1.57 127.0.0.1'.
- Moved the robot to the center of the labyrinth: 'release\agent -x -o qualification1_inside.log -s -52.0,-5.0,-4.0 127.0.0.1'. This point is in the middle of RFIDs 10112, 10113, 10125, 10126. First T-junction is quite far away: RFID 10189.
- Moved the robot to the t-juntion of the labyrinth: 'release\agent -x -o qualification1_inside.log -s -35.64,-11.1,-4.0 -r 0.0,0.0,-2.5 127.0.0.1'.
22 January 2007
- Compilation for msvc.net of qtwin-4.1.3 failed on tools\porting\src.
- Increased heap-space in Makefile.Release from -Zm200 to -Zm10000. Now the porting tools are generated.
- Next failure is in src-directory (qmake not known). Added bin-directory to PATH, compilation continues.
- Compilation fails in a test directory. Did 'nmake install' in src directory, and all needed libraries and include-files seems to be there.
- Created Makefile from agent.pro with command 'qmake -win32 -o Makefile agent.pro'. Started compilation with command 'nmake'.
- The Makefile tries to compile with g++, instead of Microsofts cl. This goes well for the agent, but not for the socket and server directory (problems with definitions in /usr/include/socket).
- Copied Makefile.* from pc-unreal, and replaced d:\qt-src-4.1.3 with c:\qtwin-4.1.3. Now we could build socket and server, but they use the debug-versions of qt.
- Rerun 'qconfigure.bat' with flag -debug-and-release.
- Also copied Makefile.* from pc-unreal for agent.
- Everything compiles, except main.cpp.
include\tclap\XorHandler.h(141): error C2065: undeclared indentifier
include\tclap\XorHandler.h(142): error C2679: binary '!='" nor operator found
- Moving 'using namespace std' in front of include\tclap\CmdLine.h solves the problem.
- Added Config.cpp, IniFile.cpp, LogParser.cpp and StatusSensor.cpp to Makefile.Release.
- Problems with IniFile.cpp:
error C2552: 's' : non-aggregates cannot be initialized.
- Solved by sequential initialization. Now 'release/agent.exe -i ../logs/runAlmere1/scans.txt -f cogniron -c cogniron' works.
- The result is not bad, although the algorithm is fooled by the strange turn between the living and the bedroom:
17 January 2007
- Tried to install qt-4.1.3 on pc-ias01. This machine has Visual Studio 6 (1998) and Visual Studio .Net (2003), so I couldn't copy the package from pc-unreal. Followed the instructions from http://qtnode.net/wiki/Qt4_with_Visual_Studio.
- Downloaded ftp://ftp.trolltech.com/qt/source/qt-win-opensource-src-4.1.3.zip and http://downloads.sourceforge.net/qtwin/acs-4.2.2-patch1.zip.
- vcvars32.bat was not available from the command-line, so I started a file-search. Script is available both in VC98\Bin and Vc7\bin. Decided to use the Visual Studio .NET Command prompt.
- installpatch42.bat seems to fail in tools/linguist, tools/assistant and more improtant in qmake/generators. Yet qmake/Makefile.win32-msvc.net was created, so maybe it stillworks. Otherwise we have to find a different patch file.
- There exist no patch file for qt-4.1.3, but there exist a svn-revision tagged http://qtwin.svn.sourceforge.net/viewvc/qtwin/qt-4/tags/qt_4_1_3/.
- Try to make a release of qt-4.1.3 with the partial patch, but 'qconfigure.bat msvc.net -release' failed directly: nmake couldn't find src\corelib\io\qresource.h
- Checked out https://qtwin.svn.sourceforge.net/svnroot/qtwin/qt-4/tags/qt_4_1_3 into C:\qtwin-4.1.3\
- Switched to https://qtwin.svn.sourceforge.net/svnroot/qtwin/qt-4/ revision 1869 (1839 is tag qt_4_1_3), because some of the Makefiles and qtpatch were missing in the tag-version. Makefile.win32-msvcnet was updated in version 1869, the next change was to cope with qt version 4.2.2. Version 1869 belongs to version 4.1.4. Version 1872 is version 4.1.last.
- Compilation failed at codemodel.cpp: compiler out of heap space.
Labbook 2006
Labbook 2005
Labbook 2004
Formatting Help?