From: brian g. <bg...@us...> - 2003-02-05 03:00:20
|
Hi everybody, I've just checked in a slew of changes to Player (and a few changes to Stage), in order to get all robot control on one TCP port. To recap, Player now listens on just one port, even when running in Stage. Each device is identified by the triple: {robot,interface,index}. Thus, with one TCP connection, you can control multiple devices on multiple robots, treating them (if you wish) as one large sensor-actuator network. This change might also prove beneficial with physical robots when combined with the passthrough driver: you can use an auxillary Player server, full of passthrough drivers, to aggregate in one place the data and control for all the robots' devices. It's done, I've tested it a bit, and it seems to work fine. Important changes and notes are below. Let me know if you have problems. Remember that you can check out the tag 'pre-single-port' if you don't want to deal with these changes right now. brian. ------------------------------------------------------------------------------ Player ------------------------------------------------------------------------------ I ended up changing the Player message protocol in the following ways: - The message header now has a 2-byte 'robot' field that specifies to which robot the message pertains (the header is still 32 bytes; I took two bytes out of the 4-byte 'reserved' field). - The device subscription message payload now contains an extra field, to identify the robot to subscribe to. ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ Stage ------------------------------------------------------------------------------ I changed the semantics of the Stage .world file in the following way: - The 'port' keyword for a Player entity now sets the robot id for that entity, *not* the port. This is a temporary situation, as the whole config file setup will change substantially when Richard merges his Stage changes back into HEAD. I add a command-line argument to Stage: - To specify the single port on which Player should listen, pass '-pp <port>' to Stage. ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ C++ Client library ------------------------------------------------------------------------------ I've updated the C++ client (and the underlying C client) to support the protocol changes. I've also add the ability to take advantage of the new robot id mechanism: - When creating a proxy, such as for a position device, you can select the robot id by passing it as the 4th argument to the constructor, e.g.: PositionProxy pp(&playerclient, 0, 'a', 1); If you don't pass the 4th arg, then it's assumed to be 0. I know this is not a great API; I'll polish it later. ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ libplayerc ------------------------------------------------------------------------------ I've updated libplayerc to support the protocol changes, but have *not* added the ability to take advantage of the new robot id mechanism. In particular, this means that libplayerc is currently only capable of controlling the robot (if any) with id 0. playerv works, but gets a little confused by the list of available devices, whose names only differ by robot id. ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ Tclplayer ------------------------------------------------------------------------------ I haven't updated Tclplayer yet. ------------------------------------------------------------------------------ |
From: ahoward <ah...@po...> - 2003-02-05 19:41:18
|
Hi folks: I have updated libplayerc, pyplayerc and playerv to be compatible with Brian's new single-port stuff. The API has changed a little, with proxy creation functions now taking an additional argument to specify which robot to talk to. E.g. laser = playerc_laser_create(client, index); becomes laser = playerc_laser_create(client, robot, index); And similarly for pyplayerc. playerv has aquired an additional command line argument to specify the robot. E.g. playerv -h localhost -p 6665 becomes playerv -h localhost -p 6665 -r 0 You can only talk to one robot at a time, since it makes no sense to connect to multiple robots in playerv. Andrew On Tue, 4 Feb 2003, brian gerkey wrote: > Hi everybody, > > I've just checked in a slew of changes to Player (and a few changes to > Stage), in order to get all robot control on one TCP port. > > To recap, Player now listens on just one port, even when running in Stage. > Each device is identified by the triple: {robot,interface,index}. Thus, > with one TCP connection, you can control multiple devices on multiple > robots, treating them (if you wish) as one large sensor-actuator network. > > This change might also prove beneficial with physical robots when combined > with the passthrough driver: you can use an auxillary Player server, full > of passthrough drivers, to aggregate in one place the data and control > for all the robots' devices. > > It's done, I've tested it a bit, and it seems to work fine. > > Important changes and notes are below. > > Let me know if you have problems. > > Remember that you can check out the tag 'pre-single-port' if you don't want > to deal with these changes right now. > > brian. > > ------------------------------------------------------------------------------ > Player > ------------------------------------------------------------------------------ > I ended up changing the Player message protocol in the following ways: > > - The message header now has a 2-byte 'robot' field that specifies to which > robot the message pertains (the header is still 32 bytes; I took two > bytes out of the 4-byte 'reserved' field). > > - The device subscription message payload now contains an extra field, to > identify the robot to subscribe to. > ------------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Stage > ------------------------------------------------------------------------------ > I changed the semantics of the Stage .world file in the following way: > > - The 'port' keyword for a Player entity now sets the robot id for that > entity, *not* the port. This is a temporary situation, as the whole > config file setup will change substantially when Richard merges his > Stage changes back into HEAD. > > I add a command-line argument to Stage: > > - To specify the single port on which Player should listen, pass > '-pp <port>' to Stage. > ------------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > C++ Client library > ------------------------------------------------------------------------------ > I've updated the C++ client (and the underlying C client) to support the > protocol changes. I've also add the ability to take advantage of the new > robot id mechanism: > > - When creating a proxy, such as for a position device, you can select > the robot id by passing it as the 4th argument to the constructor, e.g.: > > PositionProxy pp(&playerclient, 0, 'a', 1); > > If you don't pass the 4th arg, then it's assumed to be 0. I know this > is not a great API; I'll polish it later. > ------------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > libplayerc > ------------------------------------------------------------------------------ > I've updated libplayerc to support the protocol changes, but have *not* > added the ability to take advantage of the new robot id mechanism. In > particular, this means that libplayerc is currently only capable of > controlling the robot (if any) with id 0. > > playerv works, but gets a little confused by the list of available devices, > whose names only differ by robot id. > ------------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Tclplayer > ------------------------------------------------------------------------------ > I haven't updated Tclplayer yet. > ------------------------------------------------------------------------------ > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > Andrew Howard email: ah...@po... Department of Computer Science http: www-robotics.usc.edu/~ahoward University of Southern California phone: 1 (213) 740 6416 Los Angeles, CA, U.S.A. 90089-0781 fax: 1 (213) 821 5696 << Insert pithy saying here >>> |
From: Josh B. <jb...@bb...> - 2003-02-05 20:11:31
|
I have a Question on version 1.3.1 of Player. I am trying to use the set odometry configuration command (p 29 of manual) for the position device (p2os: amigobot) but player returns a "Position got unknown config request". Has this been implemented yet for p2os? If not what other options do I have for setting the location/orientation of a robot? Thanks, Josh |
From: John S. <sw...@cs...> - 2003-02-05 20:30:18
|
As far I know, that config has only been implemented in our REB robots, which implement "reb_position". You can always just set an initial pose in your client program and then use that to transpose any odometry readings you get from the server. In fact, we have sort of deprecated the set odometry config ourselves, favoring the above method, since the reb & p2os drivers were merged. john Josh Bers wrote: > I have a Question on version 1.3.1 of Player. I am trying to use the set > odometry configuration command (p 29 of manual) for the position device > (p2os: amigobot) but player returns a "Position got unknown config > request". Has this been implemented yet for p2os? If not what other > options do I have for setting the location/orientation of a robot? > > Thanks, > > Josh -- John Sweeney [sw...@cs...] Laboratory for Perceptual Robotics, UMASS, Amherst, MA 01002 USA W:413.545.1876 H:413.549.9694 M:646.541.6081 |
From: brian g. <bg...@us...> - 2003-02-05 22:03:43
|
hi Josh, John's right; that config request has only been implemented in the REB drivers. In general, not all requests for a given interface will be implemented by every driver that supports that interface. The config requests that are supported by the p2os_position driver are listed at the top of page 49 of the Player manual. The p2os driver doesn't support that particular request because the underlying P2OS microcontroller doesn't support arbitrarily setting odometry (it only supports resetting odometry to 0,0,0). It could easily be faked in software in the p2os driver; hmm....I'm more partial to John's client-side solution, but maybe i'll implement the server-side method as well. I'll let you know. brian. On Wed, 5 Feb 2003, John Sweeney wrote: > As far I know, that config has only been implemented in our REB robots, > which implement "reb_position". You can always just set an initial pose > in your client program and then use that to transpose any odometry > readings you get from the server. In fact, we have sort of deprecated > the set odometry config ourselves, favoring the above method, since the > reb & p2os drivers were merged. > > john > > Josh Bers wrote: > > I have a Question on version 1.3.1 of Player. I am trying to use the set > > odometry configuration command (p 29 of manual) for the position device > > (p2os: amigobot) but player returns a "Position got unknown config > > request". Has this been implemented yet for p2os? If not what other > > options do I have for setting the location/orientation of a robot? > > > > Thanks, > > > > Josh > > |
From: brian g. <bg...@us...> - 2003-02-05 23:17:14
|
Josh Bers wrote: > > I have a Question on version 1.3.1 of Player. I am trying to use the set > odometry configuration command (p 29 of manual) for the position device > (p2os: amigobot) but player returns a "Position got unknown config > request". Has this been implemented yet for p2os? If not what other > options do I have for setting the location/orientation of a robot? > hi, I've just implemented this request in the p2os_position driver by maintaining the odometry offset in software. I've only tested it a bit, but it seems to work fine. I've made the change on HEAD, as well as release-1-3-patches, so it will be in the next 1.3.x bugfix release. Also a patch against 1.3.1 is appended. As a side-effect, this patch adds the capability of direct joystick control of P2OS robots (thanks, Boyoon). brian. diff -c --exclude=Make* --exclude=CVS --exclude=*.o --exclude=.* --exclude=*.a /tmp/player-src-1.3.1/server/drivers/mixed/p2os/p2os.cc ./p2os.cc *** /tmp/player-src-1.3.1/server/drivers/mixed/p2os/p2os.cc Fri Nov 29 10:02:39 2002 --- ./p2os.cc Wed Feb 5 14:35:46 2003 *************** *** 21,27 **** */ /* ! * $Id: p2os.cc,v 1.2 2002/11/29 18:02:39 gerkey Exp $ * * the P2OS device. it's the parent device for all the P2 'sub-devices', * like gripper, position, sonar, etc. there's a thread here that --- 21,27 ---- */ /* ! * $Id: p2os.cc,v 1.6 2003/02/05 22:32:50 gerkey Exp $ * * the P2OS device. it's the parent device for all the P2 'sub-devices', * like gripper, position, sonar, etc. there's a thread here that *************** *** 80,85 **** --- 80,86 ---- extern int P2OS::psos_fd; extern char P2OS::psos_serial_port[]; extern int P2OS::radio_modemp; + extern int P2OS::joystickp; extern bool P2OS::initdone; extern char P2OS::num_loops_since_rvel; extern SIP* P2OS::sippacket; *************** *** 107,112 **** --- 108,114 ---- strncpy(psos_serial_port,DEFAULT_P2OS_PORT,sizeof(psos_serial_port)); psos_fd = -1; radio_modemp = 0; + joystickp = 0; data = new player_p2os_data_t; command = new player_p2os_cmd_t; *************** *** 150,155 **** --- 152,158 ---- cf->ReadString(section, "port", psos_serial_port), sizeof(psos_serial_port)); radio_modemp = cf->ReadInt(section, "radio", radio_modemp); + joystickp = cf->ReadInt(section, "joystick", joystickp); // zero the subscription counter. subscriptions = 0; *************** *** 419,424 **** --- 422,439 ---- sonarpacket.Build(sonarcommand, 4); SendReceive(&sonarpacket); + if(joystickp) + { + // enable joystick control + P2OSPacket js_packet; + unsigned char js_command[4]; + js_command[0] = JOYDRIVE; + js_command[1] = 0x3B; + js_command[2] = 1; + js_command[3] = 0; + js_packet.Build(js_command, 4); + SendReceive(&js_packet); + } /* now spawn reading thread */ StartThread(); *************** *** 625,630 **** --- 640,648 ---- last_sonar_subscrcount = 0; last_position_subscrcount = 0; + if(sippacket) + sippacket->x_offset = sippacket->y_offset = sippacket->angle_offset = 0; + GlobalTime->GetTime(&timeBegan_tv); // request the current configuration *************** *** 785,790 **** --- 803,835 ---- case PLAYER_POSITION_CODE: switch(config[0]) { + case PLAYER_POSITION_SET_ODOM_REQ: + if(config_size != sizeof(player_position_set_odom_req_t)) + { + puts("Arg to odometry set requests wrong size; ignoring"); + if(PutReply(&id, client, PLAYER_MSGTYPE_RESP_NACK, + NULL, NULL, 0)) + PLAYER_ERROR("failed to PutReply"); + break; + } + + player_position_set_odom_req_t set_odom_req; + set_odom_req = *((player_position_set_odom_req_t*)config); + + if(sippacket) + { + sippacket->x_offset = ntohl(set_odom_req.x) - + sippacket->xpos; + sippacket->y_offset = ntohl(set_odom_req.y) - + sippacket->ypos; + sippacket->angle_offset = ntohs(set_odom_req.theta) - + sippacket->angle; + } + + if(PutReply(&id, client, PLAYER_MSGTYPE_RESP_ACK, NULL, NULL, 0)) + PLAYER_ERROR("failed to PutReply"); + break; + case PLAYER_POSITION_MOTOR_POWER_REQ: /* motor state change request * 1 = enable motors diff -c --exclude=Make* --exclude=CVS --exclude=*.o --exclude=.* --exclude=*.a /tmp/player-src-1.3.1/server/drivers/mixed/p2os/p2os.h ./p2os.h *** /tmp/player-src-1.3.1/server/drivers/mixed/p2os/p2os.h Fri Nov 29 09:07:36 2002 --- ./p2os.h Wed Feb 5 14:35:35 2003 *************** *** 21,27 **** */ /* ! * $Id: p2os.h,v 1.1 2002/11/29 17:07:36 gerkey Exp $ * * the P2OS device. it's the parent device for all the P2 'sub-devices', * like gripper, position, sonar, etc. there's a thread here that --- 21,27 ---- */ /* ! * $Id: p2os.h,v 1.2 2003/01/28 00:32:55 gerkey Exp $ * * the P2OS device. it's the parent device for all the P2 'sub-devices', * like gripper, position, sonar, etc. there's a thread here that *************** *** 69,74 **** --- 69,75 ---- #define GRIPPERVAL 36 #define TTY2 42 #define GETAUX 43 + #define JOYDRIVE 47 /* gripper stuff */ #define GRIPopen 1 *************** *** 145,150 **** --- 146,152 ---- // device used to communicate with p2os static char psos_serial_port[MAX_FILENAME_SIZE]; static int radio_modemp; // are we using a radio modem? + static int joystickp; // are we using a joystick? static struct timeval timeBegan_tv; diff -c --exclude=Make* --exclude=CVS --exclude=*.o --exclude=.* --exclude=*.a /tmp/player-src-1.3.1/server/drivers/mixed/p2os/sip.cc ./sip.cc *** /tmp/player-src-1.3.1/server/drivers/mixed/p2os/sip.cc Fri Nov 29 09:07:44 2002 --- ./sip.cc Wed Feb 5 14:35:33 2003 *************** *** 21,27 **** */ /* ! * $Id: sip.cc,v 1.1 2002/11/29 17:07:44 gerkey Exp $ * * part of the P2OS parser. methods for filling and parsing server * information packets (SIPs) --- 21,27 ---- */ /* ! * $Id: sip.cc,v 1.2 2003/02/05 22:32:50 gerkey Exp $ * * part of the P2OS parser. methods for filling and parsing server * information packets (SIPs) *************** *** 47,55 **** /* time and position */ //data->position.time = htonl((unsigned int)timeNow); ! data->position.xpos = htonl((int32_t)xpos); ! data->position.ypos = htonl((int32_t)ypos); ! data->position.yaw = htonl((int32_t)angle); data->position.xspeed = htonl((int32_t) (((lvel) + (rvel) ) / 2)); data->position.yawspeed = htonl((int32_t) (180*((double)(rvel - lvel) / --- 47,55 ---- /* time and position */ //data->position.time = htonl((unsigned int)timeNow); ! data->position.xpos = htonl((int32_t)(xpos + x_offset)); ! data->position.ypos = htonl((int32_t)(ypos + y_offset)); ! data->position.yaw = htonl((int32_t)(angle + angle_offset)); data->position.xspeed = htonl((int32_t) (((lvel) + (rvel) ) / 2)); data->position.yawspeed = htonl((int32_t) (180*((double)(rvel - lvel) / diff -c --exclude=Make* --exclude=CVS --exclude=*.o --exclude=.* --exclude=*.a /tmp/player-src-1.3.1/server/drivers/mixed/p2os/sip.h ./sip.h *** /tmp/player-src-1.3.1/server/drivers/mixed/p2os/sip.h Fri Nov 29 09:07:47 2002 --- ./sip.h Wed Feb 5 14:35:33 2003 *************** *** 21,27 **** */ /* ! * $Id: sip.h,v 1.1 2002/11/29 17:07:47 gerkey Exp $ * * part of the P2OS parser. methods for filling and parsing server * information packets (SIPs) --- 21,27 ---- */ /* ! * $Id: sip.h,v 1.2 2003/02/05 22:32:50 gerkey Exp $ * * part of the P2OS parser. methods for filling and parsing server * information packets (SIPs) *************** *** 48,53 **** --- 48,54 ---- short angle, lvel, rvel, control; unsigned short sonars[PLAYER_SONAR_MAX_SAMPLES]; int xpos, ypos; + int x_offset,y_offset,angle_offset; /* returns 0 if Parsed correctly otherwise 1 */ void Parse( unsigned char *buffer ); |
From: Josh B. <jb...@bb...> - 2003-02-06 15:11:58
|
Brian, Thanks for the quick turnaround. However, I believe that the offset that you implemented will not work as expected. The problem is one of reference frames. If I displace the position via an x,y offset but not the orientation then odometry will continue to work. If however, I change the orientation of the robot w/ respect to its internal coordinate frame then a rotation must be applied before translating the robot's position by an offset. I think that one must also reset the robot's internal odometry any time a set odometry is issued. The way I see this command being used is to give a transformation from a global reference frame to the robots internal odometry and therefore perhaps your and John's instincts of keeping it in the client code are appropriate (since the client knows the global refernce frame). The code for transforming a local odometry into a global one via a transformation looks something like: Given: Transform = rotate(theta), translate(x_off, y_off) Then: x(global) = (x(local) * cos(theta) - y(local) * sin(theta)) + x_off y(global) = (x(local) * sin(theta) + y(local) * cos(theta)) + y_off Josh -----Original Message----- From: pla...@li... [mailto:pla...@li...] On Behalf Of brian gerkey Sent: Wednesday, February 05, 2003 6:12 PM To: John Sweeney Cc: 'Player/Stage Developers' Subject: Re: [Playerstage-developers] Position device question Josh Bers wrote: > > I have a Question on version 1.3.1 of Player. I am trying to use the > set odometry configuration command (p 29 of manual) for the position > device > (p2os: amigobot) but player returns a "Position got unknown config > request". Has this been implemented yet for p2os? If not what other > options do I have for setting the location/orientation of a robot? > hi, I've just implemented this request in the p2os_position driver by maintaining the odometry offset in software. I've only tested it a bit, but it seems to work fine. I've made the change on HEAD, as well as release-1-3-patches, so it will be in the next 1.3.x bugfix release. Also a patch against 1.3.1 is appended. As a side-effect, this patch adds the capability of direct joystick control of P2OS robots (thanks, Boyoon). brian. diff -c --exclude=Make* --exclude=CVS --exclude=*.o --exclude=.* --exclude=*.a /tmp/player-src-1.3.1/server/drivers/mixed/p2os/p2os.cc ./p2os.cc *** /tmp/player-src-1.3.1/server/drivers/mixed/p2os/p2os.cc Fri Nov 29 10:02:39 2002 --- ./p2os.cc Wed Feb 5 14:35:46 2003 *************** *** 21,27 **** */ /* ! * $Id: p2os.cc,v 1.2 2002/11/29 18:02:39 gerkey Exp $ * * the P2OS device. it's the parent device for all the P2 'sub-devices', * like gripper, position, sonar, etc. there's a thread here that --- 21,27 ---- */ /* ! * $Id: p2os.cc,v 1.6 2003/02/05 22:32:50 gerkey Exp $ * * the P2OS device. it's the parent device for all the P2 'sub-devices', * like gripper, position, sonar, etc. there's a thread here that *************** *** 80,85 **** --- 80,86 ---- extern int P2OS::psos_fd; extern char P2OS::psos_serial_port[]; extern int P2OS::radio_modemp; + extern int P2OS::joystickp; extern bool P2OS::initdone; extern char P2OS::num_loops_since_rvel; extern SIP* P2OS::sippacket; *************** *** 107,112 **** --- 108,114 ---- strncpy(psos_serial_port,DEFAULT_P2OS_PORT,sizeof(psos_serial_port)); psos_fd = -1; radio_modemp = 0; + joystickp = 0; data = new player_p2os_data_t; command = new player_p2os_cmd_t; *************** *** 150,155 **** --- 152,158 ---- cf->ReadString(section, "port", psos_serial_port), sizeof(psos_serial_port)); radio_modemp = cf->ReadInt(section, "radio", radio_modemp); + joystickp = cf->ReadInt(section, "joystick", joystickp); // zero the subscription counter. subscriptions = 0; *************** *** 419,424 **** --- 422,439 ---- sonarpacket.Build(sonarcommand, 4); SendReceive(&sonarpacket); + if(joystickp) + { + // enable joystick control + P2OSPacket js_packet; + unsigned char js_command[4]; + js_command[0] = JOYDRIVE; + js_command[1] = 0x3B; + js_command[2] = 1; + js_command[3] = 0; + js_packet.Build(js_command, 4); + SendReceive(&js_packet); + } /* now spawn reading thread */ StartThread(); *************** *** 625,630 **** --- 640,648 ---- last_sonar_subscrcount = 0; last_position_subscrcount = 0; + if(sippacket) + sippacket->x_offset = sippacket->y_offset = + sippacket->angle_offset = 0; + GlobalTime->GetTime(&timeBegan_tv); // request the current configuration *************** *** 785,790 **** --- 803,835 ---- case PLAYER_POSITION_CODE: switch(config[0]) { + case PLAYER_POSITION_SET_ODOM_REQ: + if(config_size != sizeof(player_position_set_odom_req_t)) + { + puts("Arg to odometry set requests wrong size; ignoring"); + if(PutReply(&id, client, PLAYER_MSGTYPE_RESP_NACK, + NULL, NULL, 0)) + PLAYER_ERROR("failed to PutReply"); + break; + } + + player_position_set_odom_req_t set_odom_req; + set_odom_req = + *((player_position_set_odom_req_t*)config); + + if(sippacket) + { + sippacket->x_offset = ntohl(set_odom_req.x) - + sippacket->xpos; + sippacket->y_offset = ntohl(set_odom_req.y) - + sippacket->ypos; + sippacket->angle_offset = ntohs(set_odom_req.theta) - + sippacket->angle; + } + + if(PutReply(&id, client, PLAYER_MSGTYPE_RESP_ACK, NULL, NULL, 0)) + PLAYER_ERROR("failed to PutReply"); + break; + case PLAYER_POSITION_MOTOR_POWER_REQ: /* motor state change request * 1 = enable motors diff -c --exclude=Make* --exclude=CVS --exclude=*.o --exclude=.* --exclude=*.a /tmp/player-src-1.3.1/server/drivers/mixed/p2os/p2os.h ./p2os.h *** /tmp/player-src-1.3.1/server/drivers/mixed/p2os/p2os.h Fri Nov 29 09:07:36 2002 --- ./p2os.h Wed Feb 5 14:35:35 2003 *************** *** 21,27 **** */ /* ! * $Id: p2os.h,v 1.1 2002/11/29 17:07:36 gerkey Exp $ * * the P2OS device. it's the parent device for all the P2 'sub-devices', * like gripper, position, sonar, etc. there's a thread here that --- 21,27 ---- */ /* ! * $Id: p2os.h,v 1.2 2003/01/28 00:32:55 gerkey Exp $ * * the P2OS device. it's the parent device for all the P2 'sub-devices', * like gripper, position, sonar, etc. there's a thread here that *************** *** 69,74 **** --- 69,75 ---- #define GRIPPERVAL 36 #define TTY2 42 #define GETAUX 43 + #define JOYDRIVE 47 /* gripper stuff */ #define GRIPopen 1 *************** *** 145,150 **** --- 146,152 ---- // device used to communicate with p2os static char psos_serial_port[MAX_FILENAME_SIZE]; static int radio_modemp; // are we using a radio modem? + static int joystickp; // are we using a joystick? static struct timeval timeBegan_tv; diff -c --exclude=Make* --exclude=CVS --exclude=*.o --exclude=.* --exclude=*.a /tmp/player-src-1.3.1/server/drivers/mixed/p2os/sip.cc ./sip.cc *** /tmp/player-src-1.3.1/server/drivers/mixed/p2os/sip.cc Fri Nov 29 09:07:44 2002 --- ./sip.cc Wed Feb 5 14:35:33 2003 *************** *** 21,27 **** */ /* ! * $Id: sip.cc,v 1.1 2002/11/29 17:07:44 gerkey Exp $ * * part of the P2OS parser. methods for filling and parsing server * information packets (SIPs) --- 21,27 ---- */ /* ! * $Id: sip.cc,v 1.2 2003/02/05 22:32:50 gerkey Exp $ * * part of the P2OS parser. methods for filling and parsing server * information packets (SIPs) *************** *** 47,55 **** /* time and position */ //data->position.time = htonl((unsigned int)timeNow); ! data->position.xpos = htonl((int32_t)xpos); ! data->position.ypos = htonl((int32_t)ypos); ! data->position.yaw = htonl((int32_t)angle); data->position.xspeed = htonl((int32_t) (((lvel) + (rvel) ) / 2)); data->position.yawspeed = htonl((int32_t) (180*((double)(rvel - lvel) / --- 47,55 ---- /* time and position */ //data->position.time = htonl((unsigned int)timeNow); ! data->position.xpos = htonl((int32_t)(xpos + x_offset)); ! data->position.ypos = htonl((int32_t)(ypos + y_offset)); ! data->position.yaw = htonl((int32_t)(angle + angle_offset)); data->position.xspeed = htonl((int32_t) (((lvel) + (rvel) ) / 2)); data->position.yawspeed = htonl((int32_t) (180*((double)(rvel - lvel) / diff -c --exclude=Make* --exclude=CVS --exclude=*.o --exclude=.* --exclude=*.a /tmp/player-src-1.3.1/server/drivers/mixed/p2os/sip.h ./sip.h *** /tmp/player-src-1.3.1/server/drivers/mixed/p2os/sip.h Fri Nov 29 09:07:47 2002 --- ./sip.h Wed Feb 5 14:35:33 2003 *************** *** 21,27 **** */ /* ! * $Id: sip.h,v 1.1 2002/11/29 17:07:47 gerkey Exp $ * * part of the P2OS parser. methods for filling and parsing server * information packets (SIPs) --- 21,27 ---- */ /* ! * $Id: sip.h,v 1.2 2003/02/05 22:32:50 gerkey Exp $ * * part of the P2OS parser. methods for filling and parsing server * information packets (SIPs) *************** *** 48,53 **** --- 48,54 ---- short angle, lvel, rvel, control; unsigned short sonars[PLAYER_SONAR_MAX_SAMPLES]; int xpos, ypos; + int x_offset,y_offset,angle_offset; /* returns 0 if Parsed correctly otherwise 1 */ void Parse( unsigned char *buffer ); ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Playerstage-developers mailing list Pla...@li... https://lists.sourceforge.net/lists/listinfo/playerstage-developers |
From: brian g. <bg...@us...> - 2003-02-06 18:58:43
|
On Thu, 6 Feb 2003, Josh Bers wrote: > Thanks for the quick turnaround. However, I believe that the offset that > you implemented will not work as expected. The problem is one of > reference frames. If I displace the position via an x,y offset but not > the orientation then odometry will continue to work. If however, I > change the orientation of the robot w/ respect to its internal > coordinate frame then a rotation must be applied before translating the > robot's position by an offset. I think that one must also reset the > robot's internal odometry any time a set odometry is issued. > > The way I see this command being used is to give a transformation from a > global reference frame to the robots internal odometry and therefore > perhaps your and John's instincts of keeping it in the client code are > appropriate (since the client knows the global refernce frame). The code > for transforming a local odometry into a global one via a transformation > looks something like: > > Given: Transform = rotate(theta), translate(x_off, y_off) > > Then: x(global) = (x(local) * cos(theta) - y(local) * sin(theta)) + > x_off > y(global) = (x(local) * sin(theta) + y(local) * cos(theta)) + > y_off > Josh, Good point; you're quite right. I instinctively shy away from coordinate transforms, cause I usually get them wrong. Now the question is: should we implement this odometry assignment functionality properly in the P2OS driver? It would add some FP math into the loop, which I'm guessing won't run well on embedded systems like the iPAQ. However, now that I think about it, there's already some FP math in there, to convert from robot-specific units (e.g., encoder ticks) to externally meaningful units (e.g., meters). Does anyone know *how* bad FP math is on systems without FPUs? Should it really be a concern, or are modern processors so fast that it doesn't really matter? brian. |
From: Josh B. <jb...@bb...> - 2003-02-06 20:36:06
|
Brian, I think that the floating point math is less of a concern than correct/expected functionality. Since only the reset of odometry is supported by p2os, I think that it is perfectly reasonable that the player driver not support the set odometry configuration command. It is then always the responsibility of the client app to maintain global coordinate frame transformations. However, to take the side of device independence, it would be nice for all player devices to support all api calls. In this case, I would argue that we should implement it for p2os, or take it out of the api. BTW. I forgot to say that the transformed heading would become: Assuming theta = angle of offset in degrees Heading(global) = (heading(local) + theta) % 360 Josh -----Original Message----- From: pla...@li... [mailto:pla...@li...] On Behalf Of brian gerkey Sent: Thursday, February 06, 2003 1:59 PM To: Josh Bers Cc: 'Player/Stage Developers' Subject: RE: [Playerstage-developers] Position device question On Thu, 6 Feb 2003, Josh Bers wrote: > Thanks for the quick turnaround. However, I believe that the offset > that you implemented will not work as expected. The problem is one of > reference frames. If I displace the position via an x,y offset but not > the orientation then odometry will continue to work. If however, I > change the orientation of the robot w/ respect to its internal > coordinate frame then a rotation must be applied before translating > the robot's position by an offset. I think that one must also reset > the robot's internal odometry any time a set odometry is issued. > > The way I see this command being used is to give a transformation from > a global reference frame to the robots internal odometry and therefore > perhaps your and John's instincts of keeping it in the client code are > appropriate (since the client knows the global refernce frame). The > code for transforming a local odometry into a global one via a > transformation looks something like: > > Given: Transform = rotate(theta), translate(x_off, y_off) > > Then: x(global) = (x(local) * cos(theta) - y(local) * sin(theta)) + > x_off > y(global) = (x(local) * sin(theta) + y(local) * cos(theta)) + y_off > Josh, Good point; you're quite right. I instinctively shy away from coordinate transforms, cause I usually get them wrong. Now the question is: should we implement this odometry assignment functionality properly in the P2OS driver? It would add some FP math into the loop, which I'm guessing won't run well on embedded systems like the iPAQ. However, now that I think about it, there's already some FP math in there, to convert from robot-specific units (e.g., encoder ticks) to externally meaningful units (e.g., meters). Does anyone know *how* bad FP math is on systems without FPUs? Should it really be a concern, or are modern processors so fast that it doesn't really matter? brian. ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Playerstage-developers mailing list Pla...@li... https://lists.sourceforge.net/lists/listinfo/playerstage-developers |
From: John S. <sw...@cs...> - 2003-02-06 21:24:39
|
Josh Bers wrote: > > However, to take the side of device independence, it would be nice for > all player devices to support all api calls. In this case, I would argue > that we should implement it for p2os, or take it out of the api. > I wouldn't mind if we removed SetOdometry. john -- John Sweeney [sw...@cs...] Laboratory for Perceptual Robotics, UMASS, Amherst, MA 01002 USA W:413.545.1876 H:413.549.9694 M:646.541.6081 |
From: ahoward <ah...@po...> - 2003-02-09 18:29:52
|
On Thu, 6 Feb 2003, brian gerkey wrote: > Does anyone know *how* bad FP math is on systems without FPUs? Should it > really be a concern, or are modern processors so fast that it doesn't really > matter? For the coordinate transformation you are proposing, emulated FPU is no problem whatsoever (microseconds). That's assuming your target of choice as an emulation lib, of course. A. Andrew Howard email: ah...@po... Department of Computer Science http: www-robotics.usc.edu/~ahoward University of Southern California phone: 1 (213) 740 6416 Los Angeles, CA, U.S.A. 90089-0781 fax: 1 (213) 821 5696 << Insert pithy saying here >>> |