From: Aslund <seb...@gm...> - 2010-09-20 08:22:15
|
Hey everyone I am working on implementing some path planning and for that I need a map. I have read about how to use writelog and pmaptest to create a grid map, but sadly I am unable to produce any data in my logs. I hope someone can see where I go wrong. When I run player on my robot, then I get the following message: ------- Adding position2d interface. Configuring Roboteq serial port at /dev/ttyS0 Computed maximum forward velocity of 0.870628 m/s. Computed maximum rotational velocity of 3.414229 rad/s. listening on 6665 Listening on ports: 6665 AX2500 found. Encoder present. Short circuit detection capable. warning : unable to get position geometry ------ When I try to get the log while I move around with PlayerView, then pmaptest gives the following output with the generated logfile; ------ aslund@SDURobot:~$ pmaptest --grid_scale 0.05 mydata2010_09_17_13_24_16.log range_count = 489 range_max = 5.600000 angle_min = -1.500000 angle_max = 1.500000 angle_step = 0.006136 allocating 8192 bytes for scans allocating 607 Mb of map space (estimated lower bound) 0.000 m 0.000 rotations 0 scans 0 steps in 0 seconds -nan msec/scan -nan msec/step ------ My .cfg file is this: ------ driver ( name "hokuyo_aist" provides ["ranger:0"] portopts "type=serial,device=/dev/ttyACM0,timeout=1" min_angle "-1.5" max_angle "1.5" ) driver ( name "rangertolaser" requires ["ranger:0"] # read from ranger:0 provides ["laser:0"] # output results on laser:0 ) driver ( name "roboteq" provides ["position2d:0" "power:0"] devicepath "/dev/ttyS0" motor_control_mode "197" invert_directions "true" encoder_ppr "1024" wheel_circumference "1.28" axle_length "0.255" gear_ratio "7.742" ) driver ( name "writelog" log_directory "/home/aslund" basename "mydata" requires ["laser:0" "position2d:0"] provides ["log:0"] alwayson 1 autorecord 1 ) ------ Thanks for your help. Sebastian Aslund |
From: Aslund <seb...@gm...> - 2010-09-20 13:07:53
|
Hey I have tried to look into the code an apparently writelog is unable to get any geometry information, but when I look at the Roboteq driver, then it updates the geometry if it register encoders, which it does. So if the roboteq driver publishes position2D information, then why cant writelog not read them? Sebastian On 20 September 2010 10:22, Aslund <seb...@gm...> wrote: > Hey everyone > > I am working on implementing some path planning and for that I need a map. > I have read about how to use writelog and pmaptest to create a grid map, but > sadly I am unable to produce any data in my logs. I hope someone can see > where I go wrong. > When I run player on my robot, then I get the following message: > ------- > Adding position2d interface. > Configuring Roboteq serial port at /dev/ttyS0 > Computed maximum forward velocity of 0.870628 m/s. > Computed maximum rotational velocity of 3.414229 rad/s. > listening on 6665 > Listening on ports: 6665 > AX2500 found. > Encoder present. > Short circuit detection capable. > warning : unable to get position geometry > ------ > > When I try to get the log while I move around with PlayerView, then > pmaptest gives the following output with the generated logfile; > ------ > aslund@SDURobot:~$ pmaptest --grid_scale 0.05 > mydata2010_09_17_13_24_16.log > range_count = 489 > range_max = 5.600000 > angle_min = -1.500000 > angle_max = 1.500000 > angle_step = 0.006136 > allocating 8192 bytes for scans > allocating 607 Mb of map space (estimated lower bound) > 0.000 m 0.000 rotations 0 scans 0 steps in 0 seconds > -nan msec/scan -nan msec/step > ------ > > My .cfg file is this: > ------ > driver > ( > name "hokuyo_aist" > provides ["ranger:0"] > portopts "type=serial,device=/dev/ttyACM0,timeout=1" > min_angle "-1.5" > max_angle "1.5" > ) > > driver > ( > name "rangertolaser" > requires ["ranger:0"] # read from ranger:0 > provides ["laser:0"] # output results on laser:0 > ) > > driver > ( > name "roboteq" > provides ["position2d:0" "power:0"] > devicepath "/dev/ttyS0" > motor_control_mode "197" > invert_directions "true" > encoder_ppr "1024" > wheel_circumference "1.28" > axle_length "0.255" > gear_ratio "7.742" > ) > driver > ( > name "writelog" > log_directory "/home/aslund" > basename "mydata" > requires ["laser:0" "position2d:0"] > provides ["log:0"] > alwayson 1 > autorecord 1 > ) > ------ > > Thanks for your help. > > Sebastian Aslund > |
From: Rich M. <jp...@gm...> - 2010-09-20 13:42:46
|
Hi, Geometry is different from Odometry. When writelog starts up, it sends a PLAYER_POSITION2D_REQ_GET_GEOM to the position2d devices its logging. The roboteq driver doesn't have any code to handle this request, so ProcessMessage returns -1 and the request is not fulfilled. The geometry request is used to convey the overall size of the robot; whether or not it makes sense to handle requests like that from the Roboteq driver is questionable (maybe via an optional tuple in the config file?) As far as pmap goes, check to see that logfile.h/cpp (called from pmap_test.cc) are reading the correct tokens out of your logfile. A cursory look at the code indicates that if you're only getting the following message once is probably having trouble reading from your log file. 0.000 m 0.000 rotations 0 scans 0 steps in 0 seconds -nan msec/scan -nan msec/step Rich From: Aslund [mailto:seb...@gm...] Sent: Monday, September 20, 2010 9:08 AM To: pla...@li... Subject: Re: [Playerstage-users] Problems with writelog and position geometry Hey I have tried to look into the code an apparently writelog is unable to get any geometry information, but when I look at the Roboteq driver, then it updates the geometry if it register encoders, which it does. So if the roboteq driver publishes position2D information, then why cant writelog not read them? Sebastian On 20 September 2010 10:22, Aslund <seb...@gm...> wrote: Hey everyone I am working on implementing some path planning and for that I need a map. I have read about how to use writelog and pmaptest to create a grid map, but sadly I am unable to produce any data in my logs. I hope someone can see where I go wrong. When I run player on my robot, then I get the following message: ------- Adding position2d interface. Configuring Roboteq serial port at /dev/ttyS0 Computed maximum forward velocity of 0.870628 m/s. Computed maximum rotational velocity of 3.414229 rad/s. listening on 6665 Listening on ports: 6665 AX2500 found. Encoder present. Short circuit detection capable. warning : unable to get position geometry ------ When I try to get the log while I move around with PlayerView, then pmaptest gives the following output with the generated logfile; ------ aslund@SDURobot:~$ pmaptest --grid_scale 0.05 mydata2010_09_17_13_24_16.log range_count = 489 range_max = 5.600000 angle_min = -1.500000 angle_max = 1.500000 angle_step = 0.006136 allocating 8192 bytes for scans allocating 607 Mb of map space (estimated lower bound) 0.000 m 0.000 rotations 0 scans 0 steps in 0 seconds -nan msec/scan -nan msec/step ------ My .cfg file is this: ------ driver ( name "hokuyo_aist" provides ["ranger:0"] portopts "type=serial,device=/dev/ttyACM0,timeout=1" min_angle "-1.5" max_angle "1.5" ) driver ( name "rangertolaser" requires ["ranger:0"] # read from ranger:0 provides ["laser:0"] # output results on laser:0 ) driver ( name "roboteq" provides ["position2d:0" "power:0"] devicepath "/dev/ttyS0" motor_control_mode "197" invert_directions "true" encoder_ppr "1024" wheel_circumference "1.28" axle_length "0.255" gear_ratio "7.742" ) driver ( name "writelog" log_directory "/home/aslund" basename "mydata" requires ["laser:0" "position2d:0"] provides ["log:0"] alwayson 1 autorecord 1 ) ------ Thanks for your help. Sebastian Aslund |
From: Aslund <seb...@gm...> - 2010-09-21 13:13:11
|
Hey Rich Thanks for the information. I have played a bit more around and found out that pmaptest is able to produce a map, but only if I disable the GUI, somehow it doesn't work with GUI enabled. The new problem is that I get a map out, but the picture is totally wrong of what it should be and is properly due to the drifting error in my robot's odometry. The question is the how I counter this problem so I can get a decent map? Regards Sebastian On 20 September 2010 15:42, Rich Mattes <jp...@gm...> wrote: > Hi, > > > > Geometry is different from Odometry. When writelog starts up, it sends a > PLAYER_POSITION2D_REQ_GET_GEOM to the position2d devices its logging. The > roboteq driver doesn’t have any code to handle this request, so > ProcessMessage returns -1 and the request is not fulfilled. The geometry > request is used to convey the overall size of the robot; whether or not it > makes sense to handle requests like that from the Roboteq driver is > questionable (maybe via an optional tuple in the config file?) > > > > As far as pmap goes, check to see that logfile.h/cpp (called from > pmap_test.cc) are reading the correct tokens out of your logfile. A cursory > look at the code indicates that if you’re only getting the following message > once is probably having trouble reading from your log file. > > > > 0.000 m 0.000 rotations 0 scans 0 steps in 0 seconds > > -nan msec/scan -nan msec/step > > > > > > Rich > > > > *From:* Aslund [mailto:seb...@gm...] > *Sent:* Monday, September 20, 2010 9:08 AM > *To:* pla...@li... > *Subject:* Re: [Playerstage-users] Problems with writelog and position > geometry > > > > Hey > > I have tried to look into the code an apparently writelog is unable to get > any geometry information, but when I look at the Roboteq driver, then it > updates the geometry if it register encoders, which it does. So if the > roboteq driver publishes position2D information, then why cant writelog not > read them? > > Sebastian > > On 20 September 2010 10:22, Aslund <seb...@gm...> wrote: > > Hey everyone > > I am working on implementing some path planning and for that I need a map. > I have read about how to use writelog and pmaptest to create a grid map, but > sadly I am unable to produce any data in my logs. I hope someone can see > where I go wrong. > When I run player on my robot, then I get the following message: > ------- > Adding position2d interface. > Configuring Roboteq serial port at /dev/ttyS0 > Computed maximum forward velocity of 0.870628 m/s. > Computed maximum rotational velocity of 3.414229 rad/s. > listening on 6665 > Listening on ports: 6665 > AX2500 found. > Encoder present. > Short circuit detection capable. > warning : unable to get position geometry > ------ > > When I try to get the log while I move around with PlayerView, then > pmaptest gives the following output with the generated logfile; > ------ > aslund@SDURobot:~$ pmaptest --grid_scale 0.05 > mydata2010_09_17_13_24_16.log > range_count = 489 > range_max = 5.600000 > angle_min = -1.500000 > angle_max = 1.500000 > angle_step = 0.006136 > allocating 8192 bytes for scans > allocating 607 Mb of map space (estimated lower bound) > 0.000 m 0.000 rotations 0 scans 0 steps in 0 seconds > -nan msec/scan -nan msec/step > ------ > > My .cfg file is this: > ------ > driver > ( > name "hokuyo_aist" > provides ["ranger:0"] > portopts "type=serial,device=/dev/ttyACM0,timeout=1" > min_angle "-1.5" > max_angle "1.5" > ) > > driver > ( > name "rangertolaser" > requires ["ranger:0"] # read from ranger:0 > provides ["laser:0"] # output results on laser:0 > ) > > driver > ( > name "roboteq" > provides ["position2d:0" "power:0"] > devicepath "/dev/ttyS0" > motor_control_mode "197" > invert_directions "true" > encoder_ppr "1024" > wheel_circumference "1.28" > axle_length "0.255" > gear_ratio "7.742" > ) > driver > ( > name "writelog" > log_directory "/home/aslund" > basename "mydata" > requires ["laser:0" "position2d:0"] > provides ["log:0"] > alwayson 1 > autorecord 1 > ) > ------ > > Thanks for your help. > > Sebastian Aslund > > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > > |
From: Rich M. <jp...@gm...> - 2010-09-21 13:55:06
|
Hi, I discovered a bug in the documentation generation.I was going to point you to the docs for pmap, but they don't seem to be generated. I'll point you to the source it's generated from instead[1]. The documentation lists a few parameters you can play with to smooth the map, namely "num_samples." There are some examples towards the bottom of the comment block on how to improve the map output. Rich [1] http://playerstage.svn.sourceforge.net/viewvc/playerstage/code/player/trunk/ utils/pmap/pmap_test.cpp?revision=7165 <http://playerstage.svn.sourceforge.net/viewvc/playerstage/code/player/trunk /utils/pmap/pmap_test.cpp?revision=7165&view=markup> &view=markup From: Aslund [mailto:seb...@gm...] Sent: Tuesday, September 21, 2010 9:13 AM To: pla...@li... Subject: Re: [Playerstage-users] Problems with writelog and position geometry Hey Rich Thanks for the information. I have played a bit more around and found out that pmaptest is able to produce a map, but only if I disable the GUI, somehow it doesn't work with GUI enabled. The new problem is that I get a map out, but the picture is totally wrong of what it should be and is properly due to the drifting error in my robot's odometry. The question is the how I counter this problem so I can get a decent map? Regards Sebastian On 20 September 2010 15:42, Rich Mattes <jp...@gm...> wrote: Hi, Geometry is different from Odometry. When writelog starts up, it sends a PLAYER_POSITION2D_REQ_GET_GEOM to the position2d devices its logging. The roboteq driver doesn't have any code to handle this request, so ProcessMessage returns -1 and the request is not fulfilled. The geometry request is used to convey the overall size of the robot; whether or not it makes sense to handle requests like that from the Roboteq driver is questionable (maybe via an optional tuple in the config file?) As far as pmap goes, check to see that logfile.h/cpp (called from pmap_test.cc) are reading the correct tokens out of your logfile. A cursory look at the code indicates that if you're only getting the following message once is probably having trouble reading from your log file. 0.000 m 0.000 rotations 0 scans 0 steps in 0 seconds -nan msec/scan -nan msec/step Rich From: Aslund [mailto:seb...@gm...] Sent: Monday, September 20, 2010 9:08 AM To: pla...@li... Subject: Re: [Playerstage-users] Problems with writelog and position geometry Hey I have tried to look into the code an apparently writelog is unable to get any geometry information, but when I look at the Roboteq driver, then it updates the geometry if it register encoders, which it does. So if the roboteq driver publishes position2D information, then why cant writelog not read them? Sebastian On 20 September 2010 10:22, Aslund <seb...@gm...> wrote: Hey everyone I am working on implementing some path planning and for that I need a map. I have read about how to use writelog and pmaptest to create a grid map, but sadly I am unable to produce any data in my logs. I hope someone can see where I go wrong. When I run player on my robot, then I get the following message: ------- Adding position2d interface. Configuring Roboteq serial port at /dev/ttyS0 Computed maximum forward velocity of 0.870628 m/s. Computed maximum rotational velocity of 3.414229 rad/s. listening on 6665 Listening on ports: 6665 AX2500 found. Encoder present. Short circuit detection capable. warning : unable to get position geometry ------ When I try to get the log while I move around with PlayerView, then pmaptest gives the following output with the generated logfile; ------ aslund@SDURobot:~$ pmaptest --grid_scale 0.05 mydata2010_09_17_13_24_16.log range_count = 489 range_max = 5.600000 angle_min = -1.500000 angle_max = 1.500000 angle_step = 0.006136 allocating 8192 bytes for scans allocating 607 Mb of map space (estimated lower bound) 0.000 m 0.000 rotations 0 scans 0 steps in 0 seconds -nan msec/scan -nan msec/step ------ My .cfg file is this: ------ driver ( name "hokuyo_aist" provides ["ranger:0"] portopts "type=serial,device=/dev/ttyACM0,timeout=1" min_angle "-1.5" max_angle "1.5" ) driver ( name "rangertolaser" requires ["ranger:0"] # read from ranger:0 provides ["laser:0"] # output results on laser:0 ) driver ( name "roboteq" provides ["position2d:0" "power:0"] devicepath "/dev/ttyS0" motor_control_mode "197" invert_directions "true" encoder_ppr "1024" wheel_circumference "1.28" axle_length "0.255" gear_ratio "7.742" ) driver ( name "writelog" log_directory "/home/aslund" basename "mydata" requires ["laser:0" "position2d:0"] provides ["log:0"] alwayson 1 autorecord 1 ) ------ Thanks for your help. Sebastian Aslund ---------------------------------------------------------------------------- -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Playerstage-users mailing list Pla...@li... https://lists.sourceforge.net/lists/listinfo/playerstage-users |
From: Claudio C. <eru...@ti...> - 2010-09-21 14:13:07
|
I'm pretty new to Player/Stage so i'm looking for some insight here. Right now i'm experimenting with the playerc client library (still very simple stuff). What I have to do, in the end, is adapt a simple fuzzy algorithm to generate an hexagonal map. I have done the basics in matlab, and am familiar with ansi c. What i don't know is how maps can be handled by Player/Stage. For example i'd need the map to be rendered sometime to see how the algorithm behaves, how can i do this? In matlab it's pretty simple, in Player i don't know where to start. I experimented with the MRICP driver, but even without odometry drift and GPS as position source, the maps have all sorts of imprecisions. This baffles me entirely. I cannot understand where this imprecision is generated, why do i get curved lines in place of straight ones if there are no drifts in the simulation. I hope someone can elaborate on my problems. Thank you all Claudio Carbone Robotics Laboratory, Department of Automation Università di Roma Tre |
From: Tuna T. <te...@gm...> - 2010-09-21 14:26:50
|
usin playerv and subscribing to map. Tuna Toksöz Eternal sunshine of the open source mind. http://devlicio.us/blogs/tuna_toksoz http://tunatoksoz.com http://twitter.com/tehlike On Tue, Sep 21, 2010 at 10:12 AM, Claudio Carbone <eru...@ti...>wrote: > For example i'd need the map to be rendered sometime to see how the > algorithm behaves, how can i do this? > |
From: Claudio C. <eru...@ti...> - 2010-09-21 14:59:07
|
In order to do that i would have to code a driver, provide an interface that gives access to a proxy called map. I wouldn't know where to start. As i said i'm using the playerc client libraries that are not meant to do that. Claudio Carbone Robotics Laboratory, Department of Automation Università di Roma Tre From: Tuna Toksoz [mailto:te...@gm...] Sent: martedì 21 settembre 2010 16:16 To: pla...@li... Subject: Re: [Playerstage-users] General questions regarding maps usin playerv and subscribing to map. Tuna Toksöz Eternal sunshine of the open source mind. http://devlicio.us/blogs/tuna_toksoz http://tunatoksoz.com http://twitter.com/tehlike On Tue, Sep 21, 2010 at 10:12 AM, Claudio Carbone <eru...@ti...> wrote: For example i'd need the map to be rendered sometime to see how the algorithm behaves, how can i do this? |
From: Thimo L. <th...@g4...> - 2010-09-21 20:07:56
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Claudio Carbone wrote: > In order to do that i would have to code a driver, provide an interface > that gives access to a proxy called map. > > I wouldn't know where to start. There is a helpful documentation for writing player drivers at [1]. I recommend writing a driver for this to provide a map or vectormap interface, it would allow other components to transparently use your implementation. If you are interested, i could provide you with some template code for a map-providing driver. Regards, Thimo Langbehn [1] http://www.psurobotics.org/wiki/index.php?title=Writing_a_Player_Plugin -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAkyZEAsACgkQLoHAUMxCwiWVAACgvcLRhrXhsHlx2eEa/CKJSZ25 c4kAoJlWQwMhFa8vY5VZJCBxiUBNs1Fc =dY4/ -----END PGP SIGNATURE----- |
From: Claudio C. <eru...@ti...> - 2010-09-21 21:55:02
|
Sure! I'm all ears :p Let me know Claudio Carbone Robotics Laboratory, Department of Automation Università di Roma Tre -----Original Message----- From: Thimo Langbehn [mailto:th...@g4...] Sent: martedì 21 settembre 2010 22:06 To: pla...@li... Subject: Re: [Playerstage-users] General questions regarding maps -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Claudio Carbone wrote: > In order to do that i would have to code a driver, provide an interface > that gives access to a proxy called map. > > I wouldn't know where to start. There is a helpful documentation for writing player drivers at [1]. I recommend writing a driver for this to provide a map or vectormap interface, it would allow other components to transparently use your implementation. If you are interested, i could provide you with some template code for a map-providing driver. Regards, Thimo Langbehn [1] http://www.psurobotics.org/wiki/index.php?title=Writing_a_Player_Plugin -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEAREKAAYFAkyZEAsACgkQLoHAUMxCwiWVAACgvcLRhrXhsHlx2eEa/CKJSZ25 c4kAoJlWQwMhFa8vY5VZJCBxiUBNs1Fc =dY4/ -----END PGP SIGNATURE----- ---------------------------------------------------------------------------- -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Playerstage-users mailing list Pla...@li... https://lists.sourceforge.net/lists/listinfo/playerstage-users |
From: Thimo L. <th...@g4...> - 2010-09-22 19:41:08
Attachments:
signature.asc
MapDriver.tgz
|
Claudio Carbone wrote: >> In order to do that i would have to code a driver, provide an interface >> that gives access to a proxy called map. > >> I wouldn't know where to start. > > There is a helpful documentation for writing player drivers at [1]. > I recommend writing a driver for this to provide a map or vectormap > interface, it would allow other components to transparently use your > implementation. > If you are interested, i could provide you with some template code for a > map-providing driver. > > [1] http://www.psurobotics.org/wiki/index.php?title=Writing_a_Player_Plugin I attached a small template, made for Player trunk (rev. 8905). It should give you the general idea how to develop and load a custom (map) driver. For further information, I suggest looking at some existing drivers and the interface definitions in player/libplayerinterface/interfaces/ , especially 042_map.def and 063_vectormap.def . If you want to integrate an algorithm into player, I recommend to develop it as a separate library and then only wrap it with such a driver. Regards, Thimo Lanbgbehn |
From: Claudio C. <eru...@ti...> - 2010-09-25 08:00:15
|
Is there any driver/device/interface that does basic mapping and only provides a simple map to read? No correction, no inference, no slam, no nothing. Basic sensor reading and saving. Is there anything like that? Which drivers provide the map interface? Thanks Claudio Carbone Robotics Laboratory, Department of Automation Università di Roma Tre |
From: Ge, F. L. <fg...@cs...> - 2010-09-25 08:28:39
|
I guess the simplest one is playerv :) Regards Fenglu ge -----Original Message----- From: Claudio Carbone [mailto:eru...@ti...] Sent: Saturday, 25 September 2010 6:00 PM To: pla...@li... Subject: Re: [Playerstage-users] General questions regarding maps Is there any driver/device/interface that does basic mapping and only provides a simple map to read? No correction, no inference, no slam, no nothing. Basic sensor reading and saving. Is there anything like that? Which drivers provide the map interface? Thanks Claudio Carbone Robotics Laboratory, Department of Automation Università di Roma Tre ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Playerstage-users mailing list Pla...@li... https://lists.sourceforge.net/lists/listinfo/playerstage-users |
From: Claudio C. <eru...@ti...> - 2010-09-25 08:34:23
|
Sure, i know. I mean: what should i put in the player cfg to provide the interface? Thanks Claudio Carbone Robotics Laboratory, Department of Automation Università di Roma Tre -----Original Message----- From: Ge, Feng Lu [mailto:fg...@cs...] Sent: sabato 25 settembre 2010 10:05 To: 'pla...@li...' Subject: Re: [Playerstage-users] General questions regarding maps I guess the simplest one is playerv :) Regards Fenglu ge -----Original Message----- From: Claudio Carbone [mailto:eru...@ti...] Sent: Saturday, 25 September 2010 6:00 PM To: pla...@li... Subject: Re: [Playerstage-users] General questions regarding maps Is there any driver/device/interface that does basic mapping and only provides a simple map to read? No correction, no inference, no slam, no nothing. Basic sensor reading and saving. Is there anything like that? Which drivers provide the map interface? Thanks Claudio Carbone Robotics Laboratory, Department of Automation Università di Roma Tre ---------------------------------------------------------------------------- -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Playerstage-users mailing list Pla...@li... https://lists.sourceforge.net/lists/listinfo/playerstage-users ---------------------------------------------------------------------------- -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Playerstage-users mailing list Pla...@li... https://lists.sourceforge.net/lists/listinfo/playerstage-users |
From: Jan S. <pla...@ja...> - 2010-09-25 12:49:21
|
Hello! I'm not quite sure what you are actually looking for, but I will just answer your questions one by one. > Is there any driver/device/interface that does basic mapping and only > provides a simple map to read? > No correction, no inference, no slam, no nothing. Yes, the "mapfile" driver. driver ( name "mapfile" provides ["map:0"] filename "yourmap.png" resolution 0.1 # length of one map pixel in meters ) This provides a simple map to read and does no correction, no interference, no slam or anything else with it. http://playerstage.sf.net/doc/Player-2.1.0/player/group__driver__mapfile.html > Basic sensor reading and saving. The "writelog" driver does this. Tell it what sensor readings to record in its requires section, and it will read and save them. http://playerstage.sf.net/doc/Player-2.1.0/player/group__driver__writelog.html > Which drivers provide the map interface? Drivers that require or provide the map interface: $ grep -Rlie "player_map" server/drivers ... amcl, gridmap, mapcspace, mapfile, mapscale, vmapfile, mricp, wavefront, vectormap ... Thinking about it, mricp might be what you wanted. Otherwise please try to be more specific about what you need. Best regards, Jan Schlüter |
From: Claudio C. <eru...@ti...> - 2010-09-30 16:13:32
|
>I'm not quite sure what you are actually looking for Me neither :( Fact is I have to somehow draw an hexagonal map. How can I do it? Currently my program reads data from player, does its things, builds up a map, and has it stored like a matrix. Regards Claudio Carbone |
From: Claudio C. <eru...@ti...> - 2010-09-30 16:17:09
|
>I'm not quite sure what you are actually looking for Me neither :( Fact is I have to somehow draw an hexagonal map. How can I do it? Currently my program reads data from player, does its things, builds up a map, and has it stored like a matrix. Regards Claudio Carbone -----Original Message----- From: Jan Schlüter [mailto:pla...@ja...] Sent: sabato 25 settembre 2010 14:23 To: pla...@li... Subject: Re: [Playerstage-users] General questions regarding maps Hello! I'm not quite sure what you are actually looking for, but I will just answer your questions one by one. > Is there any driver/device/interface that does basic mapping and only > provides a simple map to read? > No correction, no inference, no slam, no nothing. Yes, the "mapfile" driver. driver ( name "mapfile" provides ["map:0"] filename "yourmap.png" resolution 0.1 # length of one map pixel in meters ) This provides a simple map to read and does no correction, no interference, no slam or anything else with it. http://playerstage.sf.net/doc/Player-2.1.0/player/group__driver__mapfile.html > Basic sensor reading and saving. The "writelog" driver does this. Tell it what sensor readings to record in its requires section, and it will read and save them. http://playerstage.sf.net/doc/Player-2.1.0/player/group__driver__writelog.html > Which drivers provide the map interface? Drivers that require or provide the map interface: $ grep -Rlie "player_map" server/drivers ... amcl, gridmap, mapcspace, mapfile, mapscale, vmapfile, mricp, wavefront, vectormap ... Thinking about it, mricp might be what you wanted. Otherwise please try to be more specific about what you need. Best regards, Jan Schlüter ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Playerstage-users mailing list Pla...@li... https://lists.sourceforge.net/lists/listinfo/playerstage-users |
From: Aslund <seb...@gm...> - 2010-09-24 08:24:01
|
Hey I have tried to follow the different steps and the map I get is still a total mess. I have tried to run the log in PlayerView and the laser information is perfect with the motion of the robot. My room is nearly squared, but then map I get can seen here: http://yfrog.com/5xfinecj Can the error in odometry really result in such a bad map? Regards Sebastian On 21 September 2010 15:54, Rich Mattes <jp...@gm...> wrote: > Hi, > > > > I discovered a bug in the documentation generation…I was going to point you > to the docs for pmap, but they don’t seem to be generated. I’ll point you > to the source it’s generated from instead[1]. The documentation lists a few > parameters you can play with to smooth the map, namely “num_samples.” There > are some examples towards the bottom of the comment block on how to improve > the map output. > > > > Rich > > > > [1] > http://playerstage.svn.sourceforge.net/viewvc/playerstage/code/player/trunk/utils/pmap/pmap_test.cpp?revision=7165&view=markup > > > > *From:* Aslund [mailto:seb...@gm...] > *Sent:* Tuesday, September 21, 2010 9:13 AM > > *To:* pla...@li... > *Subject:* Re: [Playerstage-users] Problems with writelog and position > geometry > > > > Hey Rich > > Thanks for the information. > I have played a bit more around and found out that pmaptest is able to > produce a map, but only if I disable the GUI, somehow it doesn't work with > GUI enabled. > The new problem is that I get a map out, but the picture is totally wrong > of what it should be and is properly due to the drifting error in my robot's > odometry. The question is the how I counter this problem so I can get a > decent map? > > Regards > > Sebastian > > On 20 September 2010 15:42, Rich Mattes <jp...@gm...> wrote: > > Hi, > > > > Geometry is different from Odometry. When writelog starts up, it sends a > PLAYER_POSITION2D_REQ_GET_GEOM to the position2d devices its logging. The > roboteq driver doesn’t have any code to handle this request, so > ProcessMessage returns -1 and the request is not fulfilled. The geometry > request is used to convey the overall size of the robot; whether or not it > makes sense to handle requests like that from the Roboteq driver is > questionable (maybe via an optional tuple in the config file?) > > > > As far as pmap goes, check to see that logfile.h/cpp (called from > pmap_test.cc) are reading the correct tokens out of your logfile. A cursory > look at the code indicates that if you’re only getting the following message > once is probably having trouble reading from your log file. > > > > 0.000 m 0.000 rotations 0 scans 0 steps in 0 seconds > > -nan msec/scan -nan msec/step > > > > > > Rich > > > > *From:* Aslund [mailto:seb...@gm...] > *Sent:* Monday, September 20, 2010 9:08 AM > *To:* pla...@li... > *Subject:* Re: [Playerstage-users] Problems with writelog and position > geometry > > > > Hey > > I have tried to look into the code an apparently writelog is unable to get > any geometry information, but when I look at the Roboteq driver, then it > updates the geometry if it register encoders, which it does. So if the > roboteq driver publishes position2D information, then why cant writelog not > read them? > > Sebastian > > On 20 September 2010 10:22, Aslund <seb...@gm...> wrote: > > Hey everyone > > I am working on implementing some path planning and for that I need a map. > I have read about how to use writelog and pmaptest to create a grid map, but > sadly I am unable to produce any data in my logs. I hope someone can see > where I go wrong. > When I run player on my robot, then I get the following message: > ------- > Adding position2d interface. > Configuring Roboteq serial port at /dev/ttyS0 > Computed maximum forward velocity of 0.870628 m/s. > Computed maximum rotational velocity of 3.414229 rad/s. > listening on 6665 > Listening on ports: 6665 > AX2500 found. > Encoder present. > Short circuit detection capable. > warning : unable to get position geometry > ------ > > When I try to get the log while I move around with PlayerView, then > pmaptest gives the following output with the generated logfile; > ------ > aslund@SDURobot:~$ pmaptest --grid_scale 0.05 > mydata2010_09_17_13_24_16.log > range_count = 489 > range_max = 5.600000 > angle_min = -1.500000 > angle_max = 1.500000 > angle_step = 0.006136 > allocating 8192 bytes for scans > allocating 607 Mb of map space (estimated lower bound) > 0.000 m 0.000 rotations 0 scans 0 steps in 0 seconds > -nan msec/scan -nan msec/step > ------ > > My .cfg file is this: > ------ > driver > ( > name "hokuyo_aist" > provides ["ranger:0"] > portopts "type=serial,device=/dev/ttyACM0,timeout=1" > min_angle "-1.5" > max_angle "1.5" > ) > > driver > ( > name "rangertolaser" > requires ["ranger:0"] # read from ranger:0 > provides ["laser:0"] # output results on laser:0 > ) > > driver > ( > name "roboteq" > provides ["position2d:0" "power:0"] > devicepath "/dev/ttyS0" > motor_control_mode "197" > invert_directions "true" > encoder_ppr "1024" > wheel_circumference "1.28" > axle_length "0.255" > gear_ratio "7.742" > ) > driver > ( > name "writelog" > log_directory "/home/aslund" > basename "mydata" > requires ["laser:0" "position2d:0"] > provides ["log:0"] > alwayson 1 > autorecord 1 > ) > ------ > > Thanks for your help. > > Sebastian Aslund > > > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > > |
From: Rich M. <jp...@gm...> - 2010-09-24 16:14:23
|
Bad odometry alone can indeed give you massive errors; it's nearly impossible to track position with odometry alone. This is why SLAM is such a big problem and there's so many approaches that deal with data from many different sensors with okay readings into one pretty-good position estimate. But I'll get off my soapbox now. I'd probably go back to the beginning and make sure the Roboteq is reporting reasonable values for translation and rotation. Looking at the map, it looks like the roboteq may be over-reporting rotation information and throwing off the laser corrections. If you can, try plotting the odometry data you have to see if it makes sense in terms of distance traversed and yaw angle during turns (it won't be perfect, but it should be reasonably similar.) Alternatively, you can watch the robot state in playerprint and drive your robot with playerjoy: if you move forward a meter the x position should increase by about 1, if you spin 90 degrees to the left the yaw position should increase by about pi/2, etc. Rich From: Aslund [mailto:seb...@gm...] Sent: Friday, September 24, 2010 4:24 AM To: pla...@li... Subject: Re: [Playerstage-users] Problems with writelog and position geometry Hey I have tried to follow the different steps and the map I get is still a total mess. I have tried to run the log in PlayerView and the laser information is perfect with the motion of the robot. My room is nearly squared, but then map I get can seen here: http://yfrog.com/5xfinecj Can the error in odometry really result in such a bad map? Regards Sebastian On 21 September 2010 15:54, Rich Mattes <jp...@gm...> wrote: Hi, I discovered a bug in the documentation generation.I was going to point you to the docs for pmap, but they don't seem to be generated. I'll point you to the source it's generated from instead[1]. The documentation lists a few parameters you can play with to smooth the map, namely "num_samples." There are some examples towards the bottom of the comment block on how to improve the map output. Rich [1] http://playerstage.svn.sourceforge.net/viewvc/playerstage/code/player/trunk/ utils/pmap/pmap_test.cpp?revision=7165 <http://playerstage.svn.sourceforge.net/viewvc/playerstage/code/player/trunk /utils/pmap/pmap_test.cpp?revision=7165&view=markup> &view=markup From: Aslund [mailto:seb...@gm...] Sent: Tuesday, September 21, 2010 9:13 AM To: pla...@li... Subject: Re: [Playerstage-users] Problems with writelog and position geometry Hey Rich Thanks for the information. I have played a bit more around and found out that pmaptest is able to produce a map, but only if I disable the GUI, somehow it doesn't work with GUI enabled. The new problem is that I get a map out, but the picture is totally wrong of what it should be and is properly due to the drifting error in my robot's odometry. The question is the how I counter this problem so I can get a decent map? Regards Sebastian On 20 September 2010 15:42, Rich Mattes <jp...@gm...> wrote: Hi, Geometry is different from Odometry. When writelog starts up, it sends a PLAYER_POSITION2D_REQ_GET_GEOM to the position2d devices its logging. The roboteq driver doesn't have any code to handle this request, so ProcessMessage returns -1 and the request is not fulfilled. The geometry request is used to convey the overall size of the robot; whether or not it makes sense to handle requests like that from the Roboteq driver is questionable (maybe via an optional tuple in the config file?) As far as pmap goes, check to see that logfile.h/cpp (called from pmap_test.cc) are reading the correct tokens out of your logfile. A cursory look at the code indicates that if you're only getting the following message once is probably having trouble reading from your log file. 0.000 m 0.000 rotations 0 scans 0 steps in 0 seconds -nan msec/scan -nan msec/step Rich From: Aslund [mailto:seb...@gm...] Sent: Monday, September 20, 2010 9:08 AM To: pla...@li... Subject: Re: [Playerstage-users] Problems with writelog and position geometry Hey I have tried to look into the code an apparently writelog is unable to get any geometry information, but when I look at the Roboteq driver, then it updates the geometry if it register encoders, which it does. So if the roboteq driver publishes position2D information, then why cant writelog not read them? Sebastian On 20 September 2010 10:22, Aslund <seb...@gm...> wrote: Hey everyone I am working on implementing some path planning and for that I need a map. I have read about how to use writelog and pmaptest to create a grid map, but sadly I am unable to produce any data in my logs. I hope someone can see where I go wrong. When I run player on my robot, then I get the following message: ------- Adding position2d interface. Configuring Roboteq serial port at /dev/ttyS0 Computed maximum forward velocity of 0.870628 m/s. Computed maximum rotational velocity of 3.414229 rad/s. listening on 6665 Listening on ports: 6665 AX2500 found. Encoder present. Short circuit detection capable. warning : unable to get position geometry ------ When I try to get the log while I move around with PlayerView, then pmaptest gives the following output with the generated logfile; ------ aslund@SDURobot:~$ pmaptest --grid_scale 0.05 mydata2010_09_17_13_24_16.log range_count = 489 range_max = 5.600000 angle_min = -1.500000 angle_max = 1.500000 angle_step = 0.006136 allocating 8192 bytes for scans allocating 607 Mb of map space (estimated lower bound) 0.000 m 0.000 rotations 0 scans 0 steps in 0 seconds -nan msec/scan -nan msec/step ------ My .cfg file is this: ------ driver ( name "hokuyo_aist" provides ["ranger:0"] portopts "type=serial,device=/dev/ttyACM0,timeout=1" min_angle "-1.5" max_angle "1.5" ) driver ( name "rangertolaser" requires ["ranger:0"] # read from ranger:0 provides ["laser:0"] # output results on laser:0 ) driver ( name "roboteq" provides ["position2d:0" "power:0"] devicepath "/dev/ttyS0" motor_control_mode "197" invert_directions "true" encoder_ppr "1024" wheel_circumference "1.28" axle_length "0.255" gear_ratio "7.742" ) driver ( name "writelog" log_directory "/home/aslund" basename "mydata" requires ["laser:0" "position2d:0"] provides ["log:0"] alwayson 1 autorecord 1 ) ------ Thanks for your help. Sebastian Aslund ---------------------------------------------------------------------------- -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Playerstage-users mailing list Pla...@li... https://lists.sourceforge.net/lists/listinfo/playerstage-users ---------------------------------------------------------------------------- -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Playerstage-users mailing list Pla...@li... https://lists.sourceforge.net/lists/listinfo/playerstage-users |
From: Aslund <seb...@gm...> - 2010-09-28 13:22:02
|
Hey Rich I tried to use playerprint and playerjoy to move the robot and see the odometry data given from position2D. The result was very surprising, especially theta was jumping around like crazy when I turned the robot. If I turned the robot a few degrees, then theta changed eg. from -4.1 to -1.12. It confuses me a great deal because my velocity and rotation speed commands in Player works fine. In player I can make a small program that over a given time moves the robot 360 degrees by setting a fixed rotation velocity, when I do this I get an error that is only a few degrees, so I am a bit lost the odometry gives so wrong information when sending motion commands to the robot yield good results. Do you have any idea what might be wrong and even better, how to fix it? Ps. I am using a Roboteq motorcontroller Regards Sebastian Aslund On 24 September 2010 18:14, Rich Mattes <jp...@gm...> wrote: > Bad odometry alone can indeed give you massive errors; it’s nearly > impossible to track position with odometry alone. This is why SLAM is such > a big problem and there’s so many approaches that deal with data from many > different sensors with okay readings into one pretty-good position > estimate. But I’ll get off my soapbox now. > > > I’d probably go back to the beginning and make sure the Roboteq is > reporting reasonable values for translation and rotation. Looking at the > map, it looks like the roboteq may be over-reporting rotation information > and throwing off the laser corrections. If you can, try plotting the > odometry data you have to see if it makes sense in terms of distance > traversed and yaw angle during turns (it won’t be perfect, but it should be > reasonably similar.) Alternatively, you can watch the robot state in > playerprint and drive your robot with playerjoy: if you move forward a > meter the x position should increase by about 1, if you spin 90 degrees to > the left the yaw position should increase by about pi/2, etc. > > > > Rich > > > > *From:* Aslund [mailto:seb...@gm...] > *Sent:* Friday, September 24, 2010 4:24 AM > > *To:* pla...@li... > *Subject:* Re: [Playerstage-users] Problems with writelog and position > geometry > > > > Hey > > I have tried to follow the different steps and the map I get is still a > total mess. > I have tried to run the log in PlayerView and the laser information is > perfect with the motion of the robot. > > My room is nearly squared, but then map I get can seen here: > http://yfrog.com/5xfinecj > Can the error in odometry really result in such a bad map? > > Regards > > Sebastian > > On 21 September 2010 15:54, Rich Mattes <jp...@gm...> wrote: > > Hi, > > > > I discovered a bug in the documentation generation…I was going to point you > to the docs for pmap, but they don’t seem to be generated. I’ll point you > to the source it’s generated from instead[1]. The documentation lists a few > parameters you can play with to smooth the map, namely “num_samples.” There > are some examples towards the bottom of the comment block on how to improve > the map output. > > > > Rich > > > > [1] > http://playerstage.svn.sourceforge.net/viewvc/playerstage/code/player/trunk/utils/pmap/pmap_test.cpp?revision=7165&view=markup > > > > *From:* Aslund [mailto:seb...@gm...] > *Sent:* Tuesday, September 21, 2010 9:13 AM > > > *To:* pla...@li... > *Subject:* Re: [Playerstage-users] Problems with writelog and position > geometry > > > > Hey Rich > > Thanks for the information. > I have played a bit more around and found out that pmaptest is able to > produce a map, but only if I disable the GUI, somehow it doesn't work with > GUI enabled. > The new problem is that I get a map out, but the picture is totally wrong > of what it should be and is properly due to the drifting error in my robot's > odometry. The question is the how I counter this problem so I can get a > decent map? > > Regards > > Sebastian > > On 20 September 2010 15:42, Rich Mattes <jp...@gm...> wrote: > > Hi, > > > > Geometry is different from Odometry. When writelog starts up, it sends a > PLAYER_POSITION2D_REQ_GET_GEOM to the position2d devices its logging. The > roboteq driver doesn’t have any code to handle this request, so > ProcessMessage returns -1 and the request is not fulfilled. The geometry > request is used to convey the overall size of the robot; whether or not it > makes sense to handle requests like that from the Roboteq driver is > questionable (maybe via an optional tuple in the config file?) > > > > As far as pmap goes, check to see that logfile.h/cpp (called from > pmap_test.cc) are reading the correct tokens out of your logfile. A cursory > look at the code indicates that if you’re only getting the following message > once is probably having trouble reading from your log file. > > > > 0.000 m 0.000 rotations 0 scans 0 steps in 0 seconds > > -nan msec/scan -nan msec/step > > > > > > Rich > > > > *From:* Aslund [mailto:seb...@gm...] > *Sent:* Monday, September 20, 2010 9:08 AM > *To:* pla...@li... > *Subject:* Re: [Playerstage-users] Problems with writelog and position > geometry > > > > Hey > > I have tried to look into the code an apparently writelog is unable to get > any geometry information, but when I look at the Roboteq driver, then it > updates the geometry if it register encoders, which it does. So if the > roboteq driver publishes position2D information, then why cant writelog not > read them? > > Sebastian > > On 20 September 2010 10:22, Aslund <seb...@gm...> wrote: > > Hey everyone > > I am working on implementing some path planning and for that I need a map. > I have read about how to use writelog and pmaptest to create a grid map, but > sadly I am unable to produce any data in my logs. I hope someone can see > where I go wrong. > When I run player on my robot, then I get the following message: > ------- > Adding position2d interface. > Configuring Roboteq serial port at /dev/ttyS0 > Computed maximum forward velocity of 0.870628 m/s. > Computed maximum rotational velocity of 3.414229 rad/s. > listening on 6665 > Listening on ports: 6665 > AX2500 found. > Encoder present. > Short circuit detection capable. > warning : unable to get position geometry > ------ > > When I try to get the log while I move around with PlayerView, then > pmaptest gives the following output with the generated logfile; > ------ > aslund@SDURobot:~$ pmaptest --grid_scale 0.05 > mydata2010_09_17_13_24_16.log > range_count = 489 > range_max = 5.600000 > angle_min = -1.500000 > angle_max = 1.500000 > angle_step = 0.006136 > allocating 8192 bytes for scans > allocating 607 Mb of map space (estimated lower bound) > 0.000 m 0.000 rotations 0 scans 0 steps in 0 seconds > -nan msec/scan -nan msec/step > ------ > > My .cfg file is this: > ------ > driver > ( > name "hokuyo_aist" > provides ["ranger:0"] > portopts "type=serial,device=/dev/ttyACM0,timeout=1" > min_angle "-1.5" > max_angle "1.5" > ) > > driver > ( > name "rangertolaser" > requires ["ranger:0"] # read from ranger:0 > provides ["laser:0"] # output results on laser:0 > ) > > driver > ( > name "roboteq" > provides ["position2d:0" "power:0"] > devicepath "/dev/ttyS0" > motor_control_mode "197" > invert_directions "true" > encoder_ppr "1024" > wheel_circumference "1.28" > axle_length "0.255" > gear_ratio "7.742" > ) > driver > ( > name "writelog" > log_directory "/home/aslund" > basename "mydata" > requires ["laser:0" "position2d:0"] > provides ["log:0"] > alwayson 1 > autorecord 1 > ) > ------ > > Thanks for your help. > > Sebastian Aslund > > > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > > > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > > |
From: Rich M. <jp...@gm...> - 2010-09-29 16:27:24
|
The roboteq has a PID controller inside of it to regulate velocity, and if you're using its closed-loop mode you're seeing that regulate the yawrate you command. The roboteq will also print out encoder positions, but as I recall the driver is reading them incorrectly. I would try digging in to the "UpdatePositionData" function in the roboteq driver and make sure velocities and positions are being correctly read, scaled, and processed. Rich From: Aslund [mailto:seb...@gm...] Sent: Tuesday, September 28, 2010 9:22 AM To: pla...@li... Subject: Re: [Playerstage-users] Problems with writelog and position geometry Hey Rich I tried to use playerprint and playerjoy to move the robot and see the odometry data given from position2D. The result was very surprising, especially theta was jumping around like crazy when I turned the robot. If I turned the robot a few degrees, then theta changed eg. from -4.1 to -1.12. It confuses me a great deal because my velocity and rotation speed commands in Player works fine. In player I can make a small program that over a given time moves the robot 360 degrees by setting a fixed rotation velocity, when I do this I get an error that is only a few degrees, so I am a bit lost the odometry gives so wrong information when sending motion commands to the robot yield good results. Do you have any idea what might be wrong and even better, how to fix it? Ps. I am using a Roboteq motorcontroller Regards Sebastian Aslund On 24 September 2010 18:14, Rich Mattes <jp...@gm...> wrote: Bad odometry alone can indeed give you massive errors; it's nearly impossible to track position with odometry alone. This is why SLAM is such a big problem and there's so many approaches that deal with data from many different sensors with okay readings into one pretty-good position estimate. But I'll get off my soapbox now. I'd probably go back to the beginning and make sure the Roboteq is reporting reasonable values for translation and rotation. Looking at the map, it looks like the roboteq may be over-reporting rotation information and throwing off the laser corrections. If you can, try plotting the odometry data you have to see if it makes sense in terms of distance traversed and yaw angle during turns (it won't be perfect, but it should be reasonably similar.) Alternatively, you can watch the robot state in playerprint and drive your robot with playerjoy: if you move forward a meter the x position should increase by about 1, if you spin 90 degrees to the left the yaw position should increase by about pi/2, etc. Rich From: Aslund [mailto:seb...@gm...] Sent: Friday, September 24, 2010 4:24 AM To: pla...@li... Subject: Re: [Playerstage-users] Problems with writelog and position geometry Hey I have tried to follow the different steps and the map I get is still a total mess. I have tried to run the log in PlayerView and the laser information is perfect with the motion of the robot. My room is nearly squared, but then map I get can seen here: http://yfrog.com/5xfinecj Can the error in odometry really result in such a bad map? Regards Sebastian On 21 September 2010 15:54, Rich Mattes <jp...@gm...> wrote: Hi, I discovered a bug in the documentation generation.I was going to point you to the docs for pmap, but they don't seem to be generated. I'll point you to the source it's generated from instead[1]. The documentation lists a few parameters you can play with to smooth the map, namely "num_samples." There are some examples towards the bottom of the comment block on how to improve the map output. Rich [1] http://playerstage.svn.sourceforge.net/viewvc/playerstage/code/player/trunk/ utils/pmap/pmap_test.cpp?revision=7165 <http://playerstage.svn.sourceforge.net/viewvc/playerstage/code/player/trunk /utils/pmap/pmap_test.cpp?revision=7165&view=markup> &view=markup From: Aslund [mailto:seb...@gm...] Sent: Tuesday, September 21, 2010 9:13 AM To: pla...@li... Subject: Re: [Playerstage-users] Problems with writelog and position geometry Hey Rich Thanks for the information. I have played a bit more around and found out that pmaptest is able to produce a map, but only if I disable the GUI, somehow it doesn't work with GUI enabled. The new problem is that I get a map out, but the picture is totally wrong of what it should be and is properly due to the drifting error in my robot's odometry. The question is the how I counter this problem so I can get a decent map? Regards Sebastian On 20 September 2010 15:42, Rich Mattes <jp...@gm...> wrote: Hi, Geometry is different from Odometry. When writelog starts up, it sends a PLAYER_POSITION2D_REQ_GET_GEOM to the position2d devices its logging. The roboteq driver doesn't have any code to handle this request, so ProcessMessage returns -1 and the request is not fulfilled. The geometry request is used to convey the overall size of the robot; whether or not it makes sense to handle requests like that from the Roboteq driver is questionable (maybe via an optional tuple in the config file?) As far as pmap goes, check to see that logfile.h/cpp (called from pmap_test.cc) are reading the correct tokens out of your logfile. A cursory look at the code indicates that if you're only getting the following message once is probably having trouble reading from your log file. 0.000 m 0.000 rotations 0 scans 0 steps in 0 seconds -nan msec/scan -nan msec/step Rich From: Aslund [mailto:seb...@gm...] Sent: Monday, September 20, 2010 9:08 AM To: pla...@li... Subject: Re: [Playerstage-users] Problems with writelog and position geometry Hey I have tried to look into the code an apparently writelog is unable to get any geometry information, but when I look at the Roboteq driver, then it updates the geometry if it register encoders, which it does. So if the roboteq driver publishes position2D information, then why cant writelog not read them? Sebastian On 20 September 2010 10:22, Aslund <seb...@gm...> wrote: Hey everyone I am working on implementing some path planning and for that I need a map. I have read about how to use writelog and pmaptest to create a grid map, but sadly I am unable to produce any data in my logs. I hope someone can see where I go wrong. When I run player on my robot, then I get the following message: ------- Adding position2d interface. Configuring Roboteq serial port at /dev/ttyS0 Computed maximum forward velocity of 0.870628 m/s. Computed maximum rotational velocity of 3.414229 rad/s. listening on 6665 Listening on ports: 6665 AX2500 found. Encoder present. Short circuit detection capable. warning : unable to get position geometry ------ When I try to get the log while I move around with PlayerView, then pmaptest gives the following output with the generated logfile; ------ aslund@SDURobot:~$ pmaptest --grid_scale 0.05 mydata2010_09_17_13_24_16.log range_count = 489 range_max = 5.600000 angle_min = -1.500000 angle_max = 1.500000 angle_step = 0.006136 allocating 8192 bytes for scans allocating 607 Mb of map space (estimated lower bound) 0.000 m 0.000 rotations 0 scans 0 steps in 0 seconds -nan msec/scan -nan msec/step ------ My .cfg file is this: ------ driver ( name "hokuyo_aist" provides ["ranger:0"] portopts "type=serial,device=/dev/ttyACM0,timeout=1" min_angle "-1.5" max_angle "1.5" ) driver ( name "rangertolaser" requires ["ranger:0"] # read from ranger:0 provides ["laser:0"] # output results on laser:0 ) driver ( name "roboteq" provides ["position2d:0" "power:0"] devicepath "/dev/ttyS0" motor_control_mode "197" invert_directions "true" encoder_ppr "1024" wheel_circumference "1.28" axle_length "0.255" gear_ratio "7.742" ) driver ( name "writelog" log_directory "/home/aslund" basename "mydata" requires ["laser:0" "position2d:0"] provides ["log:0"] alwayson 1 autorecord 1 ) ------ Thanks for your help. Sebastian Aslund ---------------------------------------------------------------------------- -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Playerstage-users mailing list Pla...@li... https://lists.sourceforge.net/lists/listinfo/playerstage-users ---------------------------------------------------------------------------- -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Playerstage-users mailing list Pla...@li... https://lists.sourceforge.net/lists/listinfo/playerstage-users ---------------------------------------------------------------------------- -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Playerstage-users mailing list Pla...@li... https://lists.sourceforge.net/lists/listinfo/playerstage-users |
From: Aslund <seb...@gm...> - 2010-09-29 17:44:12
|
Hey Rich Instead of doing all these things, then I was wondering if I could create my own writelog file. During the last year have I studied and implemented an Extended Kalman filter, which have proven to be highly precise and stable, so I was wondering if I just could use these information instead. Regards Sebastian On 29 September 2010 18:27, Rich Mattes <jp...@gm...> wrote: > The roboteq has a PID controller inside of it to regulate velocity, and > if you’re using its closed-loop mode you’re seeing that regulate the yawrate > you command. The roboteq will also print out encoder positions, but as I > recall the driver is reading them incorrectly. I would try digging in to > the “UpdatePositionData” function in the roboteq driver and make sure > velocities and positions are being correctly read, scaled, and processed. > > > > Rich > > > > *From:* Aslund [mailto:seb...@gm...] > *Sent:* Tuesday, September 28, 2010 9:22 AM > > *To:* pla...@li... > *Subject:* Re: [Playerstage-users] Problems with writelog and position > geometry > > > > Hey Rich > > I tried to use playerprint and playerjoy to move the robot and see the > odometry data given from position2D. The result was very surprising, > especially theta was jumping around like crazy when I turned the robot. > If I turned the robot a few degrees, then theta changed eg. from -4.1 to > -1.12. It confuses me a great deal because my velocity and rotation speed > commands in Player works fine. > In player I can make a small program that over a given time moves the robot > 360 degrees by setting a fixed rotation velocity, when I do this I get an > error that is only a few degrees, so I am a bit lost the odometry gives so > wrong information when sending motion commands to the robot yield good > results. > > Do you have any idea what might be wrong and even better, how to fix it? > > Ps. > I am using a Roboteq motorcontroller > > Regards > > Sebastian Aslund > > On 24 September 2010 18:14, Rich Mattes <jp...@gm...> wrote: > > Bad odometry alone can indeed give you massive errors; it’s nearly > impossible to track position with odometry alone. This is why SLAM is such > a big problem and there’s so many approaches that deal with data from many > different sensors with okay readings into one pretty-good position > estimate. But I’ll get off my soapbox now. > > > I’d probably go back to the beginning and make sure the Roboteq is > reporting reasonable values for translation and rotation. Looking at the > map, it looks like the roboteq may be over-reporting rotation information > and throwing off the laser corrections. If you can, try plotting the > odometry data you have to see if it makes sense in terms of distance > traversed and yaw angle during turns (it won’t be perfect, but it should be > reasonably similar.) Alternatively, you can watch the robot state in > playerprint and drive your robot with playerjoy: if you move forward a > meter the x position should increase by about 1, if you spin 90 degrees to > the left the yaw position should increase by about pi/2, etc. > > > > Rich > > > > *From:* Aslund [mailto:seb...@gm...] > *Sent:* Friday, September 24, 2010 4:24 AM > > > *To:* pla...@li... > *Subject:* Re: [Playerstage-users] Problems with writelog and position > geometry > > > > Hey > > I have tried to follow the different steps and the map I get is still a > total mess. > I have tried to run the log in PlayerView and the laser information is > perfect with the motion of the robot. > > My room is nearly squared, but then map I get can seen here: > http://yfrog.com/5xfinecj > Can the error in odometry really result in such a bad map? > > Regards > > Sebastian > > On 21 September 2010 15:54, Rich Mattes <jp...@gm...> wrote: > > Hi, > > > > I discovered a bug in the documentation generation…I was going to point you > to the docs for pmap, but they don’t seem to be generated. I’ll point you > to the source it’s generated from instead[1]. The documentation lists a few > parameters you can play with to smooth the map, namely “num_samples.” There > are some examples towards the bottom of the comment block on how to improve > the map output. > > > > Rich > > > > [1] > http://playerstage.svn.sourceforge.net/viewvc/playerstage/code/player/trunk/utils/pmap/pmap_test.cpp?revision=7165&view=markup > > > > *From:* Aslund [mailto:seb...@gm...] > *Sent:* Tuesday, September 21, 2010 9:13 AM > > > *To:* pla...@li... > *Subject:* Re: [Playerstage-users] Problems with writelog and position > geometry > > > > Hey Rich > > Thanks for the information. > I have played a bit more around and found out that pmaptest is able to > produce a map, but only if I disable the GUI, somehow it doesn't work with > GUI enabled. > The new problem is that I get a map out, but the picture is totally wrong > of what it should be and is properly due to the drifting error in my robot's > odometry. The question is the how I counter this problem so I can get a > decent map? > > Regards > > Sebastian > > On 20 September 2010 15:42, Rich Mattes <jp...@gm...> wrote: > > Hi, > > > > Geometry is different from Odometry. When writelog starts up, it sends a > PLAYER_POSITION2D_REQ_GET_GEOM to the position2d devices its logging. The > roboteq driver doesn’t have any code to handle this request, so > ProcessMessage returns -1 and the request is not fulfilled. The geometry > request is used to convey the overall size of the robot; whether or not it > makes sense to handle requests like that from the Roboteq driver is > questionable (maybe via an optional tuple in the config file?) > > > > As far as pmap goes, check to see that logfile.h/cpp (called from > pmap_test.cc) are reading the correct tokens out of your logfile. A cursory > look at the code indicates that if you’re only getting the following message > once is probably having trouble reading from your log file. > > > > 0.000 m 0.000 rotations 0 scans 0 steps in 0 seconds > > -nan msec/scan -nan msec/step > > > > > > Rich > > > > *From:* Aslund [mailto:seb...@gm...] > *Sent:* Monday, September 20, 2010 9:08 AM > *To:* pla...@li... > *Subject:* Re: [Playerstage-users] Problems with writelog and position > geometry > > > > Hey > > I have tried to look into the code an apparently writelog is unable to get > any geometry information, but when I look at the Roboteq driver, then it > updates the geometry if it register encoders, which it does. So if the > roboteq driver publishes position2D information, then why cant writelog not > read them? > > Sebastian > > On 20 September 2010 10:22, Aslund <seb...@gm...> wrote: > > Hey everyone > > I am working on implementing some path planning and for that I need a map. > I have read about how to use writelog and pmaptest to create a grid map, but > sadly I am unable to produce any data in my logs. I hope someone can see > where I go wrong. > When I run player on my robot, then I get the following message: > ------- > Adding position2d interface. > Configuring Roboteq serial port at /dev/ttyS0 > Computed maximum forward velocity of 0.870628 m/s. > Computed maximum rotational velocity of 3.414229 rad/s. > listening on 6665 > Listening on ports: 6665 > AX2500 found. > Encoder present. > Short circuit detection capable. > warning : unable to get position geometry > ------ > > When I try to get the log while I move around with PlayerView, then > pmaptest gives the following output with the generated logfile; > ------ > aslund@SDURobot:~$ pmaptest --grid_scale 0.05 > mydata2010_09_17_13_24_16.log > range_count = 489 > range_max = 5.600000 > angle_min = -1.500000 > angle_max = 1.500000 > angle_step = 0.006136 > allocating 8192 bytes for scans > allocating 607 Mb of map space (estimated lower bound) > 0.000 m 0.000 rotations 0 scans 0 steps in 0 seconds > -nan msec/scan -nan msec/step > ------ > > My .cfg file is this: > ------ > driver > ( > name "hokuyo_aist" > provides ["ranger:0"] > portopts "type=serial,device=/dev/ttyACM0,timeout=1" > min_angle "-1.5" > max_angle "1.5" > ) > > driver > ( > name "rangertolaser" > requires ["ranger:0"] # read from ranger:0 > provides ["laser:0"] # output results on laser:0 > ) > > driver > ( > name "roboteq" > provides ["position2d:0" "power:0"] > devicepath "/dev/ttyS0" > motor_control_mode "197" > invert_directions "true" > encoder_ppr "1024" > wheel_circumference "1.28" > axle_length "0.255" > gear_ratio "7.742" > ) > driver > ( > name "writelog" > log_directory "/home/aslund" > basename "mydata" > requires ["laser:0" "position2d:0"] > provides ["log:0"] > alwayson 1 > autorecord 1 > ) > ------ > > Thanks for your help. > > Sebastian Aslund > > > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > > > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > > > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > > |
From: Rich M. <jp...@gm...> - 2010-10-01 17:28:14
|
The attached logfile is malformed. You're indicating that there are 489 readings on each line, so the log reader is expecting to see 978 separate numbers (489 ranges and 489 intensities, interlaced). Your first line has only 538 total numbers (269 readings), and your second laser line has 1074 numbers (537 readings). You need to indicate the correct number of readings on each line so the log reader knows how many points to expect. Check the log format for more details[1]. Rich [1] http://playerstage.sourceforge.net/doc/Player-svn/player/group__player__driv er__writelog__laser.html From: Aslund [mailto:seb...@gm...] Sent: Friday, October 01, 2010 5:24 AM To: pla...@li... Subject: Re: [Playerstage-users] Problems with writelog and position geometry Hey Rich I have tried to create my own log file, but when I run it in pmaptest, then I get the following error: pmaptest: /home/aslund/PlayerStage/player-3.0.1/utils/pmap/logfile.cpp:158: int logfile_read(logfile_t*): Assertion `self->token_count >= 13 + self->laser_range_count * 2' failed. Aborted A short example is shown in the attachment. Regards Sebastian On 29 September 2010 19:44, Aslund <seb...@gm...> wrote: Hey Rich Instead of doing all these things, then I was wondering if I could create my own writelog file. During the last year have I studied and implemented an Extended Kalman filter, which have proven to be highly precise and stable, so I was wondering if I just could use these information instead. Regards Sebastian On 29 September 2010 18:27, Rich Mattes <jp...@gm...> wrote: The roboteq has a PID controller inside of it to regulate velocity, and if you're using its closed-loop mode you're seeing that regulate the yawrate you command. The roboteq will also print out encoder positions, but as I recall the driver is reading them incorrectly. I would try digging in to the "UpdatePositionData" function in the roboteq driver and make sure velocities and positions are being correctly read, scaled, and processed. Rich From: Aslund [mailto:seb...@gm...] Sent: Tuesday, September 28, 2010 9:22 AM To: pla...@li... Subject: Re: [Playerstage-users] Problems with writelog and position geometry Hey Rich I tried to use playerprint and playerjoy to move the robot and see the odometry data given from position2D. The result was very surprising, especially theta was jumping around like crazy when I turned the robot. If I turned the robot a few degrees, then theta changed eg. from -4.1 to -1.12. It confuses me a great deal because my velocity and rotation speed commands in Player works fine. In player I can make a small program that over a given time moves the robot 360 degrees by setting a fixed rotation velocity, when I do this I get an error that is only a few degrees, so I am a bit lost the odometry gives so wrong information when sending motion commands to the robot yield good results. Do you have any idea what might be wrong and even better, how to fix it? Ps. I am using a Roboteq motorcontroller Regards Sebastian Aslund On 24 September 2010 18:14, Rich Mattes <jp...@gm...> wrote: Bad odometry alone can indeed give you massive errors; it's nearly impossible to track position with odometry alone. This is why SLAM is such a big problem and there's so many approaches that deal with data from many different sensors with okay readings into one pretty-good position estimate. But I'll get off my soapbox now. I'd probably go back to the beginning and make sure the Roboteq is reporting reasonable values for translation and rotation. Looking at the map, it looks like the roboteq may be over-reporting rotation information and throwing off the laser corrections. If you can, try plotting the odometry data you have to see if it makes sense in terms of distance traversed and yaw angle during turns (it won't be perfect, but it should be reasonably similar.) Alternatively, you can watch the robot state in playerprint and drive your robot with playerjoy: if you move forward a meter the x position should increase by about 1, if you spin 90 degrees to the left the yaw position should increase by about pi/2, etc. Rich From: Aslund [mailto:seb...@gm...] Sent: Friday, September 24, 2010 4:24 AM To: pla...@li... Subject: Re: [Playerstage-users] Problems with writelog and position geometry Hey I have tried to follow the different steps and the map I get is still a total mess. I have tried to run the log in PlayerView and the laser information is perfect with the motion of the robot. My room is nearly squared, but then map I get can seen here: http://yfrog.com/5xfinecj Can the error in odometry really result in such a bad map? Regards Sebastian On 21 September 2010 15:54, Rich Mattes <jp...@gm...> wrote: Hi, I discovered a bug in the documentation generation.I was going to point you to the docs for pmap, but they don't seem to be generated. I'll point you to the source it's generated from instead[1]. The documentation lists a few parameters you can play with to smooth the map, namely "num_samples." There are some examples towards the bottom of the comment block on how to improve the map output. Rich [1] http://playerstage.svn.sourceforge.net/viewvc/playerstage/code/player/trunk/ utils/pmap/pmap_test.cpp?revision=7165 <http://playerstage.svn.sourceforge.net/viewvc/playerstage/code/player/trunk /utils/pmap/pmap_test.cpp?revision=7165&view=markup> &view=markup From: Aslund [mailto:seb...@gm...] Sent: Tuesday, September 21, 2010 9:13 AM To: pla...@li... Subject: Re: [Playerstage-users] Problems with writelog and position geometry Hey Rich Thanks for the information. I have played a bit more around and found out that pmaptest is able to produce a map, but only if I disable the GUI, somehow it doesn't work with GUI enabled. The new problem is that I get a map out, but the picture is totally wrong of what it should be and is properly due to the drifting error in my robot's odometry. The question is the how I counter this problem so I can get a decent map? Regards Sebastian On 20 September 2010 15:42, Rich Mattes <jp...@gm...> wrote: Hi, Geometry is different from Odometry. When writelog starts up, it sends a PLAYER_POSITION2D_REQ_GET_GEOM to the position2d devices its logging. The roboteq driver doesn't have any code to handle this request, so ProcessMessage returns -1 and the request is not fulfilled. The geometry request is used to convey the overall size of the robot; whether or not it makes sense to handle requests like that from the Roboteq driver is questionable (maybe via an optional tuple in the config file?) As far as pmap goes, check to see that logfile.h/cpp (called from pmap_test.cc) are reading the correct tokens out of your logfile. A cursory look at the code indicates that if you're only getting the following message once is probably having trouble reading from your log file. 0.000 m 0.000 rotations 0 scans 0 steps in 0 seconds -nan msec/scan -nan msec/step Rich From: Aslund [mailto:seb...@gm...] Sent: Monday, September 20, 2010 9:08 AM To: pla...@li... Subject: Re: [Playerstage-users] Problems with writelog and position geometry Hey I have tried to look into the code an apparently writelog is unable to get any geometry information, but when I look at the Roboteq driver, then it updates the geometry if it register encoders, which it does. So if the roboteq driver publishes position2D information, then why cant writelog not read them? Sebastian On 20 September 2010 10:22, Aslund <seb...@gm...> wrote: Hey everyone I am working on implementing some path planning and for that I need a map. I have read about how to use writelog and pmaptest to create a grid map, but sadly I am unable to produce any data in my logs. I hope someone can see where I go wrong. When I run player on my robot, then I get the following message: ------- Adding position2d interface. Configuring Roboteq serial port at /dev/ttyS0 Computed maximum forward velocity of 0.870628 m/s. Computed maximum rotational velocity of 3.414229 rad/s. listening on 6665 Listening on ports: 6665 AX2500 found. Encoder present. Short circuit detection capable. warning : unable to get position geometry ------ When I try to get the log while I move around with PlayerView, then pmaptest gives the following output with the generated logfile; ------ aslund@SDURobot:~$ pmaptest --grid_scale 0.05 mydata2010_09_17_13_24_16.log range_count = 489 range_max = 5.600000 angle_min = -1.500000 angle_max = 1.500000 angle_step = 0.006136 allocating 8192 bytes for scans allocating 607 Mb of map space (estimated lower bound) 0.000 m 0.000 rotations 0 scans 0 steps in 0 seconds -nan msec/scan -nan msec/step ------ My .cfg file is this: ------ driver ( name "hokuyo_aist" provides ["ranger:0"] portopts "type=serial,device=/dev/ttyACM0,timeout=1" min_angle "-1.5" max_angle "1.5" ) driver ( name "rangertolaser" requires ["ranger:0"] # read from ranger:0 provides ["laser:0"] # output results on laser:0 ) driver ( name "roboteq" provides ["position2d:0" "power:0"] devicepath "/dev/ttyS0" motor_control_mode "197" invert_directions "true" encoder_ppr "1024" wheel_circumference "1.28" axle_length "0.255" gear_ratio "7.742" ) driver ( name "writelog" log_directory "/home/aslund" basename "mydata" requires ["laser:0" "position2d:0"] provides ["log:0"] alwayson 1 autorecord 1 ) ------ Thanks for your help. Sebastian Aslund ---------------------------------------------------------------------------- -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Playerstage-users mailing list Pla...@li... https://lists.sourceforge.net/lists/listinfo/playerstage-users ---------------------------------------------------------------------------- -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Playerstage-users mailing list Pla...@li... https://lists.sourceforge.net/lists/listinfo/playerstage-users ---------------------------------------------------------------------------- -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Playerstage-users mailing list Pla...@li... https://lists.sourceforge.net/lists/listinfo/playerstage-users ---------------------------------------------------------------------------- -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Playerstage-users mailing list Pla...@li... https://lists.sourceforge.net/lists/listinfo/playerstage-users |
From: Aslund <seb...@gm...> - 2010-10-02 01:36:24
|
Hey Rich Thanks for all your help with this, it seems that I got it working now. http://img687.imageshack.us/img687/776/pmaptest.png shows my Stage test, initial robot pose and the resulting map. I am not 100% sure how the writelog and pmaptest program runs, but I guess the laser data should be ordered from beginning to end. Since on my real robot the laser scanner is mounted with the head down, then I have programmed the logging with the end first and beginning last, thus inverting the map. With this in mind, then I think everything looks fine. Again a big thanks. Sebastian On 1 October 2010 19:28, Rich Mattes <jp...@gm...> wrote: > The attached logfile is malformed. You’re indicating that there are 489 > readings on each line, so the log reader is expecting to see 978 separate > numbers (489 ranges and 489 intensities, interlaced). Your first line has > only 538 total numbers (269 readings), and your second laser line has 1074 > numbers (537 readings). You need to indicate the correct number of readings > on each line so the log reader knows how many points to expect. > > > > Check the log format for more details[1]. > > > > Rich > > > > [1] > http://playerstage.sourceforge.net/doc/Player-svn/player/group__player__driver__writelog__laser.html > > > > *From:* Aslund [mailto:seb...@gm...] > *Sent:* Friday, October 01, 2010 5:24 AM > > *To:* pla...@li... > *Subject:* Re: [Playerstage-users] Problems with writelog and position > geometry > > > > Hey Rich > > > I have tried to create my own log file, but when I run it in pmaptest, then > I get the following error: > > pmaptest: /home/aslund/PlayerStage/player-3.0.1/utils/pmap/logfile.cpp:158: > int logfile_read(logfile_t*): Assertion `self->token_count >= 13 + > self->laser_range_count * 2' failed. > Aborted > > A short example is shown in the attachment. > > Regards > > Sebastian > > > > > On 29 September 2010 19:44, Aslund <seb...@gm...> wrote: > > Hey Rich > > Instead of doing all these things, then I was wondering if I could create > my own writelog file. > During the last year have I studied and implemented an Extended Kalman > filter, which have proven to be highly precise and stable, so I was > wondering if I just could use these information instead. > > Regards > > Sebastian > > > > On 29 September 2010 18:27, Rich Mattes <jp...@gm...> wrote: > > The roboteq has a PID controller inside of it to regulate velocity, and if > you’re using its closed-loop mode you’re seeing that regulate the yawrate > you command. The roboteq will also print out encoder positions, but as I > recall the driver is reading them incorrectly. I would try digging in to > the “UpdatePositionData” function in the roboteq driver and make sure > velocities and positions are being correctly read, scaled, and processed. > > > > Rich > > > > *From:* Aslund [mailto:seb...@gm...] > *Sent:* Tuesday, September 28, 2010 9:22 AM > > > *To:* pla...@li... > *Subject:* Re: [Playerstage-users] Problems with writelog and position > geometry > > > > Hey Rich > > I tried to use playerprint and playerjoy to move the robot and see the > odometry data given from position2D. The result was very surprising, > especially theta was jumping around like crazy when I turned the robot. > If I turned the robot a few degrees, then theta changed eg. from -4.1 to > -1.12. It confuses me a great deal because my velocity and rotation speed > commands in Player works fine. > In player I can make a small program that over a given time moves the robot > 360 degrees by setting a fixed rotation velocity, when I do this I get an > error that is only a few degrees, so I am a bit lost the odometry gives so > wrong information when sending motion commands to the robot yield good > results. > > Do you have any idea what might be wrong and even better, how to fix it? > > Ps. > I am using a Roboteq motorcontroller > > Regards > > Sebastian Aslund > > On 24 September 2010 18:14, Rich Mattes <jp...@gm...> wrote: > > Bad odometry alone can indeed give you massive errors; it’s nearly > impossible to track position with odometry alone. This is why SLAM is such > a big problem and there’s so many approaches that deal with data from many > different sensors with okay readings into one pretty-good position > estimate. But I’ll get off my soapbox now. > > > I’d probably go back to the beginning and make sure the Roboteq is > reporting reasonable values for translation and rotation. Looking at the > map, it looks like the roboteq may be over-reporting rotation information > and throwing off the laser corrections. If you can, try plotting the > odometry data you have to see if it makes sense in terms of distance > traversed and yaw angle during turns (it won’t be perfect, but it should be > reasonably similar.) Alternatively, you can watch the robot state in > playerprint and drive your robot with playerjoy: if you move forward a > meter the x position should increase by about 1, if you spin 90 degrees to > the left the yaw position should increase by about pi/2, etc. > > > > Rich > > > > *From:* Aslund [mailto:seb...@gm...] > *Sent:* Friday, September 24, 2010 4:24 AM > > > *To:* pla...@li... > *Subject:* Re: [Playerstage-users] Problems with writelog and position > geometry > > > > Hey > > I have tried to follow the different steps and the map I get is still a > total mess. > I have tried to run the log in PlayerView and the laser information is > perfect with the motion of the robot. > > My room is nearly squared, but then map I get can seen here: > http://yfrog.com/5xfinecj > Can the error in odometry really result in such a bad map? > > Regards > > Sebastian > > On 21 September 2010 15:54, Rich Mattes <jp...@gm...> wrote: > > Hi, > > > > I discovered a bug in the documentation generation…I was going to point you > to the docs for pmap, but they don’t seem to be generated. I’ll point you > to the source it’s generated from instead[1]. The documentation lists a few > parameters you can play with to smooth the map, namely “num_samples.” There > are some examples towards the bottom of the comment block on how to improve > the map output. > > > > Rich > > > > [1] > http://playerstage.svn.sourceforge.net/viewvc/playerstage/code/player/trunk/utils/pmap/pmap_test.cpp?revision=7165&view=markup > > > > *From:* Aslund [mailto:seb...@gm...] > *Sent:* Tuesday, September 21, 2010 9:13 AM > > > *To:* pla...@li... > *Subject:* Re: [Playerstage-users] Problems with writelog and position > geometry > > > > Hey Rich > > Thanks for the information. > I have played a bit more around and found out that pmaptest is able to > produce a map, but only if I disable the GUI, somehow it doesn't work with > GUI enabled. > The new problem is that I get a map out, but the picture is totally wrong > of what it should be and is properly due to the drifting error in my robot's > odometry. The question is the how I counter this problem so I can get a > decent map? > > Regards > > Sebastian > > On 20 September 2010 15:42, Rich Mattes <jp...@gm...> wrote: > > Hi, > > > > Geometry is different from Odometry. When writelog starts up, it sends a > PLAYER_POSITION2D_REQ_GET_GEOM to the position2d devices its logging. The > roboteq driver doesn’t have any code to handle this request, so > ProcessMessage returns -1 and the request is not fulfilled. The geometry > request is used to convey the overall size of the robot; whether or not it > makes sense to handle requests like that from the Roboteq driver is > questionable (maybe via an optional tuple in the config file?) > > > > As far as pmap goes, check to see that logfile.h/cpp (called from > pmap_test.cc) are reading the correct tokens out of your logfile. A cursory > look at the code indicates that if you’re only getting the following message > once is probably having trouble reading from your log file. > > > > 0.000 m 0.000 rotations 0 scans 0 steps in 0 seconds > > -nan msec/scan -nan msec/step > > > > > > Rich > > > > *From:* Aslund [mailto:seb...@gm...] > *Sent:* Monday, September 20, 2010 9:08 AM > *To:* pla...@li... > *Subject:* Re: [Playerstage-users] Problems with writelog and position > geometry > > > > Hey > > I have tried to look into the code an apparently writelog is unable to get > any geometry information, but when I look at the Roboteq driver, then it > updates the geometry if it register encoders, which it does. So if the > roboteq driver publishes position2D information, then why cant writelog not > read them? > > Sebastian > > On 20 September 2010 10:22, Aslund <seb...@gm...> wrote: > > Hey everyone > > I am working on implementing some path planning and for that I need a map. > I have read about how to use writelog and pmaptest to create a grid map, but > sadly I am unable to produce any data in my logs. I hope someone can see > where I go wrong. > When I run player on my robot, then I get the following message: > ------- > Adding position2d interface. > Configuring Roboteq serial port at /dev/ttyS0 > Computed maximum forward velocity of 0.870628 m/s. > Computed maximum rotational velocity of 3.414229 rad/s. > listening on 6665 > Listening on ports: 6665 > AX2500 found. > Encoder present. > Short circuit detection capable. > warning : unable to get position geometry > ------ > > When I try to get the log while I move around with PlayerView, then > pmaptest gives the following output with the generated logfile; > ------ > aslund@SDURobot:~$ pmaptest --grid_scale 0.05 > mydata2010_09_17_13_24_16.log > range_count = 489 > range_max = 5.600000 > angle_min = -1.500000 > angle_max = 1.500000 > angle_step = 0.006136 > allocating 8192 bytes for scans > allocating 607 Mb of map space (estimated lower bound) > 0.000 m 0.000 rotations 0 scans 0 steps in 0 seconds > -nan msec/scan -nan msec/step > ------ > > My .cfg file is this: > ------ > driver > ( > name "hokuyo_aist" > provides ["ranger:0"] > portopts "type=serial,device=/dev/ttyACM0,timeout=1" > min_angle "-1.5" > max_angle "1.5" > ) > > driver > ( > name "rangertolaser" > requires ["ranger:0"] # read from ranger:0 > provides ["laser:0"] # output results on laser:0 > ) > > driver > ( > name "roboteq" > provides ["position2d:0" "power:0"] > devicepath "/dev/ttyS0" > motor_control_mode "197" > invert_directions "true" > encoder_ppr "1024" > wheel_circumference "1.28" > axle_length "0.255" > gear_ratio "7.742" > ) > driver > ( > name "writelog" > log_directory "/home/aslund" > basename "mydata" > requires ["laser:0" "position2d:0"] > provides ["log:0"] > alwayson 1 > autorecord 1 > ) > ------ > > Thanks for your help. > > Sebastian Aslund > > > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > > > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > > > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > > > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > > > > > > > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > > |