From: Deepak R. <dra...@ui...> - 2007-10-31 21:49:39
|
Hi Richard, I tried setting interval_real to 0 and various values less than 100 and it seems to make no difference. If I try changing interval_sim to 0 or a low value however, it has the expected effect (the simulation stops running or crawls). So I dont think I'm doing it wrong. Do you think this could be a bug in version 2.0.4? Or do you think that the simulation is running as fast as it can go (with default settings 100 ms for both sim and real)? My computer is pretty fast. Here's a copy of the world file I'm using: # Desc: World file for the delivery task. Works with delivery.cfg. # the size of a pixel in Stage's underlying raytrace model in meters resolution 0.0365 interval_sim 100 # milliseconds per update step interval_real 10 # real-time milliseconds per update step gui_interval 0 # real-time milliseconds per update step # defines Pioneer-like robots include "pioneer.inc" # defines 'map' object used for floorplans include "map.inc" # defines the laser model `sick_laser' configured like a Sick LMS-200 include "sick.inc" size [40 20 ] gui_disable 0 gui_interval 0 gui_menu_interval 20 window( size [ 1895.000 1125.000 ] center [-0.278 0.689] scale 0.013 ) map( bitmap "honda1-widerdoorways.png" map_resolution 0.035 size [18 12] name "office" ) # a block for gripping define puck model( size [ 0.08 0.08 ] gripper_return 1 gui_movemask 3 gui_nose 0 fiducial_return 10 ) puck( name "obj1" pose [-5.022 3.903 -105.501 ] color "cyan" ) #puck( name "obj2" pose [2.512 -2.010 -37.717 ] color "yellow" ) #puck( name "obj3" pose [-1.404 1.027 -461.643 ] color "magenta" ) # extend the pioneer2dx definition from pioneer.inc # define trickedoutpioneer pioneer2dx ( sick_laser( fiducialfinder( range_max 8 range_max_id 5 ) ptz( blobfinder( channel_count 6 channels [ "red" "green" "blue" "cyan" "yellow" "magenta" ] ) ) ) fiducial_return 1 gripper_return 0 localization "gps" localization_origin [ 0 0 0 ] bumper( bcount 3 blength 0.2 bpose[0] [0 -0.165 90] bpose[1] [0 0.165 -90] bpose[2] [-0.26 0 0] blength[2] 0.1 # set the length of a single bumper ) ) trickedoutpioneer ( name "robot1" pose [0.079 -1.903 -0.566] gripper( pose [0.200 0.000 0.000] color "gray" ) speech() ) position( name "John" sick_laser( fiducialfinder( range_max 8 range_max_id 5 ) ptz( blobfinder( channel_count 6 channels [ "red" "green" "blue" "cyan" "yellow" "magenta" ] ) ) ) size [0.3 0.3] pose [5.000 2.500 0.000] color "red" # loads a bitmap for the model's body bitmap "person_blue.png" fiducial_return 22 velocity [0.2 0 0] laser_return 2 gui_outline 0 gui_nose 0 gui_grid 0 gripper_return 1 ) ~Deepak *************************************** Pattern-recognition development analyst Dr. Janice Wunderling said the MIT team has placed its AI projects on hold pending the completion of a comprehensive feasibility study on the threat of "humans being imprisoned in tiny, slime-filled cyber-canisters." --The Onion, Jan 21, 2004 |
From: Richard v. <va...@cs...> - 2007-10-31 22:10:39
|
I haven't heard from anyone that Stage-2.0.4 will not speed up a bit by dropping interval_real. Try it out with worlds/simple.world and see if it does what it should there. The way to test if Stage is going as fast as it can is to look at the CPU utilization of Player (or whatever program is using libstage). If Stage is using lots of CPU (80%+) then it's probably going as fast as it can. This happens quite quickly when using the blobfinder and laser, as they are very raytrace intensive. Unfortunately the Stage-2.0 raytracing implementation is not very fast. The next release will improve that very considerably, and I'm working hard to get that out to you ASAP. Richard/ On 31-Oct-07, at 2:49 PM, Deepak Ramachandran wrote: > Hi Richard, > > I tried setting interval_real to 0 and various values less than > 100 and it seems to make no difference. If I try changing > interval_sim to 0 or a low value however, it has the expected > effect (the simulation stops running or crawls). So I dont think > I'm doing it wrong. Do you think this could be a bug in version > 2.0.4? > Or do you think that the simulation is running as fast as it can go > (with default settings 100 ms for both sim and real)? My computer > is pretty fast. > > Here's a copy of the world file I'm using: > > # Desc: World file for the delivery task. Works with delivery.cfg. > > # the size of a pixel in Stage's underlying raytrace model in meters > resolution 0.0365 > > interval_sim 100 # milliseconds per update step > interval_real 10 # real-time milliseconds per update step > gui_interval 0 # real-time milliseconds per update step > > > # defines Pioneer-like robots > include "pioneer.inc" > > > # defines 'map' object used for floorplans > include "map.inc" > > > # defines the laser model `sick_laser' configured like a Sick LMS-200 > include "sick.inc" > > > size [40 20 ] > > gui_disable 0 > gui_interval 0 > gui_menu_interval 20 > > window( > size [ 1895.000 1125.000 ] > center [-0.278 0.689] > scale 0.013 > ) > > map( > bitmap "honda1-widerdoorways.png" > map_resolution 0.035 > size [18 12] > name "office" > ) > > # a block for gripping > define puck model( > size [ 0.08 0.08 ] > gripper_return 1 > gui_movemask 3 > gui_nose 0 > fiducial_return 10 > ) > > puck( name "obj1" pose [-5.022 3.903 -105.501 ] color "cyan" ) > #puck( name "obj2" pose [2.512 -2.010 -37.717 ] color "yellow" ) > #puck( name "obj3" pose [-1.404 1.027 -461.643 ] color "magenta" ) > > > # extend the pioneer2dx definition from pioneer.inc > # > define trickedoutpioneer pioneer2dx > ( > sick_laser( > fiducialfinder( range_max 8 range_max_id 5 ) > > ptz( > blobfinder( > channel_count 6 > channels [ "red" "green" "blue" "cyan" "yellow" "magenta" ] > ) > ) > ) > > fiducial_return 1 > gripper_return 0 > > localization "gps" > localization_origin [ 0 0 0 ] > > bumper( bcount 3 > blength 0.2 > bpose[0] [0 -0.165 90] > bpose[1] [0 0.165 -90] > bpose[2] [-0.26 0 0] > > blength[2] 0.1 # set the length of a single bumper > ) > ) > > trickedoutpioneer > ( > name "robot1" > pose [0.079 -1.903 -0.566] > > gripper( pose [0.200 0.000 0.000] color "gray" ) > speech() > ) > > position( > name "John" > > sick_laser( > fiducialfinder( range_max 8 range_max_id 5 ) > ptz( > blobfinder( > channel_count 6 > channels [ "red" "green" "blue" "cyan" "yellow" "magenta" ] > ) > ) > ) > > size [0.3 0.3] > pose [5.000 2.500 0.000] > color "red" > # loads a bitmap for the model's body > bitmap "person_blue.png" > fiducial_return 22 > velocity [0.2 0 0] > laser_return 2 > gui_outline 0 > gui_nose 0 > gui_grid 0 > > gripper_return 1 > ) > > > ~Deepak > *************************************** > Pattern-recognition development analyst Dr. Janice Wunderling said > the MIT team has placed its AI projects on hold pending the > completion of a comprehensive feasibility study on the threat of > "humans being imprisoned in tiny, slime-filled cyber-canisters." > > --The Onion, Jan 21, 2004 > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a > browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users |
From: Reed H. <re...@mo...> - 2007-11-05 20:50:37
|
Richard vaughan wrote: > This happens quite quickly when using the blobfinder and > laser, as they are very raytrace intensive. Unfortunately the > Stage-2.0 raytracing implementation is not very fast. The next > release will improve that very considerably, and I'm working hard to > get that out to you ASAP. In what ways is it different? I have made various optimizations to Stage 2, but nothing major [will release source code with next MobileSim release]. I started working on a bigger change but ran into a few issues and so decided to wait until after Stage 3... Top three functions according to gprof are stg_cell_locate and _itl_collect_matching of course. Also stg_rtk_fig_polygon_calc, which I haven't looked at yet. stg_matrix_lines too. Most raytraces could take advantage of the tendancy for locality, right? So my thought was that you could start the raytrace in the source's cell or in the cell where a previous hit was found (e.g. in the case of the laser), but I need to understand a bit better how the quad tree works (kept crashing in an unreproducable way... I think there's a bug in walking "up" the tree... need to look into it more). We're currently up to 40-50 robots in constant motion and constant reading/writing of various properties, each with a simulated SICK at 32m range and half-angle precision (so that's 360 raytraces per) (plus some randomness that original libstage doesn't do), 2cm matrix resolution, and 150ms/150ms real/sim intervals on a 3Ghz machine, and are near the CPU limit (also the network's limit, since the rest of the software is on different computers). My immediate goal is 65, then 100-125 or so. What's the largest number of robots anyone has run in Stage at real time? (Well, I've run 200 but that was with a significant sacrifice in performance, though still sort of functional.) Reed |