From: pablis <pau...@ho...> - 2011-01-18 13:51:48
|
Hi all, I'm trying to set up communication over a TCP connection using PlayerTCP. However, I'm not quite getting it ( %-| ) and was wondering if those in the know might comment on the below approach I'm using:- sockaddr_in saddr; m_pTCP = new PlayerTCP(); int newsock; PlayerTCP::InitGlobals(); saddr.sin_addr.s_addr = inet_addr( IP_OF_REMOTE MACHINE ); saddr.sin_family = AF_INET; saddr.sin_port = PORT_OF_REMOTE_MACHINE; // add client QueuePointer q = m_pTCP->AddClient(&saddr, inet_addr( LOCAL_IP ), htons( LOCAL_PORT ), newsock, false, NULL, true))); m_pTCP->Listen( LOCAL_PORT ); I think this is the correct way to set up my local machine to listen out for incoming messages, and make the local system aware of the REMOTE client. This bit seems to work ok. However, I get a problem when I execute the following lines:- player_msghdr h; int * data = new int[10]; for(int i = 0; i < 10; i++) data[i] = 10*i; h.type = PLAYER_MSGTYPE_DATA; h.size = 12; Message m(h, data, false); // ok q->get()->Push(m); // error I would expect that I get() the MessageQueue pointer from the QueuePointer associated with the client I added previously, and Push() message m onto it. This last push, however, fails and I get segmentation fault. I've checked q and it's a valid address. I'm not sure I'm setting things up right though, since if I add more clients, with QueuePointers q1, q2, q3, etc., I find that their QueuePointer values are all the same ! :confused: Assuming the above problem can be resolved, then I'm guessing I would also have to issue something like a Write(client) to get everything off the queue which I push onto it (but that's my next problem...) Cheers :working:, Paul -- View this message in context: http://old.nabble.com/PlayerTCP-tp30700376p30700376.html Sent from the playerstage-users mailing list archive at Nabble.com. |
From: pablis <pau...@ho...> - 2011-01-19 11:04:17
|
Hi all, Been working on this for a day now and I've found out the following: When using PlayerTCP, the only way I can seem to get a connection is to issue a Listen(7000) on port 7000, for example, then issue an Accept(10000), for example. Then, using telnet, open a connection with the localhost on port 7000. The Accept() function of PlayerTCP (in my program) then connects to telnet ok. However, I cannot get the QueuePointer for the connection which AddClient (in Accept) returns ! I've looked at the PlayerTCP cc file only to find that Accept does not return the QueuePointer ! What's the point in that? Still trying :confused: ... Thanks, Paul. -- View this message in context: http://old.nabble.com/PlayerTCP-tp30700376p30706268.html Sent from the playerstage-users mailing list archive at Nabble.com. |
From: Rich M. <jp...@gm...> - 2011-01-19 15:01:58
|
> -----Original Message----- > From: pablis [mailto:pau...@ho...] > Sent: Wednesday, January 19, 2011 6:04 AM > To: pla...@li... > Subject: Re: [Playerstage-users] PlayerTCP > > > Hi all, > > Been working on this for a day now and I've found out the following: > > When using PlayerTCP, the only way I can seem to get a connection is to > issue a Listen(7000) on port 7000, for example, then issue an > Accept(10000), > for example. Then, using telnet, open a connection with the localhost > on > port 7000. The Accept() function of PlayerTCP (in my program) then > connects > to telnet ok. However, I cannot get the QueuePointer for the connection > which AddClient (in Accept) returns ! I've looked at the PlayerTCP cc > file > only to find that Accept does not return the QueuePointer ! What's the > point > in that? Still trying :confused: ... > > Thanks, > Paul. Accept() calls AddClient(), which creates the queue pointer for the client and stores it in the PlayerTCP class-level "clients" array (this->clients[j]->queue). You should be able to retrieve it from there. I'm curious as to what you're trying to accomplish here, are you trying to make your own Player server? Is there any reason you can't use the playerc/playerc++ client libraries to do what you want? Rich |
From: pablis <pau...@ho...> - 2011-01-19 15:23:42
|
Rich Mattes-2 wrote: > >> -----Original Message----- >> From: pablis [mailto:pau...@ho...] >> Sent: Wednesday, January 19, 2011 6:04 AM >> To: pla...@li... >> Subject: Re: [Playerstage-users] PlayerTCP >> >> >> Hi all, >> >> Been working on this for a day now and I've found out the following: >> >> When using PlayerTCP, the only way I can seem to get a connection is to >> issue a Listen(7000) on port 7000, for example, then issue an >> Accept(10000), >> for example. Then, using telnet, open a connection with the localhost >> on >> port 7000. The Accept() function of PlayerTCP (in my program) then >> connects >> to telnet ok. However, I cannot get the QueuePointer for the connection >> which AddClient (in Accept) returns ! I've looked at the PlayerTCP cc >> file >> only to find that Accept does not return the QueuePointer ! What's the >> point >> in that? Still trying :confused: ... >> >> Thanks, >> Paul. > > Accept() calls AddClient(), which creates the queue pointer for the client > and stores it in the PlayerTCP class-level "clients" array > (this->clients[j]->queue). You should be able to retrieve it from there. > > I'm curious as to what you're trying to accomplish here, are you trying to > make your own Player server? Is there any reason you can't use the > playerc/playerc++ client libraries to do what you want? > > Rich > > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > > Hi Rich, Thanks for the reply. Unfortunately the class-level "client" data member is private, and moreover it points to a bunch of playertcp_conn objects (maybe the playertcp_conn object gives access to the QueuePointer instantiation; but even if it did, I can't get at them due to the private construct) In answer to your question, I'm basically trying to communicate data between robots. I want to be able to send my own commands and transmit my own data. I thought the PlayerTCP class was the way to do this? Are you saying I can transfer my own commands between robots over the player ports? I'll look into this now, but whilst I'm here, I'll ask: how? Thanks again, Paul -- View this message in context: http://old.nabble.com/PlayerTCP-tp30700376p30710857.html Sent from the playerstage-users mailing list archive at Nabble.com. |
From: G. C. <gch...@ie...> - 2011-01-19 15:47:51
|
unless you are trying to do sthg more complex than usual, why not use the passthrough driver? On 19 January 2011 15:23, pablis <pau...@ho...> wrote: > > > > Rich Mattes-2 wrote: >> >>> -----Original Message----- >>> From: pablis [mailto:pau...@ho...] >>> Sent: Wednesday, January 19, 2011 6:04 AM >>> To: pla...@li... >>> Subject: Re: [Playerstage-users] PlayerTCP >>> >>> >>> Hi all, >>> >>> Been working on this for a day now and I've found out the following: >>> >>> When using PlayerTCP, the only way I can seem to get a connection is to >>> issue a Listen(7000) on port 7000, for example, then issue an >>> Accept(10000), >>> for example. Then, using telnet, open a connection with the localhost >>> on >>> port 7000. The Accept() function of PlayerTCP (in my program) then >>> connects >>> to telnet ok. However, I cannot get the QueuePointer for the connection >>> which AddClient (in Accept) returns ! I've looked at the PlayerTCP cc >>> file >>> only to find that Accept does not return the QueuePointer ! What's the >>> point >>> in that? Still trying :confused: ... >>> >>> Thanks, >>> Paul. >> >> Accept() calls AddClient(), which creates the queue pointer for the client >> and stores it in the PlayerTCP class-level "clients" array >> (this->clients[j]->queue). You should be able to retrieve it from there. >> >> I'm curious as to what you're trying to accomplish here, are you trying to >> make your own Player server? Is there any reason you can't use the >> playerc/playerc++ client libraries to do what you want? >> >> Rich >> >> >> ------------------------------------------------------------------------------ >> Protect Your Site and Customers from Malware Attacks >> Learn about various malware tactics and how to avoid them. Understand >> malware threats, the impact they can have on your business, and how you >> can protect your company and customers by using code signing. >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Playerstage-users mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-users >> >> > > Hi Rich, > > Thanks for the reply. Unfortunately the class-level "client" data member is > private, and moreover it points to a bunch of playertcp_conn objects (maybe > the playertcp_conn object gives access to the QueuePointer instantiation; > but even if it did, I can't get at them due to the private construct) > > In answer to your question, I'm basically trying to communicate data between > robots. I want to be able to send my own commands and transmit my own data. > I thought the PlayerTCP class was the way to do this? Are you saying I can > transfer my own commands between robots over the player ports? I'll look > into this now, but whilst I'm here, I'll ask: how? > > Thanks again, > Paul > > -- > View this message in context: http://old.nabble.com/PlayerTCP-tp30700376p30710857.html > Sent from the playerstage-users mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > |
From: Rich M. <jp...@gm...> - 2011-01-19 16:01:22
|
> Hi Rich, > > Thanks for the reply. Unfortunately the class-level "client" data > member is > private, and moreover it points to a bunch of playertcp_conn objects > (maybe > the playertcp_conn object gives access to the QueuePointer > instantiation; > but even if it did, I can't get at them due to the private construct) > > In answer to your question, I'm basically trying to communicate data > between > robots. I want to be able to send my own commands and transmit my own > data. > I thought the PlayerTCP class was the way to do this? Are you saying I > can > transfer my own commands between robots over the player ports? I'll > look > into this now, but whilst I'm here, I'll ask: how? > > Thanks again, > Paul > Player is designed to be able to transfer commands and data between robots and clients, there's no need to hack with the internal libraries to accomplish this. Depending on what your topology is, what kind of data you want to transfer, etc., there are several ways to go about what you want to do. The easiest way to coordinate multiple robots is to write a client program using one of the client libraries (C, C++, python, ruby) that will subscribe to a Player server running on each robot. This client can be run on one of your robots, or on a separate computer. The client program can listen for data coming from both robots, and issue commands to both robots. There are lots of samples in examples/{libplayerc,libplayerc++,python,ruby}, and all of the utilities like playerprint, playerjoy, and playercam make use the client libraries If you want your robots to publish data that doesn't fit into one of the existing interfaces, you can do one of two things. First, you can use Player's "opaque" interface. The opaque interface allows you to transfer any arbitrary data through the Player message-passing framework. As long as the sender and receiver both know what the data is (for instance, it could be a my_custom_data_struct_t that you define), they'll be able to encode/decode the data successfully. See examples/drivers/opaquedriver/opaquedriver.cc for a sample implementation. You can create your own new interface, and define the different command, request, and data messages and structs. See libplayerinterface/interfaces/ADDING_INTERFACES for details, and the *.def files in the interfaces folder for examples. If you prefer not to write a client, you can use something like the "blackboard" interface. Each robot's driver can subscribe to the blackboard driver, and post its own information there. They can also read information that other robots post there. If you can be more specific about what you're doing (which robots & drivers you're using, what you want the robots to do, what data you want to pass back and forth, etc.) we'll probably be able to give you better guidance. Rich |
From: Geoffrey B. <geo...@ai...> - 2011-01-19 23:52:11
|
On 20/01/11 01:01, Rich Mattes wrote: > If you want your robots to publish data that doesn't fit into one of the > existing interfaces, you can do one of two things. First, you can use > Player's "opaque" interface. The opaque interface allows you to transfer > any arbitrary data through the Player message-passing framework. As long as > the sender and receiver both know what the data is (for instance, it could > be a my_custom_data_struct_t that you define), they'll be able to > encode/decode the data successfully. See > examples/drivers/opaquedriver/opaquedriver.cc for a sample implementation. > You can create your own new interface, and define the different command, > request, and data messages and structs. See > libplayerinterface/interfaces/ADDING_INTERFACES for details, and the *.def > files in the interfaces folder for examples. > > If you prefer not to write a client, you can use something like the > "blackboard" interface. Each robot's driver can subscribe to the blackboard > driver, and post its own information there. They can also read information > that other robots post there. It seems to still be a well-guarded secret, but the best way to send custom data in Player is actually not the opaque interface any more. You can create a plugin interface for the data you want to send. There's not as much documentation about this as there should be. There is an example in share/player/examples/plugins/exampleinterface under the location where you installed player *to* (not from), and the wiki has a very brief explanation of how to compile plugin interfaces here: http://playerstage.sourceforge.net/wiki/Compiling_Player_3_clients_and_plugins#Compiling_plugin_interfaces Using this, you can create the messages you need and then use them like any other Player interface. It's a little more work than using the opaque interface, but it's significantly more reliable. Geoff |
From: Richard V. <va...@sf...> - 2011-01-20 05:51:02
|
A general purpose alternative that my group uses is Redis. It has many useful data structures for messaging between clients and it's very fast indeed. Google Redis and get started in a few minutes. - rtv On Wed, Jan 19, 2011 at 3:52 PM, Geoffrey Biggs <geo...@ai...> wrote: > On 20/01/11 01:01, Rich Mattes wrote: >> If you want your robots to publish data that doesn't fit into one of the >> existing interfaces, you can do one of two things. First, you can use >> Player's "opaque" interface. The opaque interface allows you to transfer >> any arbitrary data through the Player message-passing framework. As long as >> the sender and receiver both know what the data is (for instance, it could >> be a my_custom_data_struct_t that you define), they'll be able to >> encode/decode the data successfully. See >> examples/drivers/opaquedriver/opaquedriver.cc for a sample implementation. >> You can create your own new interface, and define the different command, >> request, and data messages and structs. See >> libplayerinterface/interfaces/ADDING_INTERFACES for details, and the *.def >> files in the interfaces folder for examples. >> >> If you prefer not to write a client, you can use something like the >> "blackboard" interface. Each robot's driver can subscribe to the blackboard >> driver, and post its own information there. They can also read information >> that other robots post there. > > It seems to still be a well-guarded secret, but the best way to send > custom data in Player is actually not the opaque interface any more. You > can create a plugin interface for the data you want to send. There's not > as much documentation about this as there should be. There is an example > in share/player/examples/plugins/exampleinterface under the location > where you installed player *to* (not from), and the wiki has a very > brief explanation of how to compile plugin interfaces here: > > http://playerstage.sourceforge.net/wiki/Compiling_Player_3_clients_and_plugins#Compiling_plugin_interfaces > > Using this, you can create the messages you need and then use them like > any other Player interface. It's a little more work than using the > opaque interface, but it's significantly more reliable. > > Geoff > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > |
From: Rich M. <jp...@gm...> - 2011-01-31 02:37:30
|
On 01/19/2011 06:52 PM, Geoffrey Biggs wrote: > On 20/01/11 01:01, Rich Mattes wrote: >> If you want your robots to publish data that doesn't fit into one of the >> existing interfaces, you can do one of two things. First, you can use >> Player's "opaque" interface. The opaque interface allows you to transfer >> any arbitrary data through the Player message-passing framework. As long as >> the sender and receiver both know what the data is (for instance, it could >> be a my_custom_data_struct_t that you define), they'll be able to >> encode/decode the data successfully. See >> examples/drivers/opaquedriver/opaquedriver.cc for a sample implementation. >> You can create your own new interface, and define the different command, >> request, and data messages and structs. See >> libplayerinterface/interfaces/ADDING_INTERFACES for details, and the *.def >> files in the interfaces folder for examples. >> >> If you prefer not to write a client, you can use something like the >> "blackboard" interface. Each robot's driver can subscribe to the blackboard >> driver, and post its own information there. They can also read information >> that other robots post there. > It seems to still be a well-guarded secret, but the best way to send > custom data in Player is actually not the opaque interface any more. You > can create a plugin interface for the data you want to send. There's not > as much documentation about this as there should be. There is an example > in share/player/examples/plugins/exampleinterface under the location > where you installed player *to* (not from), and the wiki has a very > brief explanation of how to compile plugin interfaces here: > > http://playerstage.sourceforge.net/wiki/Compiling_Player_3_clients_and_plugins#Compiling_plugin_interfaces > > Using this, you can create the messages you need and then use them like > any other Player interface. It's a little more work than using the > opaque interface, but it's significantly more reliable. > > Geoff > > Related to this, I've written up a wiki tutorial on how to build a plugin interface[1] based on the examples provided in the Player source. Please feel free to add to, edit, and correct it. Rich [1] http://playerstage.sourceforge.net/wiki/Writing_a_Player_interface |
From: pablis <pau...@ho...> - 2011-01-27 12:00:54
|
Hi Rich, Thanks for the info. I'll go with the opaque driver for now I think. In answer to your question, here's what I'm trying to achieve: Three small mobile robots (with room to add more). Each robot runs a Player server, which communicates with that particular robots position and laser (via the appropriate Player proxies). On top of this I have my C++ algorithm running in the background (on each robot) which can communicate with its local Player server. An algorithm running on any one robot communicates with the algorithm of other robots over wireless TCP (hence my initial problem). The algorithm can then act on the information received. This info is a bunch of pre-defined commands which my algorithm will act on upon receiving them. Some of these messages request laser and position information. However, I will now access this particular information (laser and position) directly via the Player proxies (without the need to do so via my own command system). The only non Player communication are those specific to my algorithm. If I understand correctly, this can be done using the opaque driver. Thanks again, Paul Rich Mattes-2 wrote: > >> Hi Rich, >> >> Thanks for the reply. Unfortunately the class-level "client" data >> member is >> private, and moreover it points to a bunch of playertcp_conn objects >> (maybe >> the playertcp_conn object gives access to the QueuePointer >> instantiation; >> but even if it did, I can't get at them due to the private construct) >> >> In answer to your question, I'm basically trying to communicate data >> between >> robots. I want to be able to send my own commands and transmit my own >> data. >> I thought the PlayerTCP class was the way to do this? Are you saying I >> can >> transfer my own commands between robots over the player ports? I'll >> look >> into this now, but whilst I'm here, I'll ask: how? >> >> Thanks again, >> Paul >> > > Player is designed to be able to transfer commands and data between robots > and clients, there's no need to hack with the internal libraries to > accomplish this. Depending on what your topology is, what kind of data > you > want to transfer, etc., there are several ways to go about what you want > to > do. > > The easiest way to coordinate multiple robots is to write a client program > using one of the client libraries (C, C++, python, ruby) that will > subscribe > to a Player server running on each robot. This client can be run on one > of > your robots, or on a separate computer. The client program can listen for > data coming from both robots, and issue commands to both robots. There > are > lots of samples in examples/{libplayerc,libplayerc++,python,ruby}, and all > of the utilities like playerprint, playerjoy, and playercam make use the > client libraries > > If you want your robots to publish data that doesn't fit into one of the > existing interfaces, you can do one of two things. First, you can use > Player's "opaque" interface. The opaque interface allows you to transfer > any arbitrary data through the Player message-passing framework. As long > as > the sender and receiver both know what the data is (for instance, it could > be a my_custom_data_struct_t that you define), they'll be able to > encode/decode the data successfully. See > examples/drivers/opaquedriver/opaquedriver.cc for a sample implementation. > You can create your own new interface, and define the different command, > request, and data messages and structs. See > libplayerinterface/interfaces/ADDING_INTERFACES for details, and the *.def > files in the interfaces folder for examples. > > If you prefer not to write a client, you can use something like the > "blackboard" interface. Each robot's driver can subscribe to the > blackboard > driver, and post its own information there. They can also read > information > that other robots post there. > > If you can be more specific about what you're doing (which robots & > drivers > you're using, what you want the robots to do, what data you want to pass > back and forth, etc.) we'll probably be able to give you better guidance. > > Rich > > > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > > -- View this message in context: http://old.nabble.com/PlayerTCP-tp30700376p30776634.html Sent from the playerstage-users mailing list archive at Nabble.com. |