Started Labbook 2008.

29 November 2007

• Looked at a way to model the world of the ICRA challenge. Two possibilities to model a sandbox:
  • Particle emitter (thousands of particles).
  • Change vehicle-friction (attribute of vehicle, not environment)
  • Not possible: water (only rectangular pool, no friction, only splashing)
• Tijn did some tests, and only the bots reacted (and not the vehicles). Tijn pointed out that the Unreal GameMod CarBall solved this issue on version 2.4. Currently only version 2.7 is available, nicely packages as an ut4mod, which adds nicely an entry in the main-menu, and allows for the CarBall game only to select CarBall-maps. A lesson to be learned.
• Unfortunatelly, no source-code is provided, so I should ask.

25 November 2007

• Added synchronisation of the map between the BehaviorRobots (update-cycle of 30 seconds, while the operator has an update-cycle of 10 seconds). Results are good, the robots do less double work.
• The gaps in the updates are not due to the synchronisation cycle, but a bug in the synchronisation protocol (or the print statements):
  • [Comm] - Achilles received sync commit from Hercules (11/25/2007 6:50:50 AM)
  • [Comm] - Achilles sent sync update to Operator (5 items since 11/25/2007 6:50:51 AM)
  • [Comm] - Achilles received sync commit from Operator (11/25/2007 6:50:59 AM)
  • [Comm] - Achilles received sync start from Operator
  • [Comm] - Achilles sent sync update to Operator (5 items since 11/25/2007 6:51:02 AM)
• Result for CommStation West (Achilles crashed after 15 in the NorthWest corriodor, a few minutes later followed by Hercules in the SouthWest corridor): [AREA] 604 1035.72 530.89:
  
• Result for CommStation East (Hercules got stuck on the legs of the victim, but was able to recover after 2 minutes): [AREA] 612 1132.25 568.28
• Result for CommStation Middle: [AREA] 680 1239.30 642.30:
  
  
• Results are too good, so I decreased the CommStation power with 6 dBm. In the second room the Power is now -91 dBm. The result has effect, but still beyond the lobby:
  • [Achilles] - CommStation is (-44.50,15.50) m and Robot on (-48.46,30.46) m
  • [Achilles] - Estimated distance to CommStation is 15.47 m for -79.71 dBm
  • [FrontierExploration] - At distance 31.72 m to CommStation the pathloss is estimated on -92.40 dBm
  • [FrontierExploration] - Communication success is estimated on 50 %
  • [FrontierExploration] - At distance 28.07 m to CommStation the pathloss is estimated on -79.71 dBm
  • [FrontierExploration] - Communication success is estimated on 100 %
  Problem is that as long no low powers (in this case < -79.71 dBm) are seen, the estimates about low power are quite rough.
• Rerun the non-information shared experiment (ePo = -28 dBm) with Debugging on. With the CommStation in the middle: [AREA] 818 1312.43 535.41
• Rerun with the CommStation in the west. This was a nice run for Hercules, but Achilles directly got stuck in the second room. Achilles was out of communication range, but its position was relayed by Hercules. Result: [AREA] 477 1253.03 431.38
• Second try. Now both had a nice run, although they did a lot of double work:[AREA] 786 1094.04 555.65
• Last, but not least, the run with the CommStation in the East. Both explored the Northern corridor (double work). Achilles explored the East corridor. Hercules explored the South-East corridor. Inside the lobby Hercules was out of range, but inside the South-East corridor Hercules could send its measurements again.Result: [AREA] 709 1455.89 545.08
• Rerun with information sharing. Unfortunatelly, both robots get stuck at the side of a door: [AREA] 451 939.71 429.65
• Another rerun. Both robots get stuck in resp. room 3 and 5. [AREA] 474 1184.76 303.04
• Increased the Gaussian kernel from 15 to 17. This time a successful run, but still without an impressive result: [AREA] 223 764.06 426.16. Hercules explores a lot of space in the SouthWest, but Achilles is too far away to relay. Both robots slow down, because there is only one option, so the path-planning has to be performed for the full diagonal.
• Tried shared Middle. Hercules tumbled in the corridor below the North-South room, Achilles tumbled in the lobby (continued driving while thinking). [AREA] 410 1072.29 512.54
• Run with the CommStation in the east. Good exploration of both robots, although at the end both robots tumble. [AREA] 540 1238.68 547.11
• Started UsarCommander with less programs in the background. Now the behavior is better. At the end both robots get stuck on a victim: [AREA] 514 876.30 490.83 (4 Victims)
• Submitted the paper The influence of communication range on the information gain for multi-robot exploration to the Workshop on Wireless Multihop Communications in Networked Robotics.

23 November 2007

• With i.e. the table on this wikipedia-page, I did a sanity check on the powers received. Typically, a wireless router emits 100 mW (+20 dBm). At short distances, 1 microW is received (-30 dBm). Bremen indicates a power of -49.67 dBm at 2 meter (a little bit) concervative. For the 802.11b typically a range of 38 meter is indicated (including Walls). Typically, the power at that range is -70 dbm, which leaves 20 dBi for the Walls.
• Tried several configurations for the ComServer. Bremen indicated an attenuation of 6 dBi per Wall. When a robot enters a room, it seems that there are several obstacles present according to UsarSim. I raised the number of obstacles, and decreased the attenuation per obstacle. This gives realistic values. Tried the following configurations:
  • -49.67 + 5 x 6.625 (signal everywhere < - 100 dBm)
  • -34.67 + 5 x 6.625 (40 dBm too weak)
  • -14.67 + 5 x 3.325 (13 dBm too strong)
  • -14.67 + 10 x 3.325 (5 dBm too strong)
  • -20.00 + 10 x 3.325 (Ok, too strong at larger distances)
  • -20.00 + 10 x 4.325 (Ok, too strong jumps in rooms)
  • -20.00 + 20 x 1.325 (Ok, too strong in corridors)
  • -22.00 + 20 x 1.325 + 1.09 f(d) (Selected)
• Debugged the prediction of the power with a QuadTree. Commited version 839.
  
  CommStation resp. at the West, Middle and East side of the North corridor.

22 November 2007

• Made the chain FrontierExploration->CorridorWalk->RandomWalk->FrontierExploration. Added Sanity-check in ManifoldSlam before storing the first Patch and included tilt-sensing and Retreat. Result is a bit more stable, but the problem remains that there are not enough frontiers on this map to choice from. Commited version 836.
  
  
  • Hercules: FrontierExploration (Tilted) -> CorridorWalk 33 Patches (Open Space) -> 35 Patches (2 minutes) -> FrontierExploration
    • Best Frontier of size 4.43 m^2 at distance 4.00 m -> Utility 1.11 (Patch 69)
    • Best Frontier of size 2.28 m^2 at distance 9.80 m -> Utility 0.23 (Patch 97)
    • Best Frontier of size 9.94 m^2 at distance 10.10 m -> Utility 0.98 (Patch 195)
    • Best Frontier of size 9.90 m^2 at distance 6.60 m -> Utility 1.50 (Patch 255)
    • NO PROGRESS ANY MORE FROM THIS POINT. HYPOTHESIS: pathplanning steared too close to the wall).
    • Best Frontier of size 4.42 m^2 at distance 4.40 m -> Utility 1.00 (Patch 311)
    • Best Frontier of size 4.22 m^2 at distance 5.30 m -> Utility 0.80 (Patch 351)
    • New Goal Position = (-60.40 , -3.60)
    • Best Frontier of size 4.22 m^2 at distance 5.10 m -> Utility 0.83 (Patch 381)
    • New Goal Position = (-60.20 , -3.70)
    • Best Frontier of size 4.07 m^2 at distance 5.10 m -> Utility 0.80 (Patch 454)
    • New Goal Position = (-60.20 , -3.70)
    • Best Frontier of size 4.01 m^2 at distance 4.90 m -> Utility 0.82 (Patch 533)
    • Best Frontier of size 3.98 m^2 at distance 5.20 m -> Utility 0.77
    • Best Frontier of size 3.98 m^2 at distance 7.20 m -> Utility 0.55
• Found that the Motion maintains its own list of TeamMembers and TeamPoses. TeamMembers can be initiated at startup (Constructor checks information in the teamconfiguration), but the TeamPoses should really be maintained. Made the TeamPose-list from the CommAgent accessable from the motion (Protected Friend). Consequence:
  • the position of the Operator is known (needed for calculating communication probability)
  • The decisions of other agents is taken into account (will make the SelectNewTarget much slower).
  • The computation of the power didn't had good prediction power, so I stored the tuples (distance,power) for a better estimate. This works fine. Commited version 838
    
    

21 November 2007

• Instead of the _eAttenFac, I changed the eMaxObs to 10. Typical signal-strength still -88 dBm. Also repaired the incorrect test I introduced in the BroadcastSend. The result is bad. Most of the time is dedicated to broadcasting, while not much appears on the screan.
• Raised the _eAttenFac to 1.625 dBm, and now the levels are between -93 and -95 dBm.
• Lowered the _eAttenFac to 1.125 dBm (eMaxObs=5). Levels are now between -81 and -93 dBm. Unfortunatelly, UsarSim crashed on a Runaway loop in the UsarComServer.getSigStrength. Commited version 833.
  
  
• Moved the RelaySyncCommand to the OperatorAgent.PoseUpdate (increased the frequency from 30 to 5 sec). Now the robots have their own manifold, and only know the other's position. The update is still slow, although the number is sent is reasonable:
• Found that still a RelaySyncCommand was sent by the robots (after SyncCommit was received). Tried again, but Achilles was on its back before I before I knew it. Added some sanitychecks in ManifoldSlam. The check on match.NumCorrespondencies = 0 is independent of the scanmatcher. The check on Abs(match.Covariance(0, 0)) > _CovarianceThreshold should be scanmatcher dependend.
• First succesfull run. Achilles didn't had signal anymore in the upper-left corner, put relayed its position. After checking two corners, Hercules decided to go up and found a victim at the dead-end. Commited version 834.
  
  
• Found out that RandowWalk has often no option. Retreat was not used, instead the robot was turning around. Changed from turning to FrontierExploration. Implemented new Motion (CorridorWalk) and made the chain FrontierExploration->RandomWalk->CorridorWalk->FrontierExploration. CorridorWalk was once selected, but run in a bug. Repaired bug and commited version 835. To be tested.

20 November 2007

• Included the utility-function based on probability on communication. Changed the _eAttenFac from 6.625 dBm (walls) to 0.625 dBm (bushes). Typical values in the Labyrinth are -88 dBm, so I should try an _eAttenFac of 1.625 dBm tomorrow.
• Got the continues-sync working.
• Unfortunatelly, after a while, no interesting frontiers are to be seen, because the corners are so sharp. Changed the FrontierExploration-motion, to switch to RandomWalk for 2 minutes. Switch to RandomWalk works, change to FrontierExploration not. Committed version 832.
  
  
• Tomorrow, try an exclusive switch in AutonomousExploration.

19 November 2007

• Version 830 works, but the operator is updated too slowly. Further it seems the time-out functionality is still needed in the Frontier exploration.
• Changed that always a small update is sent (3 seconds or 5 patches and 4 relations). Only when the robot is paused a complete update is sent. The robot is automatically paused when the battery is finished.

16 November 2007

• Experimented with two robots. The information that is sent is still huge. The best performance was when I accidentenly put the exchange back to the latest 10 results.

15 November 2007

• Changed eMaxObs from 5 to 2. This are the commit times

  operator -> Hercules	Hercules -> operator	comments
  10:05:24	10:05:26
  10:05:28	see next row
  10:05:31	10:05:29	4 extra items
  10:05:34	10:05:33
  10:05:38	10:05:36
  10:05:40	10:05:39
  10:05:41	see next row
  10:05:43	see next row
  10:05:46	10:05:45	4 extra items
  see next	10:05:48
  10:05:49	10:05:51
  10:05:53
  10:05:55	10:05:54
  see next	10:05:57
  10:06:34	10:06:51	one minute
  10:07:27		patch missing
  10:07:51	10:07:37
  	10:07:57	patch missing
  10:08:20	10:08:26	patch missing

  So, as long as the updates arrive in seconds, everything goes well.
• Changed the WssDevice frequency from 2 seconds to 10 seconds. Replaced the SyncRequest from the FrontierExploration, to the NofifySignalStrength handler.
• Changed the WssDevice frequency back to 2 seconds. The result is fast (typically 1-3patches per sync), but in the beginning patches are missing, until later when many patches are sent up and down (typically 50 patches, most already known).
  
  • [Comm] - Operator received first sync update from Hercules at 11/15/2007 2:22:01 PM)
  • [Comm] - Operator received master sync update from Hercules (3 items)
  • [Manifold]-- Extended, currently has 2 patches / 1 relations
  • [Comm] - Operator sent sync commit to Hercules (11/15/2007 2:21:59 PM)
  • [Comm] - Operator sent sync update to Hercules (0 items since 1/1/0001 12:00:00 AM)
  • ...
  • [Comm] - Operator received master sync update from Hercules (4 items)
  • [Comm] - Operator sent sync commit to Hercules (11/15/2007 2:22:03 PM)
  • [Comm] - Operator received sync commit from Hercules (11/15/2007 2:22:05 PM)
  • ...
  • [Comm] - Operator received master sync update from Hercules (4 items)
  • [Map] - relation recorded at 11/15/2007 2:22:06 PM from unknown FromPatch at 0.00077 , -0.00031 / 0.14099)
• Changed the protocol completely. LastUpdate is written at only one place: when a Commit is received. A commit is received directly when a message is received, followed by the Manifold Writers-block. Reduced the WSSdevice frequency to 10 seconds, because it takes up to 5 seconds before a commit returns. Commited version 827.
• Changed the protocol further. The Slave sends complete updates, the Master sends only the latest updates. Works fine, a few extra patches (one in set of 12). Only had a socket problem that should be catched. Commited version 828.
  • [Operator] - sending data of length 406
  • A first chance exception of type 'System.Net.Sockets.SocketException' occurred in System.dll
  • A first chance exception of type 'System.IO.IOException' occurred in System.dll
  • Exception occurred while trying to send message
  • System.IO.IOException: Unable to write data to the transport connection: An established connection was aborted by the software in your host machine. ---> System.Net.Sockets.SocketException: An established connection was aborted by the software in your host machine
  • at System.Net.Sockets.Socket.Send(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
  • at System.Net.Sockets.NetworkStream.Write(Byte[] buffer, Int32 offset, Int32 size)
  • --- End of inner exception stack trace ---
  • at System.Net.Sockets.NetworkStream.Write(Byte[] buffer, Int32 offset, Int32 size)
  • at UvARescue.Communication.WssConversation.Send(Protocol protocol, Byte[] data) in D:\UvA Rescue 2007\edu\Communication\Device\Wss\WssConversation.vb:line 220
  • at UvARescue.Communication.WssConversation.SendMessage(Message message) in D:\UvA Rescue 2007\edu\Communication\Device\Wss\WssConversation.vb:line 402
  • A first chance exception of type 'System.Threading.ThreadAbortException' occurred in mscorlib.dll
  • The thread '' (0x6c8) has exited with code 0 (0x0).
  • The thread 0x750 has exited with code 0 (0x0).
• Protected the Send with an Exception-handling routine. First experiment with two robots:
  
  
• Experiment was partly succesfull. Achilles explored the North-South room, Hercules reached the T-junction. Then both went into Nothing to do mode. Should replace the distance threshold on replanning with a timing threshold.

14 November 2007

• Recompiled ComServer.uc, but UsarSim now crashes:
  • USARComServer DM-Mapping_250.USARComServer (Function USARBot.USARComServer.getSigStrength:020A) Runaway loop detected (over 10000000 iterations)
  • History: FFrame::Serialize <- UObject::ProcessEvent <- (ComServerCon DM-Mapping_250.ComServerCon, Function USARBotAPI.ComServerCon.ReceivedText) <- ATcpLink::PollConnections <- ATcpLink::Tick <- TickAllActors <- ULevel::Tick <- (NetMode=0) <- TickLevel <- UGameEngine::Tick <- Level Untitled <- UpdateWorld <- MainLoop <- FMallocWindows::Free <- FMallocWindows::Realloc <- 10910191 0 FArray <- FArray::Realloc <- 0*2 <- FMallocWindows::Free
• Updated all Com*.uc from svn, and replaced modified *.ini files. Now the simulator works again.
• Changed cutoff from -93 dBm to -99 dBm.
• Found the right position for NW (-66.25,16,-3.3).
• Running with Hercules or Achilles alone works. Achilles doesn't reconnect to Operator when possible.
• Solved the bug (there was still a reply pending from a failed OPEN). Committed version 825.
  
  
• Put PATHLOSS_THRESHOLD and eCutOff back to -93 dBM, and raised ePd0 from -49.67 to -29.67 dBm (stronger radio-signal at distance D0 (2 meter)). Now, there is signal in the North-South room. Signal is weak far in the lobby.
• Raised ePd0 from -29.67 to -9.67.
• Still, some patches are missing.
  • [Comm] - Operator sent sync commit to Hercules (11/14/2007 6:51:48 PM)
  • [Comm] - Operator received sync commit from Hercules (11/14/2007 6:51:50 PM)
  • [Comm] - Operator sent sync commit to Hercules (11/14/2007 6:51:51 PM)
  • [Comm] - Operator received sync commit from Hercules (11/14/2007 6:51:52 PM)
  • [Comm] - Operator received master sync update from Hercules (2 items)
  • [Map] - relation c2d10d8b-30ed-4973-bebd-30dd30f73861 from unknown FromPatch 69b253cd-343b-4b12-9eb8-37cdd3bef802) [Comm] - Operator sent sync commit to Hercules (11/14/2007 6:51:54 PM)
  • Now have a version with only a few extra patches at the begin of a sync.

13 November 2007

• Successfull TeleOperation with v671, and with v824 (after adding CreateCommActor in CommAgent).
• The distributed autonomous exploration works fine in the MappingWorldGarage. Hitting the world button gives me updates, until the second room (PATHLOSS_THRESHOLD= -93 dBm). The robot continues his explorations (but nothing this is not seen on the map).
• Tried again, with PATHLOSS_THRESHOLD= -120 dBm.
• Do a StartSynch at the moment the robot stops for SelectNewTarget. This works, until the robot leaves the room. The default threshold in Unreal is -93 dBm plus 6 dBm for each obstacle. When the robot leaves the room the signal level was around -90 dBm, so one extra obstacle would kill the signal.
• Tried to influence the signal with the ini-file, but it seems that I have to edit line 469 of ComServer.uc.

12 November 2007

• Looking if I could reproduce the Euros results with distributed manifolds. Spawned the CommStation at -20,16.75. Spawned Hercules in the NorthEast corner, but didn't receive any signal. Added debug-print in CommAgent::NotifySignalStrengthReceived.
• Problem was because Operator wasn't a Usar Operator, and because CreateCommActor was commented out in the CommAgent constructor (since version 767).

5 November 2007

• After a weekend hard working, we submitted a paper called Balancing information gain against movement costs for multi-robot exploration to Euros conference.
• Tried to commit the code on Shuttle, but first had to update FrontierExploration to version 822. This explains why some bugs that I thought were solved still occurred. Tested the merged code on NorthWestPower3.0, and it seems to work.
• This time Hercules is able to explore the 5th room and to get out (with a minor orientation error). Unfortunatelly, Achilles wasn't stopped when Hercules was thinking (continued driving). Result: Area 452.07 (before crash) / 497 (after crash) (8 Victims).
• Commited version 823. Inserted Thread.Sleep after PP, to allow free the CPU for other threads (i.e. control of Achilles). Set sleep initially on 250 milliseconds, but this can probably be reduced.
• Sleep seems to have no effect, all planning-prints are still after each other. The endless-loop occured. Added bestutil > 0.0 to While-loop. This seems to work. Had a good run (Area 549 (5 Victims), although at the end Hercules crashed unnecessary to a wall in the Yellow arena.

2 November 2007

• Run with Power 0.75 for single robot. Hercules explored the lobby, East corridor, North-West corridor. Result: [AREA] 755 1227.39 579.89 (6 Victims)
• Run with Power 0.5 for single robot. Hercules explored only half of the East corridor, but lost to many time in the lobby to come much further in the North-West corridor. Result: [AREA] 772 1253.81 556.08 (2 Victims)
• Run with Power 1.0 for single robot. Explored the South-East corridor and the first room of the Yellow arena. Result: [AREA] 655 1268.05 497.76 (4 Victims)
• Run with Power 1.5 for single robot. Explored the South-East corridor and the first room of the Yellow arena. Result: [AREA] 612 1231.73 494.42 (4 Victims)
• Run with Power 2.0 for two robots. Achilles explored the third room, and was able to come out, but with a rotational error. Result [AREA] 1481 1310.92 619.24 (8 Victims)
• Run with Power 1.5 for two robots. Only the first two rooms were explored. When leaving the second room a rotational error occured. Achilles explored the small corridor next to the cubicles. Result [AREA] 1471 1286.23 682.22 (5 Victims)
• Rerun with Power 1.0. Although the system crashed on a TCP-error 100 seconds for the end, the result seems to reproduce (Area 597).
• Rerun with Power 1.5, this time with GroundTruth. Maybe the large value is due to the rotational error. Result was even lower than before (Area 461) because Achilles fell halfway (Area 461).
• Rerun with Power 2.0 and GroundTruth. This time both robots are interfering with each other, exploring close to each other.
• Run with Power 2.5. Achilles got stuck in room 3, but the result is reasonable: Area 550.84 (6 Victims).
• Also with a single robot the results for Power 2.5 are good: Area 509.
• Run Power 2.0 with a single robot. Smooth run, but Area only 417.65. This poewer seems to be the minimum, not the maximum.
• Try Power 3.0 with a a single robot. Three minutes for the end the robot tumbelt in the room next to North-South corridor. Area 329. This values do reproduce. Why is Power 2.0 so sensitive?
• Run with Power 3.0 with two robots. Hercules tumbeled in room 5, but Achilles was able to navigate the room next tho the North-South corridor. Area 348 (6 Vicims).

1 November 2007

• Rerun of version821, with bestmember = 0.99*goodmember replaced by 0.9*goodmember. The original version is more conservative, but the second one is faster.
• Fixed bug in version822. Now the best and good are calculated for every agent after an assignment. Test failed due to failure in Tcp-connection. Log is OK for 900 seconds.
• Finally, we have a 'successfull' run. Hercules goes to the lobby, needs less then a minute to do path-planning on 10 frontiers, and explores the complete South-East corrdior. In the mean time Achilles explores the first three rooms, and gets stuck on the Victim. Result: [AREA] 1237 1088.56 520.7 (5 Victims), which is equivalent with the AMAI-paper.
• Rerun with Power 1.0. Hercules explores the complete the South-East corridor, and even reaches the Yellow Arena. Achilles explores the first two rooms and the complete East-Corridor. Result: Area 1454 1414.4 628.5 (6 Victims).
• Rerun with Power 0.5. Result: [AREA] 1476 1248.13 632.87 (7 Victims). Although this result is even better than the previous result, the behavior seems to be a little random, with robots going back and forth, and even heading towards the same frontier.
• Rerun with Power 0.75. Hercules went to the lobby, and tried to complete the loop. Hercules got stuck in the transit-room. In the mean time Achilles explored the first two rooms, the complete East-corridor and was already heading back for another job. Result: [AREA] 1266 1248.78 651.20 (4 Victims).

31 October 2007

• Morning started with a bug on the path-cache for the third team-member.
• Running with two robots works fine, until the first robot reaches the lobby. The order of checking of the frontiers is optimal for that robot, but anti-normal for the second robot. Result: [AREA] 809 1349.25 428.00 (4 victims)
• Each robot should check the most promissing frontiers first. Solution: first ordering the frontiers on Manhattan distance, followed by checking the PP-distance (in reversed utility order).
• After some debugging, finally had an operational version. After 15 minutes, two robots can still decide about which frontier to select. Example (Achilles in the East-corridor):
  • [Behavior] - 16 frontiers of size 1.00 m^2
  • [Behavior] - Manifold has a diagonal of 61.77 m
  • [Hercules] - Plan Path for Frontier of size 44.86 m^2 at distance 11.59 m
  • [Behavior] - Stop pathplanning at distance 37.02 m
  • [Hercules] - Best Frontier of size 44.86 m^2 at distance 11.60 m -> Utility 1.14
  • [Achilles] - Plan Path for Frontier of size 5.96 m^2 at distance 29.72 m
  • [Behavior] - Stop pathplanning at distance 11.44 m
  • [Achilles] - Plan Path for Frontier of size 18.23 m^2 at distance 20.96 m
  • [Behavior] - Stop pathplanning at distance 23.16 m
  • [Achilles] - Plan Path for Frontier of size 17.87 m^2 at distance 17.43 m
  • [Behavior] - Stop pathplanning at distance 25.96 m
  • [Achilles] - Best Frontier of size 17.87 m^2 at distance 33.80 m -> Utility 0.09
  Yet, it is strange that the frontier of 17.87 is selected. Anyway, the result is already good: [AREA] 1342 1207.02 571.75 (5 Victims) for Power 1.5
• Found the bug. The best frontiers were not found, because the upperbound was too tight. Based the upperbound on the second utility, and now it works fast and realable. Unfortunattely, Herculles crashed because the halt-command didn't reach the robot while planning in the lobby. Achilles continues without problems, but explores first room 3 before it continues in the corrodors. Result: [AREA] 1085 1200.25 437.33 (3 Victims). Achilles has some extra time left and continues in the North-West corridor: [AREA] 1113 1364.11 449.75 (4 Victims). Very promissing.

30 October 2007

• Should try run with distance only Utility, to compare with Yamauchi. With distance only (Area = 1 m^2, distance is Power 2.0) the first three rooms are explored (Victim in room 2&3). In room 3 the robot gets stuck under the table. Rerun after collision-avoidance is implemented.
• Rerun on Area only. Effect is nearly the same as Power 1.5, because only the last 10 frontiers are considered. After entering the corridor above the yellow arena, the robot heads back to the lobby (seems to be PP-error, not an assignment error), and again the corridor. After detecting the victim in that corridor, it decides to explore the yellow aren. Total [AREA] 741 1200.55 495.53 (5 Victims). Both runs were not on distance/Area only, because I changed the utility on one place only.
• Tried to merge version, but as a result I reverted to an older version. Rewritten SelectNewTarget, with an adaptive filter for large area's (based on 1/e principle). Rerun for Power 2.0 (Replanning after 4 meter):
  • Decision point before T-junction:
    • [Behavior] - 3 frontiers of size 8.23 m^2
    • [Behavior] - Calculate Utility for Frontier of size 46.25 at distance 11.06
    • [Behavior] - Better Frontier of size 46.25 m^2 at distance 11.10 m
    • [Behavior] - Calculate Utility for Frontier of size 44.23 at distance 9.97
    • [Behavior] - Better Frontier of size 44.23 m^2 at distance 10.00 m
    • [Behavior] - New Frontier Selected (-52.87 , 17.06)
    • [Behavior] - New Goal Position = (-43.50 , 17.10)
  • Decision point after T-Junction:
    • [Behavior] - 4 frontiers of size 8.23 m^2
    • [Behavior] - Calculate Utility for Frontier of size 53.13 at distance 11.71
    • [Behavior] - Better Frontier of size 53.13 m^2 at distance 12.50 m
    • [Behavior] - Calculate Utility for Frontier of size 11.24 at distance 4.84
    • [Behavior] - New Frontier Selected (-44.74 , 28.57)
    • [Behavior] - New Goal Position = (-47.00 , 17.50)
  • Decision point after entering Lobby:
    • [Behavior] - 6 frontiers of size 8.23 m^2
    • [Behavior] - Calculate Utility for Frontier of size 10.60 at distance 4.02
    • [Behavior] - Better Frontier of size 10.60 m^2 at distance 4.60 m
    • [Behavior] - Calculate Utility for Frontier of size 17.90 at distance 5.04
    • [Behavior] - Better Frontier of size 17.90 m^2 at distance 5.40 m
    • [Behavior] - New Frontier Selected (-49.83 , 33.45)
    • [Behavior] - New Goal Position = (-45.20 , 33.50)
  • Decision point after leaving Lobby:
    • [Behavior] - 5 frontiers of size 8.23 m^2
    • [Behavior] - Calculate Utility for Frontier of size 18.09 at distance 9.78
    • The thread 0xa4c has exited with code 0 (0x0).
    • [Behavior] - Calculate Utility for Frontier of size 38.00 at distance 16.77
    • [Behavior] - Better Frontier of size 38.00 m^2 at distance 22.30 m
    • [Behavior] - Calculate Utility for Frontier of size 11.24 at distance 9.66
    • [Behavior] - Calculate Utility for Frontier of size 30.86 at distance 15.34
    Unfortunatelly, the planning of those 5 frontiers takes a long time, and is directly repeated after the decision (create cash). [AREA] 370 963.89 401.24 9 (1 Victim)
• Implemented a upperbound for the pathplanning. Default is 20 meter, but with the utility I can calculate a more tight bound.
  • Decision point for the T-junction:
    [Behavior] - 4 frontiers of size 9.43 m^2 [Behavior] - Calculate Utility for Frontier of size 51.72 m^2 at distance 11.60 m [Behavior] - Stop pathplanning at distance 20.00 m [Behavior] - Better Frontier of size 51.72 m^2 at distance 12.30 m [Behavior] - Calculate Utility for Frontier of size 10.29 m^2 at distance 5.03 m [Behavior] - Stop pathplanning at distance 5.49 m [Behavior] - New Frontier Selected (-44.79 , 28.93) [Behavior] - New Goal Position = (-46.60 , 17.80)
• Upperbound seems to work, but sometimes still the utility with the non-existing path is selected. Added print-statements, and I store the best path for Agent1. The robot explores now the room after the North-South corridor, and the corridor above the yellow arena. At the entrance of the arena the system holds. Result: [AREA] 587 851.03 490.86 (3 Victims)
  Last correct decision point:
  • [Behavior] - 5 frontiers of size 9.22 m^2
  • [Behavior] - Calculate Utility for Frontier of size 49.21 m^2 at distance 11.40 m
  • [Behavior] - Stop pathplanning at distance 20.00 m
  • [Behavior] - Better Frontier of size 49.21 m^2 at distance 11.40 m -> Utility 0.38
  • [Behavior] - Calculate Utility for Frontier of size 37.76 m^2 at distance 8.51 m
  • [Behavior] - Stop pathplanning at distance 9.99 m
  • [Behavior] - Hercules-> Utility 0.38
  • [Behavior] - New Frontier Selected (-28.20 , 28.38)
  • [Behavior] - New Goal Position = (-39.10 , 28.40)
• Resolved the bug. Removed the largest area filter, because the system is now fast enough with pathplanning. Explored North-South corridor, entered the room next to the cubicles, bounced over victim. Due to the bounces, the room seemed to be closed, and path-planning couldn't find a solution any more. Result: [AREA] 773 1200.86 490.24 (2 Victims)
• Rerun with Power 2.5. Raised default to 80m. Now the 2th room and the room behind the North-South corridor is explored. When leaving the robot hits the corner, which block the North-East corridor, but still has enough time to reach the lobby: [AREA] 850 1200.06 453.32 (6 Victims).
• Rerun with Power 1.5. The robot explores the 5th room, because no path can be found into the huge free space behind the T-junction. Unfortunatelly, the victim in room 5 is not seen. After that the lobby and the South-West corner is visited. Result: [AREA] 813 1203.42 500.45 (2 Victims). Even after 20 minutes the number of frontiers is managable:
  • [Behavior] - 4 frontiers of size 10.28 m^2
  • [Behavior] - 12 frontiers of size 1.00 m^2
  Of those 12 frontiers, 3 are so closeby (in Manathan distance) that path-planning is tried:
  • [Behavior] - Calculate Utility for Frontier of size 3.37 m^2 at distance 7.45 m
  • [Behavior] - Better Frontier of size 3.37 m^2 at distance 16.20 m -> Utility 0.05
  • [Behavior] - Calculate Utility for Frontier of size 9.85 m^2 at distance 7.24 m
  • [Behavior] - Better Frontier of size 9.85 m^2 at distance 7.20 m -> Utility 0.51
  • [Behavior] - Calculate Utility for Frontier of size 60.21 m^2 at distance 10.41 m
  • [Behavior] - Better Frontier of size 60.21 m^2 at distance 16.50 m -> Utility 0.90
  • [Behavior] - Hercules-> Utility 0.90
• Rerun with Power 1.0. No room is visited, robot ends at the end of the South-East corridor. Result: [AREA] 603 1104.95 473.71 (3 Victims).
• Created GUI textbox for PowerLaw (version 816). Tested with Power 3.0. Agent directly explores room 1 and 2. Continues in the room behind the North-South corridor. Result [AREA] 817 1201.19 328.22 (5 Victims).
• Run with 2 Agents (Hercules -21.5,17.5,+3.3; Achilles -21.5,16,-3.3). Started Achilles when Hercules travelled 4m. Assignment seems to work, although both stay in the corriodor:
  • [Behavior] - 2.00 PowerLaw
  • [Behavior] - 2 frontiers of size 8.38 m^2
  • [Behavior] - 4 frontiers of size 1.00 m^2
  • [Behavior] - Calculate Utility for Frontier of size 4.97 m^2 at distance 1.77 m
  • [Behavior] - Stop pathplanning at distance 80.00 m
  • [Behavior] - Better Frontier of size 4.97 m^2 at distance 1.80 m -> Utility 1.53
  • [Behavior] - Calculate Utility for Frontier of size 4.97 m^2 at distance 3.91 m
  • [Behavior] - Stop pathplanning at distance 80.00 m
  • [Behavior] - Better Frontier of size 4.97 m^2 at distance 3.80 m -> Utility 0.34
  • [Behavior] - Hercules-> Utility 1.53
  • [Behavior] - Achilles-> Utility 0.16
  After Hercules-tick 102 No New Goals are set. Last goals for Herc (-36.30 , 17.00),(-36.10 , 17.00),(-35.80 , 17.00) and for Achilles (-26.00 , 16.30). Maybe due to an unclean Manifold. A retry (with Power 1.5), showed the same behavior, only now a little bit late. Hercules is circling at the T-junction, Achilles in a corner of room 1. After stopping Achilles, Hercules receives again Goal-positions and explores again. Result: [AREA] 783 1203.17 416.12 (2 Victims). I should use a different machine for the server and the manifold.
• At home, with the Shuttle, two Agents work fine. With Power 2.0, the first two rooms are explored. After that Achilles have to wait for a few minutes, because only one frontier is visible. As soon as room 3 is seen, Achilles goes in and is not able to get out anymore. Result: [AREA] 1383 1200.17 506.55 (5 Victims).
• Gave Theseus its own path-cache, and run with three Agents. At the beginning they move, but at the end they freeze. In the beginning Theseus and Achilles are in each other way. [AREA] 1405 816.20 414.09

29 October 2007

• There was a large difference between the Manhattan distance and the path-plan distance. At time 347 the difference was 20 vs 80, 16 vs 64, 7 vs 26. Added an bracket to be sure that the grid scale was divided from the distance (and not the exponent). Still, there was a large distance, while the number of steps in the path seems to be a good estimator (and easier to compute). Used the path.length in the Utility-function and the behavior directly changes (with Power 2.0 the second room and the North-South corridor is explored). Result, [AREA] 435 1072.14 388.57 after 897 ticks. Much more area is explored until tick 1182, but no [AREA] is printed.
• Added print after 1200 secs. Rerun with Power 3.0. Now the first two rooms are explored, and the room behind the North-South corridor. [AREA] 741 1201.02 333.60 (4 victims).
• Rerun with Power 1.0. Skipped the rooms, and directly headed into the North-South corridor. Unfortunatelly, it collided against the wall (thinking and driving at the same time?). [AREA] 231 1258.02 346.84 (2 victims).
• Rerun with Power 1.5. Now the robot goes directly to the lobby. At the lobby the next decision is made:
  
  • [Behavior] - Calculate Utility for at distance 26.15
  • [Behavior] - Better Frontier with 9.36 m^2 area at distance 37.70 m
  • [Behavior] - Calculate Utility for at distance 28.97
  • [Behavior] - Calculate Utility for at distance 23.71
  • [Behavior] - Calculate Utility for at distance 18.93
  • [Behavior] - Calculate Utility for at distance 19.92
  • [Behavior] - Better Frontier with 27.27 m^2 area at distance 25.70 m
  • [Behavior] - Calculate Utility for at distance 14.65
  • [Behavior] - Better Frontier with 37.63 m^2 area at distance 19.30 m
  • [Behavior] - Calculate Utility for at distance 1.96
  • [Behavior] - Better Frontier with 31.58 m^2 area at distance 1.50 m
  Unfortunatelly, there are so many options that the robot cannot choose anymore. Last update [AREA] 267 620.45 373.59
• Reversed searching order (latest frontiers first), and limited search to 10 latest frontiers. Result is much faster. Only at the lobby still the result is still strange. It finds a good frontier, but doesn't assign that frontier, and starts recalculating.
• Stored the best path, to prevent planning the same path twice. Result for Power 1.5 is very good: [AREA] 535 1213.61 483.68
• Rerun for Power 2.5. Second room (with Victim) is explored, and the room behind the North-South corridor (2 Victims). Total: [AREA] 780 1211.98 388.51 (4 Victims)

26 October 2007

• Changed in SelectNewTarget the path back from the border towards the center. Got an error about number of Manifold.observers changing (both on pc-vlab10 and pc-unreal).
• Version 808 works, so there is a bug in the 809-code. For Power 2.0 the result is after 15minutes [AREA] 518 820.67 407.44, 18 minutes [AREA] 543 995.61 416.72
• Updated only FrontierExploration, FrontierInfo and FrontierTools to 809. This works, but the robot only turns around in front of the second chamber.
• Changed back to path towards center (on two places). SafeSpaceLayer contains my attempt to paint the new path, so can be ignored. TeleOperation contains the bug-fix I found, so should be included. Now got an error in ExtractFrontierBorders (Parameter unknown). In the previous run there was still a breakpoint in SelectNewTarget. With a breakpoint the code works. A second time the code also works without breakpoint. With Power3.0, the first chamber is explored. The run ends in the narrow corridor (on its side) [AREA] 532 1253.44 424.62.
• The change in MotionControl is a Public ActiveMotions. The change in BehaviorControl is a Public CurrentBehavior. Can both be ignored. BehaviorAgent contains a new constructor(Agent). Agent contains a new member AgentConfig, needed by BehaviorAgent. Seems that only SafeSpaceLayer is to be distrusted.
• Made the run on pc-vlab10, with only SafeSpaceLayer v808 (+path to center). That works. Last Area report at time 372 (-54.06, 16.72) [AREA] 206 3791.47 284.42. No collision this time, because on the slower machine the robot comes less far.
• Created ProcessStatusData to DeActivateAllMotions when the Battery < 1. Rerun with Power 2.0.

12 October 2007

• Tried to connect UsarCommander (v671) from nb-avmovie@decis to pc-unreal@uva. I could ping to 146.50.1.149, but couldn't telnet to port 3000 (UsarSimServer).

11 October 2007

• Tried to implement path to frontier and not region, but the result was very strange. Should draw current path, but it was not easy to make the motion of an agent available to the manifold. Better make a virtual sensor from the motion, and give a NotifyUpdate.

10 October 2007

• Implemented utility-function based on path-distance. For each robot the best utility-value is remembered. When the utility, as calculated on the Eucledian distance, is better than the previous value, the utility is recalculated on the path-distance. The path distance is typically twice as large as the Eucledian distance.
• For the NE-position this leads to nice greedy behavior. At the T-junction both options look equal. The robot continues to explore the North-corridor. After the second victim another decision is made, again to continue in the North-corridor. Nearly on the end it is clear that the corridor has an dead-end, and the room with the step-field is explored. Unfortunatelly, the robot doesn't continue around the corner, but heads back towards the next room. After a small collision the position is wrong, and path through walls are planned.
• Tried the same run, now with GroundTruth-seed. Still, the path-planner returns strange paths, with a lot of turning at the beginning. In the room with the step field, such a strange turn results in a encounter with the step-field. The time is up before the survey can be continued. Result: [AREA] 723 2439.98 347.33
• Tried the same run with Power 1.0. Result was a continues turning in the end of the North-corner. This was a bug. With the new code the robot takes the small corridor south. The path is too long, and the robot hit the wall. [AREA] 413 674.22 397.41 (with still 6 minutes to go).
• Repeating the run with Power 3.0 has direct effect, because now the first room is explored, and not the corridor. The north-corridor is followed, but after the second victim the north corridor of the cubicle world is chosen. At the end of this corridor is a victim, which plays as a stepfield. [AREA] 663 1198.84 406.74
  
  

9 October 2007

• Tried to reproduce exploration-results of Bayu. Started with DM-compWorldDay4b_250.bat. Started at position8, which is -20,27,-4. This is at the end of the corridor above the Yellow Arena (SouthEast). Tried different rotations. After rotation -1.57 (collision with victim), -0 (no progress), I got the robot moving with rotation +0.8 (robot stopped at the middle of the lobby.
• Tried position3, which is -20,17.5,-4. This is the upper-right corridor (NorthEast).With orientation +1.2 the robot is just looking at the south-wall (stuck). With rotation 0 the robot is looking at the end of the corridor. With orientation +1.57 the robot turns into the corridor, and starts exploring (very close to the wall, resulting in a collision). With orientation -3.0 the center of the corridor is reached. The result with is QWSM is suboptimal. With plain WSM the result is much better.
  
  The robot explores the top corridor, until the second victim. The room below looks more interesting (close Eucledian distance), and partly explored. The NorthSouth is closeby, so Hercules enters this corridor, continues into the lobby, enters the SouthEast corridor. The robot realizes that it has forgotten the small room before the lobby (closeby in Eucledian distance), goes back and enters the East corridor. Halfway it realizes its mistake and returns to the NorthSouth corridor again, but now the time is up.
• Conclusion:Really needs path distance before optimizing on power-law. Probably the best solution is to freeze the slowly (larger distance sensitivity at the end of the run).

4 October 2007

• Looked at utility-function as used in AutonomousExploration. This utility-function can be found in FrontierExploration:SelectNewTarget(). The distance is based on the metric distance, not the path-distance (sensitive to obstacles).

2 August 2007

Looked at the statistics collected from the Park runs by Bayu. Made a histogram of the trace-distance, because a average tracedistance of 13 meter for WSM seems to be quite large. Yet, the histogram revealed that this is not due to outliers, but that the bulk is really shifted an order of 100:

25 July 2007

• Bayu suggested to look at AP Hill dataset. Howard published with this dataset (and SDR, more a corridor-scenario). Unfortunatelly, both datasets are in Player format, so the lineparser has to be implemented first.
• Started in the mean time with the FR079 dataset of Cyrill Stachniss. Last year the results were already promissing, so I was interested what the QuadTree algorithms would make from it. WSMQ60cm performed well until the messy rooms at the end. ICP100cm already made an orientational error at the first turn in the corridor. The same error is made with the messy rooms at the end (while this is the corrected log). Both runs were performed with a max range of 20m, while the dataset was recorded with the max range of the laser scanner set on 80m. The central corridor is 40m long. Select as robot Hummer to get a max range of 79m.
• Implemented the lineparser for the Player format. Initial results IDCQ100cm look reasonable, but the robots get lost in the large room. Using a Hummer does help, the map generated with WSMQ60cm contains an error of a few degrees (originating from standing still in the corridor while people/robots are moving around), which is corrected when the big hall is visited for the second time):
  
  The logfiles intel1 and intel2 go less well. Intel1 builds orientation error on orientation error (45deg, 90deg, 100deg, 110deg). Intel2 makes an initial error of a few degrees, is stable in the small rooms, but makes a big mistake (90deg) before it enters the large hall.
• The results of Intel3 are again encouraging. Although an initial rotation is build up with turning in the lower hallway, followed by a tour through the small rooms, the total error is only 30 degrees when the large hallway is entered, and the system is thereafter accurate for quite a long time.
• The previous runs were unfair, because I didn't restarted UsarCommander. Without a restart the scan-matcher us es also the previous quadtrees to localize. Intel3 doesn't make the initial orientation error anymore. In the large hall a small rotational error is introduced, but the result is rather good (without loop-closing):
  
  
• The NSH dataset was run with reduced scanrange of a Hokuyo (4m). With the normal indoor SICK scanrange (19m), the result is perfect:
  
  

24 July 2007

• Compared the BigLoop map (purely based on odometry) with the video made with the omni-directional camera:
  
  After seeing the video, it is clear that the robot starts at the entrance of the ping-pong room, in the corridor. After a loop through the NikHef building, the robot returns precisely at that location, and continues to the Institute's hall. The long corridor at the top should be rotated 45 degrees, and the side corridor should fit at the start at the origin. Unfortunatelly, this rotation error originates at the assembly hall at the lower right side, where there is not enough laser-scan information to correct this error.
• Rerunning Quad IDC with different settings for the MAX_CORRELATIONDISTANCE resulted in the perfect map for the Preliminary2-run. A value of 50cm resulted in an orientation error in precise the opposite direction as the orientation error at a value of 200cm. A value of 100cm resulted in the following map:
  
  
• Also did a parameterscan for the Weighted Scan Matcher. For values of 75cm and 100cm resulted in wrong localizations at the start-position. Between 40cm and 66 cm the results where reasonable, with as best result the MAX_CORRELATIONDISTANCE at 50cm.
• Inspired by the article SLAM with sparse sensing, a tried the different algorithms on the Newell-Simon Hall Level A at CMU dataset. The results for WSMQ with MAX_CORRELATIONDISTANCE at 40cm are not bad (2 meter error after 114 meter loop, no loop-closure, several corridors without features):
  
  
• Also experimented with MAX_CORRELATIONDISTANCE for the Quad IDC at home. Changed the value from 200cm to 6.25cm. What clearly can be seen from this experiment, is the problems the scan-matcher has in these corridors. The odometry is used as seed to start the iteration at the correct displacement. The scan-matcher realises that both walls fit perfectly, only except that there are a few new points. The scan-matcher moves back and everytime the fit is sligthly better. The result is that the scan-matcher underestimates the displacements in new corridors. When the robot turns, and travels through a kwown corridor, this underestimation doesn't occur. Dependent on the MAX_CORRELATIONDISTANCE, I could place the side-corridor of the Newell-Simon Hall 6 to 200cm behind the door of the inititial room. This fenomen cannot be solved by scan-matching, because the correspondence is OK. It should be solved in the update-rule of the position, where the scan-matcher is used for the orientation and the odometry for the displacement. Different project.

23 July 2007

• Tested the new quadTree code on Day4. The quadIDC starts great, which a sharp car and straight wall behind the car. Only at the end the algorithm accepts a wrong orientation, which destroys the whole map. The quadWSM makes an early orientation error while bumbing to the car, but the final map is better. Other options are equal or worse:
  
  

19 July 2007

• Result does not improve with MultiICP for the BigLoop:
  
  Hopefully the MbWSM gives better results. Anyway, the dataset is challinging enough to see differences between the scan matching algorithms. Hopefully these differences remain after odometry is added.

18 July 2007

• Collected the odometry data of the tape-loop. Also inspected the actually loop. A possible difficulty is that on one side the robot is passing a staircase, which will not give distance measures depending on height.
• Started to analyze the other BigLoop datafile. Initial results look promising:
  
  
  
  
  
• Analysis of this first run: The robot starts in the ping-pong hall, goes into the Nikhef-corridor, makes a full circle around the stairs (same location as the tapeLoop), turns towards the Technical Services (doesn't explores the two side-corridors at the end). Returns back to the stairs and enters the Mechanical Workshop. In the huge assembly hall the location and orientation is lost. From the assembly hall one travelles towards the reception (overlapping parts). The map is understandable again after returning in the hallway back to the Informatics Institute. Halfway a side-turn is made towards the ping-pong hall, but this hall doesn't seem to be entered. The voyage continues in the direction of the Institute hall. Also in this large hall it is difficult to localize. Inside the hall the back of the chairs and the table legs are clearly visible.
• Observations: Most parts of the map are understandable. The map is mirrored, so we should reverse the scanning direction. The loss of location in the assembly hall is not surprising, considering the size of that hall compared with the max-range of 4 meter of the Hokuyo. The Hokuyo returns 0.0 instead of the max-range, which results in unknown space in front of the robot. This keeps the map clean, but is difficult when driving on frontiers. The robot does not return on its initial position, but this can be explained with the difficulties in the assembly hall, reception and Institute hall. Falling back on odometry when the scan-matchers fail will (hopefully) solve this issue. A more difficult issue will be accurate estimates of travelled distances in the long corridors. When not enough distinctive features are visible (closed doors), only the orientation is fit.

17 July 2007

• Asked Olaf about Hukoyu data-sets. Recently, two data-sets were recorded in the NikHef-building. The first one is a small loop, travelled five times. The second is a large loop (132 Mb on lasermeasurements only). The small loop was generated especially to test the SLAM-algorithm. The odometry was fooled with a tape on one of the weels:
• Commited version 697, which could read dataset. The result is not impressive (robot doesn't seem to move), but this is actually correct. Only after 3 minutes the robot starts to move. The IDC cannot match this scan, WSM is able to proeess this data partially. Difficulties remain the corners, where not enough points are available for a reliable match. The localization should rely on odometry on this situations.

3 July 2007

• Chosen Chartreuse (RGB #7FFF00) as path-colour, because a path is per definition cleared. Cleared is indicated in the green channel #00FF00, the path should be indicate with a shade of red (< #FF0000). They specified that the red has to be between 120 and 130, and 7F is equal to 127. The result looks nice, the path is clearly visible, but only when you take notice of it:
• Used most of the morning to reproduce the error in the ManifoldView. The problem is that although the wireless seems to work, the sensor data doesn't reach the operator window. The machines in Atlanta have this problem, while Bayu hasn't. Created a sandbox of old revisions, but the error remained. Using a clean install of Bayu's latest seem to solve it.
• During setup the Manifold worked fine. Unfortunately, at the real start it happened again. Restarting the interface solved this. Now another problem appeared. The robots were so busy sending sensor-information, that no steering commands could reach the robots any more. The result was that the robots never stopped turning.
• Inspected the apriori-loading problem. All version between 623 and 632 could load the file. Loaded the apriori-file of day3, which is huge. On pc-unreal it takes a minute. Looked at the loading-code if the apriori-image could be further reduced. This was not possible. Bayu used a nice and dirty trick. The apriori-image was reduced by creating a thumbnail-image from it from the same size. The article compares GetThumbnailImage against Scaling the image. Thumnail images are 10 times as small (and 10 times as ugly) as using official scaling. Because the quality is not important for us, this helps a lot to reduce the image to a smaller size with the same scale.

1 July 2007

• Tried to make GeoTiffViewer from src, but qmake didn't want to be in the PATH, could find its QMAKESPECS, couldn't read -spec e:\qt-4.1.3\mkspecs\win32-msvc2005\qmake.conf and couldn't process geoTiffViewer.pro. The qt was clearly an copy from pc-ias, because it was refering to d:. Tried to solve it with defining QTDIR, but didn't help. Removed references to qt and gdal from my environment, also doesn't help. Give up.

1 July 2007

• Sonar:
  • P2AT heeft F1-F8 en R1-R8
  • P2DX heeft alleen F1-F8
  • ATRVJr heeft S1-S17
  • Kurt2D heeft er maar een Front (is dit een fout, alle andere sensoren zijn IR)
  • Kurt3D heet de Front-sensor sensor1
  De rest van de robots heeft geen sonar.
• Installed UsarSim v3.13 on faro-mob. First attempt on to spawn one ComStation, a Talon and a P2AT failed. ComStation was not physically spawned in UsarBase mode. The Talon was spawn as UsarOperator (Spawn from UsarCommander is on).
• Second try, with ComStation as UsarOperator, Talon as UsarBase and P2AT as UsarSLAM failed also. All robots died, so maybe there is something wrong with the start-location of the Mobility world. In the Mapping world it went better, although three agents is too much for one machine (the third one was jumping).
• Moved the P2AT from 1.748, -5.782, -0.446 to 1.748, -6.782, -0.446
• This worked, but only after I first started the P2AT followed by the Talon. Running an agent on the server dropped the performance to 2 FPS. Running all agents remotely helped partly (4 FPS). The server still had the original UsarBot.ini. With the new UsarBot.ini the performance increased to 10 FPS. In client mode, with moving victims, it dropped again to 7 FPS. Just before we had to leave the building, testing on the competition-servers showed a performance of 30 FPS.
• Added ComStation to UsarBot.ini. Tried to put the camera on top, but adding a camera resulted in jumping.
• Created config-files and script-files for the competition tomorrow.
• Installed Global Mapper and GeoTiffViewer.

Labbook 2007

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

Labbook 2006

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

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