From: Kratochvil, B. E. <kra...@ir...> - 2005-04-20 14:03:22
|
> I think "type" should be left as the current position or velocity > control mode, and that switching between global and local control = should > be done through a configuration request. If you don't do it this way, > you'll need to change some of the clients to support the different > types.=20 >Do you say this because of code like this: > >if(cmd.type =3D=3D 0) >{ > // velocity control... >} else { > // position control... >} Yes, that's the way I understood to implement things. In your case, = we'd just need a case statement for the additional options.=20 >One of the reasons I'm avoiding configuration requests, is you have to=20 >wait until the config request is recieved by the driver before you can=20 >start sending your commands-- it's slower to switch modes basically. = Is=20 >this not true? Ok. That makes sense. My question is though, how would you support = this from client libraries? Would you have seperate methods/functions = for choosing the type and then just set the position and velocity like = normal? That seems like it could work for me and not break things too = badly (or quite possibly at all). > I came up with the position2d interface as an attempted way to migrate > from the current position interface to a newer more standardized one. = I > figured it would help keep everything from breaking during the > transition.=20 >So we could tear out all the stuff in position2d that is "left over"=20 >from the position interface, and re-do it? =20 Well, position2d is currently only used by me (I think) and in its = current state. So, it could basically be stripped and redone as a = "clean" position interface and then everyone could migrate to it when = they do the next driver upgrade. I would whole heartedly help support = this and could help with the development on the C/C++ side of things = along with incorporating it into the different player utilites. Are you = interested in this route?=20 Best regards, Brad |