From: Radu B. R. <ve...@in...> - 2005-05-12 11:07:22
|
Hellos, Some time ago, Fred Labrosse and after that, a few weeks ago, Matthew Johnson enquired the possibility of being able to turn their robots on spot by simply specifying the heading. From my understanding, only the following drivers have PIDs implemented: reb, kephera, clodbuster and obot (which according to obot.cc has a bad low-level PID motor controller implemented). Reed Hedges stated that he's already working on implementing it for the p2os. For all the other supported robots that do not have a low-level controller (PID-like) already implemented, wouldn't it be nice for us to support it via the player drivers? I'm also thinking Stage here. Is anyone else working on this? I was prepared to implement an abstract controller and then build P, PD, PI, PID and others on top of them for Javaclient, but I think it would save everyone some effort if we do it at the driver level. Am I smoking crack or is this a good idea? :) Cheers, Radu. -- | Radu Bogdan 'veedee' Rusu | http://www.rbrusu.com | Javaclient for P/S/G | http://java-player.sf.net | Robotics Research Group , Technical University of Cluj-Napoca[.ro] |
From: Matthew J. <mjo...@ih...> - 2005-05-12 13:20:26
|
Radu, I think this is a good idea. I think this low level control should not be lumped into the interface with the higher level stuff, particularly when it is clear that not all robots will support all the capabilities. I think it would be good to start a thread of discussion on ALL the player interfaces and how to clean them up or improve them. Matt -----Original Message----- From: pla...@li... [mailto:pla...@li...] On Behalf Of Radu Bogdan Rusu Sent: Thursday, May 12, 2005 6:08 AM To: pla...@li... Subject: [Playerstage-developers] Robots, Position and PIDs Hellos, Some time ago, Fred Labrosse and after that, a few weeks ago, Matthew Johnson enquired the possibility of being able to turn their robots on spot by simply specifying the heading. >From my understanding, only the following drivers have PIDs implemented: reb, kephera, clodbuster and obot (which according to obot.cc has a bad low-level PID motor controller implemented). Reed Hedges stated that he's already working on implementing it for the p2os. For all the other supported robots that do not have a low-level controller (PID-like) already implemented, wouldn't it be nice for us to support it via the player drivers? I'm also thinking Stage here. Is anyone else working on this? I was prepared to implement an abstract controller and then build P, PD, PI, PID and others on top of them for Javaclient, but I think it would save everyone some effort if we do it at the driver level. Am I smoking crack or is this a good idea? :) Cheers, Radu. -- | Radu Bogdan 'veedee' Rusu | http://www.rbrusu.com | Javaclient for P/S/G | http://java-player.sf.net | Robotics Research Group , Technical University of Cluj-Napoca[.ro] ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click _______________________________________________ Playerstage-developers mailing list Pla...@li... https://lists.sourceforge.net/lists/listinfo/playerstage-developers |
From: Brad K. <bkr...@et...> - 2005-05-12 13:35:19
|
Radu Bogdan Rusu wrote: >For all the other supported robots that do not have a low-level controller >(PID-like) already implemented, wouldn't it be nice for us to support it via >the player drivers? I'm also thinking Stage here. > >Is anyone else working on this? I was prepared to implement an abstract >controller and then build P, PD, PI, PID and others on top of them for >Javaclient, but I think it would save everyone some effort if we do it at >the driver level. > I already have a fairly full featured driver that does this for our Marvin robot, which could easily be extended. The source is all online at: http://www.iris.ethz.ch/research/marvin/files/. It may give you some ideas. Basically, I break the robot down into motors and low-level I/O. This is the place where the PID belongs. Then, on top of that I have the Marvin driver which just uses two motors. It should be able to support pretty much any differential drive robot that is made up of 2 motors. The low level control is based on our irisController class, which I haven't put the source online for yet. This is mainly because I haven't gone through and optimized this code. Using this framework, I've written control for 2 different low level I/O platforms we have here, and it can easily be extended to others. Let me know if you're interested in add/collaborating on this. Cheers, bk |
From: Radu B. R. <ve...@in...> - 2005-05-21 19:12:08
|
Hello Brad, ...and sorry for replying so late. I've been busy with some final university projects, and also had a lot of work to do on our ZeeRO robot, which proudly reached its v1.0 stable (hardware-wise :). After I started the discussion here, I went ahead and developed some basic controller classes for Javaclient (they are up on the CVS head at SF). Basically we support an abstract controller, and then upon that, I built some simple ones such as P,PI,PD and PID. Of course, this is not the desired solution (at least not for everyone), since Javacline is just *one* of the many existing clients for P/S/G. So, to make a long story short, I'd be happy to start collaborating with you or anyone else to implement the controllers at the player level. Right now, it might be safe to hold until 1.7 is over and the XDR is implemented, since Javaclient will suffer some changes too. Of course, we can discuss and put some ideas on paper until then. :) Cheers, Radu. On Thu, May 12, 2005 at 03:35:08PM +0200, Brad Kratochvil wrote: > Radu Bogdan Rusu wrote: > > >For all the other supported robots that do not have a low-level controller > >(PID-like) already implemented, wouldn't it be nice for us to support it > >via > >the player drivers? I'm also thinking Stage here. > > > >Is anyone else working on this? I was prepared to implement an abstract > >controller and then build P, PD, PI, PID and others on top of them for > >Javaclient, but I think it would save everyone some effort if we do it at > >the driver level. > > > I already have a fairly full featured driver that does this for our > Marvin robot, which could easily be extended. The source is all online > at: http://www.iris.ethz.ch/research/marvin/files/. It may give you > some ideas. > > Basically, I break the robot down into motors and low-level I/O. This > is the place where the PID belongs. Then, on top of that I have the > Marvin driver which just uses two motors. It should be able to support > pretty much any differential drive robot that is made up of 2 motors. > > The low level control is based on our irisController class, which I > haven't put the source online for yet. This is mainly because I haven't > gone through and optimized this code. Using this framework, I've > written control for 2 different low level I/O platforms we have here, > and it can easily be extended to others. > > Let me know if you're interested in add/collaborating on this. > > Cheers, > > bk > Yours sincerely, Radu Bogdan Rusu -- | Radu Bogdan 'veedee' Rusu | http://www.rbrusu.com | PhD student/teaching assistant | Robotics Research Group, Technical University of Cluj-Napoca[.ro] |
From: Brad K. <bkr...@et...> - 2005-05-23 12:03:53
|
Radu Bogdan Rusu wrote: >Of course, this is not the desired solution (at least not for everyone), >since Javacline is just *one* of the many existing clients for P/S/G. So, to >make a long story short, I'd be happy to start collaborating with you or >anyone else to implement the controllers at the player level. > >Right now, it might be safe to hold until 1.7 is over and the XDR is >implemented, since Javaclient will suffer some changes too. Of course, we >can discuss and put some ideas on paper until then. :) > > > It may be nice to build a fairly generic differential drive robot driver. Then people could write the low level motor interface for their particular hardware, but not have to worry about the higher level stuff for most robots. Would something like this be helpful to your project? If so, I've already got the basis for this done in our Marvin driver. What we'd need to do is figure out how best to generalize this, and what others would need. I'm working w/ some of the other devs on an interface overhaul. Is there anything that people would like to see changed/added/removed in the position interface (or any interfaces for that matter). Best regards, Brad |
From: Reed H. <re...@ac...> - 2005-05-12 16:11:20
|
Radu Bogdan Rusu wrote: > Hellos, > > Some time ago, Fred Labrosse and after that, a few weeks ago, Matthew > Johnson enquired the possibility of being able to turn their robots on spot > by simply specifying the heading. > > Is anyone else working on this? I was prepared to implement an abstract > controller and then build P, PD, PI, PID and others on top of them for > Javaclient, but I think it would save everyone some effort if we do it at > the driver level. We've been discussing this recently. I think it can be an optional component of the position driver. Not all robots offer position control natively, and we probably shouldn't force driver writers to implement that. We're still trying to decide what the interface should be. The REB driver has a configuration request to switch control modes, and then uses "xspeed" for translation distance, "yawspeed" for heading, etc. However, this has some limitations: you have to wait until the request has been processed, it overloads the "speed" fields in a confusing way, and there is no way to use velocity control for translation and heading control for heading. What I did tentatively for myself is to extend the command structure to have "xpos" , "ypos" and "yaw" fields, and have different modes signified by the mode field: mode=0 is velocity control, mode=1 is absolute position control, mode=2 is relative (delta) position control. Look in the mailing list archives for details, or I can send a patch to anyone who is interested. (My Stage patch is on sourceforge). This is not pretty at all in the implementation (I implemented it in Stage and also in the p2os driver to just send HEAD, MOVE, DHEAD commands, but haven't had a chance to test it). There has been some discussion about redesigning the position interface bit, along with some general architectural changes to Player. One change that Brian is about to move into CVS HEAD I think is to have multiple command types, so we can seperate the position and velocity control commands into seperate sructs/packets. I'd like to decouple position and heading control as well but we haven't discussed that at all really. I would also like to expand the SPEED config request to have maximum/minimum speeds, speeds to use for position control, and acceleration/deceleration values. Reed |
From: Toby C. <tco...@di...> - 2005-05-13 21:35:57
|
Hi, Just to mention this again, the soon to be merged (what is the current timeframe?) message-overhaul branch of player supports a subtype in the message header, this allows for a single 'interface' to support multiple data and command structures in a similar manner to how we previously supported multiple request/response structures. This could allow more flexibility in the interfaces (ie seperate structures for position and velocity control etc) as well as the potential for driver specific structures. Perhaps we need a capabilities request? so we can actively find out what an interface supports rather than simply detecting failure after the event... Toby Collett Reed Hedges wrote: > Radu Bogdan Rusu wrote: > >> Hellos, >> >> Some time ago, Fred Labrosse and after that, a few weeks ago, Matthew >> Johnson enquired the possibility of being able to turn their robots >> on spot >> by simply specifying the heading. >> >> Is anyone else working on this? I was prepared to implement an abstract >> controller and then build P, PD, PI, PID and others on top of them for >> Javaclient, but I think it would save everyone some effort if we do >> it at >> the driver level. > > > We've been discussing this recently. > > I think it can be an optional component of the position driver. Not > all robots offer position control natively, and we probably shouldn't > force driver writers to implement that. > > We're still trying to decide what the interface should be. The REB > driver has a configuration request to switch control modes, and then > uses "xspeed" for translation distance, "yawspeed" for heading, etc. > However, this has some limitations: you have to wait until the request > has been processed, it overloads the "speed" fields in a confusing > way, and there is no way to use velocity control for translation and > heading control for heading. What I did tentatively for myself is to > extend the command structure to have "xpos" , "ypos" and "yaw" fields, > and have different modes signified by the mode field: mode=0 is > velocity control, mode=1 is absolute position control, mode=2 is > relative (delta) position control. > > Look in the mailing list archives for details, or I can send a patch > to anyone who is interested. (My Stage patch is on sourceforge). > > This is not pretty at all in the implementation (I implemented it in > Stage and also in the p2os driver to just send HEAD, MOVE, DHEAD > commands, but haven't had a chance to test it). > > There has been some discussion about redesigning the position > interface bit, along with some general architectural changes to > Player. One change that Brian is about to move into CVS HEAD I think > is to have multiple command types, so we can seperate the position and > velocity control commands into seperate sructs/packets. > > I'd like to decouple position and heading control as well but we > haven't discussed that at all really. > > I would also like to expand the SPEED config request to have > maximum/minimum speeds, speeds to use for position control, and > acceleration/deceleration values. > > Reed > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > |
From: Reed H. <re...@ac...> - 2005-05-13 21:57:32
|
Toby Collett wrote: > Hi, > Just to mention this again, the soon to be merged (what is the current > timeframe?) message-overhaul branch of player supports a subtype in the > message header, this allows for a single 'interface' to support multiple > data and command structures in a similar manner to how we previously > supported multiple request/response structures. > This could allow more flexibility in the interfaces (ie seperate > structures for position and velocity control etc) as well as the > potential for driver specific structures. Yeah, I'm waiting on that before further development in this area... > Perhaps we need a capabilities request? so we can actively find out what > an interface supports rather than simply detecting failure after the > event... That's an idea, could be a standard configuration request that takes the message subtype and returns ACK or NACK. |
From: Toby C. <tco...@di...> - 2005-05-14 07:45:54
|
>> Perhaps we need a capabilities request? so we can actively find out what >> an interface supports rather than simply detecting failure after the >> event... > > > That's an idea, could be a standard configuration request that takes > the message subtype and returns ACK or NACK. > Yeah, basically what I was thinking. Toby |
From: Toby C. <tco...@di...> - 2005-05-15 19:30:43
|
Toby Collett wrote: >>>Perhaps we need a capabilities request? so we can actively find out what >>>an interface supports rather than simply detecting failure after the >>>event... >>> >>> >>That's an idea, could be a standard configuration request that takes >>the message subtype and returns ACK or NACK. >> >> >> >Yeah, basically what I was thinking. > > > Actually Ive been thinking some more, We should send an array of message types/subtypes that are supported when we send the subscription acknowledgement. This would be far simpler, clients that want to ignore it can, client libs can parse it and store it in the proxy so a simply GetCaps(TYPE,SUBTYPE) call could be used as a lookup... Toby |
From: Matthew J. <mjo...@ih...> - 2005-05-16 22:38:05
|
All, Would it not make more sense to make the interfaces different if they are not always supported? The idea of querying to find out what an interface can do seems backwards to me. I expect an interface to be able to do what is described in the interface definition. If this is not the case, would I need to ask ALL interfaces if they can do what I plan to ask them do before using them? If not, why make a special case for the position interface. Matt -----Original Message----- From: pla...@li... [mailto:pla...@li...] On Behalf Of Toby Collett Sent: Sunday, May 15, 2005 2:30 PM To: pla...@li... Subject: Re: [Playerstage-developers] Robots, Position and PIDs Toby Collett wrote: >>>Perhaps we need a capabilities request? so we can actively find out what >>>an interface supports rather than simply detecting failure after the >>>event... >>> >>> >>That's an idea, could be a standard configuration request that takes >>the message subtype and returns ACK or NACK. >> >> >> >Yeah, basically what I was thinking. > > > Actually Ive been thinking some more, We should send an array of message types/subtypes that are supported when we send the subscription acknowledgement. This would be far simpler, clients that want to ignore it can, client libs can parse it and store it in the proxy so a simply GetCaps(TYPE,SUBTYPE) call could be used as a lookup... Toby ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click _______________________________________________ Playerstage-developers mailing list Pla...@li... https://lists.sourceforge.net/lists/listinfo/playerstage-developers |
From: Geoffrey B. <g....@au...> - 2005-05-16 23:51:53
|
It's worth noting that querying a device's capabilities to see what it can do before you try and make it do it is a very common technique when interacting with highly variable computer hardware, especially multimedia hardware such as video cards and sound cards. Both the DirectX and the OpenGL systems provide methods for checking what video cards are available on the system and then what capabilities they have so that the most suitable drawing method can be used. I think it makes sense to provide a similar capability when dealing with robot hardware, as this is also variable. That way, rather than just knowing you have a laser scanner to play with (for example), you would know whether it supports certain features and so be able to choose the best algorithm for dealing with its data. Obviously there is going to be some fundamental functionality that would be necessary to even qualify as a device meeting a certain interface (eg, a laser device returns range data in some form). While the variability in robot hardware is nowhere near as wide as it is in video cards, I think it would be wise to provide this functionality for what variability there is and in case the variability increases in the future (which it is likely to do). If it is done right, such a query should only be necessary when the program starts. Geoff -- Robotics research group, University of Auckland http://www.ece.auckland.ac.nz/~gbig005/ Matthew Johnson wrote: > All, > > Would it not make more sense to make the interfaces different if they > are not always supported? The idea of querying to find out what an > interface can do seems backwards to me. I expect an interface to be > able to do what is described in the interface definition. If this is > not the case, would I need to ask ALL interfaces if they can do what I > plan to ask them do before using them? If not, why make a special case > for the position interface. > > Matt > > -----Original Message----- > From: pla...@li... > [mailto:pla...@li...] On Behalf Of > Toby Collett > Sent: Sunday, May 15, 2005 2:30 PM > To: pla...@li... > Subject: Re: [Playerstage-developers] Robots, Position and PIDs > > Toby Collett wrote: > > >>>>Perhaps we need a capabilities request? so we can actively find out > > what > >>>>an interface supports rather than simply detecting failure after the >>>>event... >>>> >>>> >>> >>>That's an idea, could be a standard configuration request that takes >>>the message subtype and returns ACK or NACK. >>> >>> >>> >> >>Yeah, basically what I was thinking. >> >> >> > > Actually Ive been thinking some more, We should send an array of message > types/subtypes that are supported when we send the subscription > acknowledgement. This would be far simpler, clients that want to ignore > it can, client libs can parse it and store it in the proxy so a simply > GetCaps(TYPE,SUBTYPE) call could be used as a lookup... > > Toby > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click > _______________________________________________ > Playerstage-developers mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-developers |
From: Toby C. <tco...@di...> - 2005-05-17 03:02:45
|
The player protocol already allows a device to not support some aspects of an interface (ie velocity or position control for the position interface), it simply sends a nack to any request it doesnt support. Adding capabilities checking simply allows an application to check ahead of time which can be more convienient. If every variaton in capabilities led to a new interface then we would effectively have one interface for every message or request that could be sent to a device, however the other extreme is to simply have a robot interface that supports every message and query it to see if it supports laser_geom, sonar_data etc which is also obviously flawed. Given the two extremes, the pragmatic approach is to group major categories into interfaces with minor variations in supported capabilities allowing for the sanity of developers. This is the approach that player takes at the moment. If we wished to make this more formal we could specify in the documentation which messages for a given interface are 'required' to be supported, such as range readings for laser devices. There is certainly good arguments toward seperating position control, velocity control and odometry readings into three seperate interfaces but given the generally linked nature of the three from a driver point of view it makes sense to have them linked. I'll reserve my judgement on that one. Toby Collett Matthew Johnson wrote: >All, > >Would it not make more sense to make the interfaces different if they >are not always supported? The idea of querying to find out what an >interface can do seems backwards to me. I expect an interface to be >able to do what is described in the interface definition. If this is >not the case, would I need to ask ALL interfaces if they can do what I >plan to ask them do before using them? If not, why make a special case >for the position interface. > >Matt > >-----Original Message----- >From: pla...@li... >[mailto:pla...@li...] On Behalf Of >Toby Collett >Sent: Sunday, May 15, 2005 2:30 PM >To: pla...@li... >Subject: Re: [Playerstage-developers] Robots, Position and PIDs > >Toby Collett wrote: > > > >>>>Perhaps we need a capabilities request? so we can actively find out >>>> >>>> >what > > >>>>an interface supports rather than simply detecting failure after the >>>>event... >>>> >>>> >>>> >>>> >>>That's an idea, could be a standard configuration request that takes >>>the message subtype and returns ACK or NACK. >>> >>> >>> >>> >>> >>Yeah, basically what I was thinking. >> >> >> >> >> >Actually Ive been thinking some more, We should send an array of message >types/subtypes that are supported when we send the subscription >acknowledgement. This would be far simpler, clients that want to ignore >it can, client libs can parse it and store it in the proxy so a simply >GetCaps(TYPE,SUBTYPE) call could be used as a lookup... > >Toby > > >------------------------------------------------------- >This SF.Net email is sponsored by Oracle Space Sweepstakes >Want to be the first software developer in space? >Enter now for the Oracle Space Sweepstakes! >http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click >_______________________________________________ >Playerstage-developers mailing list >Pla...@li... >https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > > >------------------------------------------------------- >This SF.Net email is sponsored by Oracle Space Sweepstakes >Want to be the first software developer in space? >Enter now for the Oracle Space Sweepstakes! >http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click >_______________________________________________ >Playerstage-developers mailing list >Pla...@li... >https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > > |
From: Radu B. R. <ve...@in...> - 2005-05-14 14:24:54
|
On Fri, May 13, 2005 at 05:57:24PM -0400, Reed Hedges wrote: > Toby Collett wrote: > >Hi, > >Just to mention this again, the soon to be merged (what is the current > >timeframe?) message-overhaul branch of player supports a subtype in the > >message header, this allows for a single 'interface' to support multiple > >data and command structures in a similar manner to how we previously > >supported multiple request/response structures. > >This could allow more flexibility in the interfaces (ie seperate > >structures for position and velocity control etc) as well as the > >potential for driver specific structures. > > Yeah, I'm waiting on that before further development in this area... Reed, have your patches been merged into the tree code? Yours sincerely, Radu Bogdan Rusu -- | Radu Bogdan 'veedee' Rusu | http://www.rbrusu.com | Javaclient for P/S/G | http://java-player.sf.net | Robotics Research Group , Technical University of Cluj-Napoca[.ro] |
From: Reed H. <re...@ac...> - 2005-05-16 12:28:07
|
Radu Bogdan Rusu wrote: > On Fri, May 13, 2005 at 05:57:24PM -0400, Reed Hedges wrote: > >>Toby Collett wrote: >>>Just to mention this again, the soon to be merged (what is the current >>>timeframe?) message-overhaul branch of player supports a subtype in the >>>message header, this allows for a single 'interface' to support multiple >>>data and command structures in a similar manner to how we previously >>>supported multiple request/response structures. >>Yeah, I'm waiting on that before further development in this area... > > > Reed, have your patches been merged into the tree code? No, not yet, and they probably won't be as they are. I'll rewrite them after some of these big changes are done. The interfaces will be completetly different, I presume, and it might be better to make drastic changes to the Position2D interface and leave Position a bit closer to the old interface for easier transition? Also my stage implementation of the absolute/relative position controls was somewhat flawed, I'll be posting a new patch for that to the SF tracker. But let me know if you want them anyway. Reed |
From: Radu B. R. <ve...@in...> - 2005-05-16 20:47:40
|
On Mon, May 16, 2005 at 08:27:52AM -0400, Reed Hedges wrote: > Radu Bogdan Rusu wrote: > >On Fri, May 13, 2005 at 05:57:24PM -0400, Reed Hedges wrote: > > > >>Toby Collett wrote: > > >>>Just to mention this again, the soon to be merged (what is the current > >>>timeframe?) message-overhaul branch of player supports a subtype in the > >>>message header, this allows for a single 'interface' to support multiple > >>>data and command structures in a similar manner to how we previously > >>>supported multiple request/response structures. > > >>Yeah, I'm waiting on that before further development in this area... > > > > > >Reed, have your patches been merged into the tree code? > > No, not yet, and they probably won't be as they are. > > I'll rewrite them after some of these big changes are done. The interfaces > will be completetly different, I presume, and it might be better to make > drastic changes to the Position2D interface and leave Position a bit closer > to the old interface for easier transition? > > Also my stage implementation of the absolute/relative position controls was > somewhat flawed, I'll be posting a new patch for that to the SF tracker. > > But let me know if you want them anyway. Sure thing. I'm trying to implement a couple of robust controllers with a colleague of mine, and the setHeading stuff is exactly what we need. It sucks using a P(ID) for heading at the higher level, especially since this can be done at the lower level. Do you patches include both p2os and Stage modifications? I'm still having trouble using PLAYER_POSITION_{POSITION,VELOCITY}_MODE_REQ in Stage :( As Brian said, we can still work and improve the 1.6.4, while the big architectural changes go to the new version (1.7 ?). > Reed Cheers, Radu. -- | Radu Bogdan 'veedee' Rusu | http://www.rbrusu.com | Javaclient for P/S/G | http://java-player.sf.net | Robotics Research Group , Technical University of Cluj-Napoca[.ro] |
From: Reed H. <re...@ac...> - 2005-05-17 02:04:34
|
Radu Bogdan Rusu wrote: >>But let me know if you want them anyway. > > > Sure thing. I'm trying to implement a couple of robust controllers with a > colleague of mine, and the setHeading stuff is exactly what we need. It > sucks using a P(ID) for heading at the higher level, especially since this > can be done at the lower level. > > Do you patches include both p2os and Stage modifications? I'm still having > trouble using PLAYER_POSITION_{POSITION,VELOCITY}_MODE_REQ in Stage :( Just Stage implementation, but the P2OS driver change should be almost trivial: just send a HEAD command for absolute heading, DHEAD for relative heading, and MOVE for relative translation. Of course, absolute translation is tricky with a non-omnidirectional robot, but the Stage code includes a method for doing it (turn to face the goal, drive to the goal, then perform any absolute heading control you need). My Stage patch sort of messes that up (absolute position control) though I think and I haven't tested it yet since I don't need it yet. I have no idea how robust my Stage controllers are, just trying different combinations to test I have worked out whatever bugs there were. The heading control is just a proportion, speed-limited. It doesn't check for overshoot, it assumes it's running frequently enough to catch the goal heading within 1 or 2 degrees accuracy. Do you have a more rigorous testing procedure I can try? Anyway, my changes to Stage will be posted soon on sourceforge (and distributed with the new ActivMedia simulator based on stage). Reed |
From: Brian G. <ge...@ai...> - 2005-05-14 21:30:24
|
Toby Collett wrote: > Perhaps we need a capabilities request? so we can actively find out what > an interface supports rather than simply detecting failure after the > event... Sounds like a good idea to me. Interestingly, this feature was requested about 2.5 years ago: http://sourceforge.net/tracker/index.php?func=detail&aid=660523&group_id=42445&atid=433167 brian. -- Brian P. Gerkey ge...@ai... Stanford AI Lab http://ai.stanford.edu/~gerkey |
From: Matthew J. <mjo...@ih...> - 2005-05-20 15:37:18
|
Has there been any thought toward getting feedback from requests? For example, I tell a robot to move to some position and then I get informed when it has reached its destination or has failed to reach its destination. Using the information obtained from the "read" part of Player, some of this functionality could be achieved, but I wonder if it would be beneficial to include this feedback explicitly without having to add state monitors. Matt |
From: Toby C. <tco...@di...> - 2005-05-20 20:25:30
|
The playerstage server in CVS now has the ability to send many types of data message, these need to be defined in the interface and also provided in the driver but the ability to do so it definately there. Exactly what messages are defined is really up to what people feel they need and are prepared to implement. Toby Collett Matthew Johnson wrote: >Has there been any thought toward getting feedback from requests? For >example, I tell a robot to move to some position and then I get informed >when it has reached its destination or has failed to reach its >destination. Using the information obtained from the "read" part of >Player, some of this functionality could be achieved, but I wonder if it >would be beneficial to include this feedback explicitly without having >to add state monitors. > >Matt > > > > >------------------------------------------------------- >This SF.Net email is sponsored by Oracle Space Sweepstakes >Want to be the first software developer in space? >Enter now for the Oracle Space Sweepstakes! >http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click >_______________________________________________ >Playerstage-developers mailing list >Pla...@li... >https://lists.sourceforge.net/lists/listinfo/playerstage-developers > > > |
From: Richard v. <va...@cs...> - 2005-05-12 16:47:46
|
On 12-May-05, at 4:07 AM, Radu Bogdan Rusu wrote: > > Hellos, > > Some time ago, Fred Labrosse and after that, a few weeks ago, Matthew > Johnson enquired the possibility of being able to turn their robots on > spot > by simply specifying the heading. > >> From my understanding, only the following drivers have PIDs >> implemented: > reb, kephera, clodbuster and obot (which according to obot.cc has a bad > low-level PID motor controller implemented). Reed Hedges stated that > he's > already working on implementing it for the p2os. > > For all the other supported robots that do not have a low-level > controller > (PID-like) already implemented, wouldn't it be nice for us to support > it via > the player drivers? I'm also thinking Stage here. Stage does this already. Put the position device into position-control-mode, and away you go. > Am I smoking crack or is this a good idea? :) It's a good idea. Crack should be employed for debugging only. Richard. |
From: Radu B. R. <ve...@in...> - 2005-05-12 21:36:57
|
On Thu, May 12, 2005 at 09:47:44AM -0700, Richard vaughan wrote: > > On 12-May-05, at 4:07 AM, Radu Bogdan Rusu wrote: > > > > >Hellos, > > > >Some time ago, Fred Labrosse and after that, a few weeks ago, Matthew > >Johnson enquired the possibility of being able to turn their robots on > >spot > >by simply specifying the heading. > > > >>From my understanding, only the following drivers have PIDs > >>implemented: > >reb, kephera, clodbuster and obot (which according to obot.cc has a bad > >low-level PID motor controller implemented). Reed Hedges stated that > >he's > >already working on implementing it for the p2os. > > > >For all the other supported robots that do not have a low-level > >controller > >(PID-like) already implemented, wouldn't it be nice for us to support > >it via > >the player drivers? I'm also thinking Stage here. > > Stage does this already. Put the position device into > position-control-mode, and away you go. On my current CVSed Stage it didn't :( (April 22). Player was giving me "warn: stg_position doesn't support config id 5 (player_interfaces.cc PositionConfig)" when issuing a "Configuration request: Change control mode." with mode=1. I just updated, but now Player won't start libstage :) Ohh, the horror :) PLAYERPATH: /usr/local/lib trying to load /usr/local/lib/libstage...success invoking player_driver_init()...failed error : failed to resolve player_driver_init: /usr/lib/libltdl.so.3: undefined symbol: player_driver_init error : failed to load plugin: libstage I need some ideas on this one. My brain just died. > >Am I smoking crack or is this a good idea? :) > > It's a good idea. Crack should be employed for debugging only. Haha :) Have to remember that one! ;) > Richard. > > Yours sincerely, Radu Bogdan Rusu -- | Radu Bogdan 'veedee' Rusu | http://www.rbrusu.com | Javaclient for P/S/G | http://java-player.sf.net | Robotics Research Group , Technical University of Cluj-Napoca[.ro] |
From: Brian G. <ge...@ai...> - 2005-05-12 22:59:28
|
Radu Bogdan Rusu wrote: > I just updated, but now Player won't start libstage :) Ohh, the horror :) > PLAYERPATH: /usr/local/lib > trying to load /usr/local/lib/libstage...success > invoking player_driver_init()...failed > error : failed to resolve player_driver_init: /usr/lib/libltdl.so.3: > undefined symbol: player_driver_init > > error : failed to load plugin: libstage Stage has been broken into two libs; there's still a libstage, but it's now the player-independent lib. Your .cfg file should instead reference the player-specific lib: plugin "libstageplugin" It will in turn load libstage. This also tripped me up, and is likely to get other users, too. Maybe libstage should get a new name, so that people won't accidentally load it, when they mean libstageplugin. Hmm, but that won't help if there's already a libstage installed; they'll just be using the old version of stage. Can't think of a nice fix for this. brian. -- Brian P. Gerkey ge...@ai... Stanford AI Lab http://ai.stanford.edu/~gerkey |
From: Radu B. R. <ve...@in...> - 2005-05-13 06:41:09
|
Okay, fixed. Thanks for that one Brian, must have missed it. Richard, Is this the configuration request type you were refering to? : #define PLAYER_POSITION_POSITION_MODE_REQ ((uint8_t)5) Latest player/stage still gives: warn: stg_position doesn't support config id 5 (player_interfaces.cc PositionConfig) PS. It's the same with PLAYER_POSITION_VELOCITY_MODE_REQ. Cheers, Radu. On Thu, May 12, 2005 at 03:59:18PM -0700, Brian Gerkey wrote: > Radu Bogdan Rusu wrote: > > >I just updated, but now Player won't start libstage :) Ohh, the horror :) > >PLAYERPATH: /usr/local/lib > >trying to load /usr/local/lib/libstage...success > >invoking player_driver_init()...failed > >error : failed to resolve player_driver_init: /usr/lib/libltdl.so.3: > >undefined symbol: player_driver_init > > > >error : failed to load plugin: libstage > > Stage has been broken into two libs; there's still a libstage, but it's > now the player-independent lib. Your .cfg file should instead reference > the player-specific lib: > plugin "libstageplugin" > It will in turn load libstage. > > This also tripped me up, and is likely to get other users, too. Maybe > libstage should get a new name, so that people won't accidentally load > it, when they mean libstageplugin. Hmm, but that won't help if there's > already a libstage installed; they'll just be using the old version of > stage. Can't think of a nice fix for this. > > brian. > > -- > Brian P. Gerkey ge...@ai... > Stanford AI Lab http://ai.stanford.edu/~gerkey > Yours sincerely, Radu Bogdan Rusu -- | Radu Bogdan 'veedee' Rusu | http://www.rbrusu.com | Javaclient for P/S/G | http://java-player.sf.net | Robotics Research Group , Technical University of Cluj-Napoca[.ro] |
From: Reed H. <re...@ac...> - 2005-05-13 13:49:20
|
Brian Gerkey wrote: > This also tripped me up, and is likely to get other users, too. Maybe > libstage should get a new name, so that people won't accidentally load > it, when they mean libstageplugin. Hmm, but that won't help if there's > already a libstage installed; they'll just be using the old version of > stage. Can't think of a nice fix for this. Just make sure it's in the change log (and summary News if Stage has that). We could also make the error messages a bit more helpful. "failed to resolve player_driver_init" can be translated into: "/usr/local/lib/libstage.so is not a valid Player plugin module (failed to resolve player_driver_init function.)", which is useful both for plugin developers and users. It looks like all the example configs in Stage have been updated to libstageplugin too. Reed Index: server/main.cc =================================================================== RCS file: /cvsroot/playerstage/code/player/server/main.cc,v retrieving revision 1.130 diff -r1.130 main.cc 923,925c1009,1012 < puts("failed"); < PLAYER_ERROR1("failed to resolve player_driver_init: %s\n", < lt_dlerror() ); --- > if(!quiet_startup) // continuation of previous unquiet message. > puts("failed"); > PLAYER_ERROR2("%s does is not a valid Player plugin (failed to resolve player_driver_init function; %s)\n", > fullpath, lt_dlerror() ); 932c1019,1020 < puts("failed"); --- > if(!quiet_startup) // continuation of previous unquiet message. > puts("failed"); |