Started Labbook 2007.

18 December 2006

• On the internet the .weakref error of gcc-4.1.1 was attributed to an old version of assembler (2.15). The error will not be solved for gcc-4.1.2. Downloaded version 2.17 of binutils.
• With the standard '/home/arnoud/packages/qt-4.2.1/linux/bin/qmake -unix -o Makefile' agent didn't compile. Instead of changing the flags, I corrected the warnings from IniFile.h; added the keyword 'const' to the Records compared in the different Sort-functions. Now the program compiles and links.
• Still, needed the new version of binutils, otherwise still the .weakref error.

5 December 2006

• Compiled the source-code with /usr/bin/gcc (version 3.4.4). Had to replace some abs() with fabs() and fabsf(). Compilation came far, but still an error.
• Conflicts between IniFile and stl_algo.h for gcc-version 2.95.3, 3.3, 3.4.3, 3.4.4 and 4.1.1.

30 November 2006

• Requested account on das3. On das3 libraries and includes of the following gcc-versions are available on /usr/lib/gcc/x86_64-redhat-linux/: 3.4.3, 3.4.5 and 4.0.2. Yet, I couldn't find the executable or config: gcc -V4.0.2 --version
  gcc: couldn't run `x86_64-redhat-linux-gcc-4.0.2': No such file or directory

27 November 2006

• Looked at different interesting datasets to compare with.
  • Amigoni et al. used stanford-gates.
  • Howard et al. used ap_hill_07b and the SAIC/SDR dataset and de USC library.
  • Birk and Carpin used ap_hill_07b, although now also the cartesium dataset from Bremen is available.
  • Stachniss uses in his latest article intel_lab, the fr_campus dataset and MIT Kilian Court.
• On Stachniss rbpfmapper site several other datasets are available. Some of those are not available on Radish.
• I started to experiment with the dataset fr079 dataset. The initial results (with maxRange=19m8 of the LaserRangeSensor) were not bad, although the second tour through the corridor was a few degrees off. Trying the same run with maxRange=80m99 resulted in a freeze of the system, because the map around the measurements becomes too big. Stopped at 10Mb, at 25%.
  
  
• Bayu has tried some new settings on runAlmere1. With these settings only 124 patches (of > 900 scans) are preserved and the results are still spectacular. It's just that the rendering has not as much data as it was used to.
• Bayu has also tried some new the algorithm on the intel_lab dataset. The result are not bad taking into consideration that no loop-closure is performed. The map was generated in approximate 40 minutes, on a mobile 1.9 GHz machine. This is slightly better than the result (45 minutes on a 2.8 GHz machine) reported by Grisetti et al. The result of Grisetti is naturally including loop-closure:
  

26 November 2006

• Bayu created some promising results on the AP Hill dataset. There is still some room for improvement here.
  The log files are massive, slightly under 150.000 lines of which approximately every 4th or 5th line contains a range scan measurement. The attached map is rendered from a manifold with ~12500 nodes, I manually stopped the run so I don't know how much of the log-file was processed already.
  Several observations:
  • this result took 45 minutes (incl. 5 mins of rendering)
  • the robots hardly move between 2 scans, the scanmatcher almost always had more than 160 correspondencies to match (from the 181 in total)
  • as you can see, the walls are razor sharp, so apart from some mismatches the majority matches perfectly. I guess we should make the SLAM a little more robust to 'single points of failure' (keeping a small history perhaps?)
  • the submap mostly had 2 scans, so clearly this is too strict. Also the extension thresholds should be relaxed, even with hardly any movement we already have LOTS of patches (did a small run, 70 nodes for just 2 cm of movement ... )
  • in the manifold, there are 2 main errors visible:
    • the corridor on the right is 'lost' in the process, larger submaps should help avoiding this I think
    • in the corridor at the bottom a rotational offset of ~30 degrees is introduced, this can be addressed with submaps and on top of that improved localization
  
  None-the-less, there is hardly any ghosting, walls are super sharp, so that's promising.
  
  
• Compared with Howards result (the combined map of four robots).
  
  

25 November 2006

• Bayu have been able to improve on Arnoud's results by taking the range scanner's max range into account. In the accompying docs it was said to be ~8m, so I configured the SLAM module to consider any value beyond 7.8m as 'infinite'. This clearly gives better results:
  • ghosting with wall at the top is gone
  • the wall in-between is much sharper
  • all obstacles (pieces of furniture) are much sharper
  
  
  
• Bayu also did run 4 and 5.
  
  

24 November 2006

• Tested the agent-software from Max and Bayu on faro. Command ../../../agent/agent -i first400scans.txt localhost -x works fine. Maybe I had made a wrong merge on pc-unreal, because results for runAlmere4 look very promissing:
  
  
• Made Makefile for gui with command '/home/arnoud/packages/qt-4.2.1/linux/bin/qmake -unix -o Makefile gui.pro'.
• The agent-software get problems with the full scan, because the loop is only started when a victim is found. Loop closure should be trigged when the robot crosses its own path, which is around scan 150, 250 and 500.
  
  
• In runAlmere1 there is only a single loop. The result looks much better. The only problem is in the final corridor, which results in a short path with a deviation to the left.
  
  
• Also in runAlmere5 there is only a single loop. The result looks good until the glass wall. When returning to the final corridor, the deviation to the left is even worse than run1.
  
  

21 November 2006

• Compiled the agent-software from Max and Bayu. Tried many compilers, until I found out that the Makefile had to be rebuild with other subdirectories next to agent-directory. Finally I got an executable, although the linker complained about libstdc++.so.6, needed by /home/arnoud/packages/qt-4.2.1/linux/lib/libQtOpenGL.so, may conflict with libstdc++.so.5. Maybe I should use gcc-4.1.1 instead of gcc-3.3.

8 November 2006

• Tried to install ManifoldSlam on fs2.das2.nikhef.nl, but svn gives the error undefined symbol: GSS_C_NT_HOSTBASED_SERVICE.
• Downloaded ManifoldSlam on faro. ManifoldSlam needs qt-4.2.
• Downloaded qt-4.2.1 from ftp://ftp.trolltech.com/qt/source/qt-x11-opensource-src-4.2.1.tar.gz.
• Configured qt with ./config -prefix /home/arnoud/packages/qt-4.2.1/ -no-sql-mysql, because gmake had problems with mysql. Also added mysql to pkgrc, so this can also be the solution.

2 November 2006

• I selected the logfile runAlmere1, to look if the Runtime error reoccurs. Here the odometry is OK, and the map based on raw measurements looks already good.
  
  
  
• The logfile runAlmere1 was analysed without errors. Still, the result is not optimal. The map consists of two partial trajectories, with a different rotation. The trajectory starts at the entrance (door closed), at the top-middle of the previous image.
  
  
• That only the first part of the map is shown is a feature of the rendering algorithm, to ensure that the small but correct maps. I also tried logfile runAlmere5, but the map is even smaller here.
  
  
  
• The logfile runAlmere5 was analysed without errors. The trajectory starts at same place as before: the entrance (door open), this time in the bottom-middle of the previous image.
  
  
• Checked in agent.cpp. Most other differences compared to the svn-base are end-of-file. An exception is Manifold.cpp, which uses different constants:
  const float Manifold::SUBMAP_MAXTRANSLATIONVARIANCE = 50.0F; // was 10.0F (base 4.0F)
  const float Manifold::SUBMAP_MAXROTATIONVARIANCE = M_PI / 1.0F; // was / 8.0F (including base)

1 November 2006

• Adjusted the software of the UvA Rescue 2006 team to read other logfiles than their own. Started with the Cogniron dataset, which was published on Radish.
• Trick was to use the correct RegExpr as provided by the QT-toolkit. Also I had to use precisely the same type and name of the sensor, otherwise the messages are not accepted.
• I selected the logfile runAlmere4, because halfway the run the odometry failed to detect a rotation. In principal our algorithm should perform better, because it is independent from the odometry.
  
  
  
• The logfile runAlmere4 was processed correctly (941 scans / 472 nodes / 555 links). The full manifold was reduced to a connected subnet of 106 nodes and 105 links. The program crashed on a Access violation (Runtime Error R6034) in library msvcp80d.dll while generating a map of size (1908, 2063). Yet, the first part of the trajectory is already visable.
  
  

October 2006

• Matthijs looked at the software of the different Rescue teams, and installed them on a Linux machine.
• For Freiburg he needed to install qt3-dev-tools, colorgcc and libqt3-mt-dev. The agent locations file was missing, so he emailed vittorio and received usarbit.ini and runstuff.sh. The WFLAGS were undefined, so use qmaile-qt3, not qt4.
• For the UvA code he gained access to our subversion site. He needed qmake to convert the .pro files to Makefiles. For qmake he needed to install qt4-dev-tools and libqt4-dev. Util3D.h seemed to be missing, but this was an uppercase error from Windows. He received Usarbot.ini from Bayu. When running, he had problems to fix the sonar retreating.
• For Virtual IUB he needed to install gcc 3.3 or the flag -fpermissive to compile zthread. For VictemFudicialItem he needed to incorporate player-03.tgz (patch player-1.6.5) in UsarSim. SETENV QTLIB /usr/share/qt3/lib. He installed ibgw2-nexpm-dev to get gw-lib gif support (mare reports). Further he had to set /usr/local/player165/bin/player/usarsim.cfg.
• For SPQR he needed FLEX-old, the flag -fpermissive, to add gmapping lib to gw_lib, and to disable RTESTLIb in the script (exit 0).

6 September 2006

• Looked at the software of the UvA Rescue 2006 team on pc-unreal. A simulation should be started up by
  • Starting the USARsim server D:\UT2004\System\usar_s.bat
  • Starting the USARsim camera client D:\UT2004\System\usar_c.bat
  • Starting the UvA mapserver D:\svn\rescuecontrol\server\release\server.exe [port]
  • Starting up to three UvA agents D:\svn\rescuecontrol\agent\release\agent.exe [hostname USARsim server]
    • o - output logfile
    • i - input logfile
    • x - specify to use sleek drawing
    • r - spawn rotation or the robot
    • s - spawn postition or the robot
    • n - a friendly name for the robot
    • m - the model of the robot to spawn
    • g - the hostname of the UvA mapserver
    • b - the port of the UvA mapserver
    • p - the port of the USARsim server
• Tried to run the RoboCup 2006 Demos. Started Unreal game -> Instant Action -> Death Match -> ' -> demoplay uvaDay4b. Failed on version of BotAPI.

13 March 2006

The agents can start moving after three cycles. Yet, the random patrol was defined for a typical map of 1500 road-segments, instead of the 40 of the small Proof2-map. Counting the number of steps (everytime the agent has nothing to do!) solves the problem, with a much better result of 2.662876.

9 March 2006

• Reduced the max_extinguish_power_sum from 1000 to 100 in config.txt to make the task more difficult for the fire-agents. Yet, the fire-agents do nothing, probably because they stopped traveling (traffic-simulator problem?). Anyway, the score of doing nothing after 20 cycles is 2.898275, and the neighbours didn't catch fire yet.
• Increased the period from 20 to 40 in config.txt, but still the neighbours didn't catch fire yet (although the buildings are dark red). The fire-agents cannot do anything, because they stopped the traffic-simulator crashed). Anyway, the score of doing nothing is 2.846050.
• Increased the period from 40 to 60 in config.txt, and rebuild all programs. The traffic-simulator now works, and the fire-agents take correct positions, but no extinction is visible. After 50 cycles the burning buildings are completey burnt down, without igniting the neighbouring houses. Final score is 2.84050.
• Created Proof2 map, with in the lower corner a three story building. At cycle 28 the two neighbours ignite, at cycle 51 the diagonal neighbour ignites, and at cycle 60 the last left building. The last command visible is at cycle 53 (a move or a stretch 129), but I couldn't scroll the window. Final score after 54 cycles is 2.504541.
• Copied RescueMiddleEarth from rescue-0_44, and applied changes as described in earlier, but the change in main.cpp to create a UDPConnection is not directly clear to me. The trick is to replace in the function-call setup_connection config.port with the variable service, so that the command-line option is used. Behaviour is the same, but I increased to period to 100. Now the other left center-building also ignites, and the score after 100 cycles is 2.303389. I also found the reason that the fire-agents cannot extinguish; their commands are rejected by the kernel because the amount of water is larger than the max.
• Introduced max_extinguish_power_sum in parameter.hxx, and now the agents start fire-fighting. After 90 cycles they have stabilized the situation. The score is 2.611165. Possible improvements: multi-nozel actions for neighbours, cooling down of fiercely burning buildings.
• Created function findDanger, which selects an endangered neighbouring Building. This function is used in the Extinguish command for a second nozzle with a small amount of water (up to 9%). The result looks good, but the final score is 2.477168 due to water-damage. Possible improvements: excluding water-damaged buildings in the findDanger function.
• The exclusion of water-damaged buildings in the findDanger function works very well, but not as expected. It leaves non-burning houses alone, but shares some water with burning neighbours. The result is 2.611165. Possible improvement, remove the assymmetric waste check.
• Raising the second waste check from 2 to 3 didn't help. Raised the ALLOWED_LEVEL, but now the lower agents oscillates in the Refuge. The result is 2.558409.
• Raising the third waste check from 2 to 4 did help. It looked much better, although the result is 2.611165 (upper building burns down anyway). Possible improvements: at time 9 the bottom agent 268129151 starts considering to extinguish they other building B199575127 (less capacity, other agent closeby). Only at time 44 the top agent 266329182 considers two buildings. At time 9 the bottom agent could have better selected to top one.
• Scaled the distance in findBuilding and findFire with the TotalBuildingArea. The top one became far more attractive, but not enough to select.
• Performance could be better as the agents first moved to the center, and than started to extinguish.

8 March 2006

• Modified Proof/gisini.txt, because gis can only read files where the number of buildings and agents are defined before the positions of buildings and agents are given.
• UvArescueC2004/UvAgents -f2 -F1 -d53 tries to connect to the kernel, but this seams to be the wrong host, port of protocol. TCP is port 7000, UCP is port 8000. The latter is the correct one (-s 8000). The kernel complaints about tcp-connection 34636. From the viewer, I originally get a window, later only messages. Yet, logviewer it seams to work. The two FireAgents are throwing 300 cycles water on the two burning fires, and the fire doesn't spread. The score is constant at 2.949576. Yet, the WaterLevel only goes down once, and never after, so it seams that the firesimulator is crashed. The score/reward is printed in the file SimulationStats.txt. The actions are recorded in DebugInfo.txt (format action(agent-id): building-id, ?, ?, ?, water, 0,).
• The firesimulator of rescue freiburg crashed about an AK_STRETCH. Protected that part in the World.java code.
• Now both FireAgents extinguish both buildings in one turn. Afterwards they get an conflict about going to the refuge. Reduced the period in config.txt to 20. Protected part in viewer/WorldModel.java to be able to view the logfile.
• To be done, reduce the maximum amount of water until they can better start with one building, and then the other.

1 March 2006

• Copied the small maps from ~mfassaer/RCR.
• The boot-scripts all.sh do not work anymore, because xterm terminates directly after the command is spawned.
• The boot-scripts works without xterms, but rescue-0_44 isn't made, and for rescue-0_48 I have no agents in Amsterdam. Friday I will upload them from Delft.
• Looked at ssh as replacement for xterm, but creating an authorized_keys as specified in the ssh-manual doesn't work (both protocols). Maybe I should use grid-proxy :-).
• start ../maps/Tiny works. Tiny is Kobe with one police-agent. Test is Kobe with 50 civilians, 5 fire-agents and a fire-center.
• Notice that Maurits start spawns the xterms without problems as iconic. Copied to rescue-0_48/boot
• Found ../maps/Proof in my mailbox. There seems to be a new version of JGISedit available than my 2002 version. The 2003 version also shows the location of the agents.

Labbook 2005

• http://staff.fnwi.uva.nl/a.visser/research/roboresc/December2005.html

Labbook 2004

• http://staff.fnwi.uva.nl/a.visser/research/roboresc/August2004.html

Formatting Help?

• Usemod Wiki Text Formatting Rules http://www.usemod.com/cgi-bin/wiki.pl?TextFormattingRules