Re: Controller Plugin

[Rosen Diankov-2]

Hi Stephan,

As long as you fill the ::SetDesired and ::SetPath methods, then you should be good to go. I usually create a concurrent thread that keeps on pinging the tcp for feedback and sets some type of local variable with the robot's joint values and positon. Then when ControllerBase::SimulationStep is called, I lock a mutex and set the robot values.

It is also possible to lock physics and set the robot values diretcly from your concurrent thread. But if you do that, it means you have to start locking physics everytime you have a planner and want to preserve the robot state. Note that OpenRAVE always has physics locked when it calls the various SimulationStep functions.

A simple example of a player controller can be found in plugins/playerrave/simpeplayercontroller.cpp.

I'm attaching a simple TCP/IP controller I developed a long time ago, hopefully this will help get you started.

rosen,

2008/10/15 Stefan Ulbrich <[hidden email]>

Hello Rosen,

I have got another question this time regarding the controller plugins: I want to create a plugin that interacts with our real robot controller (www.mca2.org) via a tcp connection.

What does a controller plugin controlling real hardware to fulfill? I thought of creating a concurrent thread that permanently awaits messages from the real
controller meanwhile updates the _probot model while having the physics locked.
Could you please suggest briefly what else I have to take care of?

Thank you very much!

Best regards,

Stefan

[Rosen Diankov-2]

just update with the most recent values

2008/10/15 Stefan Ulbrich <[hidden email]>

Thank you  for the quick answer!

As long as you fill the ::SetDesired and ::SetPath methods, then you should be good to go. I usually create a concurrent thread that keeps on pinging the tcp for feedback and sets some type of local variable with the robot's joint values and positon. Then when ControllerBase::SimulationStep is called, I lock a mutex and set the robot values.

do you store the values together with time stamps of the tcp transmission in order to be able to provide the desired value at a given elapsed time? or is it usually sufficient to update just the actual state? 

It is also possible to lock physics and set the robot values diretcly from your concurrent thread. But if you do that, it means you have to start locking physics everytime you have a planner and want to preserve the robot state. Note that OpenRAVE always has physics locked when it calls the various SimulationStep functions.

okay.

A simple example of a player controller can be found in plugins/playerrave/simpeplayercontroller.cpp.

I'm attaching a simple TCP/IP controller I developed a long time ago, hopefully this will help get you started.

again, thank you very much,

Stefan

rosen,

2008/10/15 Stefan Ulbrich <[hidden email]>

Hello Rosen,

I have got another question this time regarding the controller plugins: I want to create a plugin that interacts with our real robot controller (www.mca2.org) via a tcp connection.

What does a controller plugin controlling real hardware to fulfill? I thought of creating a concurrent thread that permanently awaits messages from the real
controller meanwhile updates the _probot model while having the physics locked.
Could you please suggest briefly what else I have to take care of?

Thank you very much!

Best regards,

Stefan

<chaircontroller.tgz>

[Rosen Diankov-2]

i forgot to attach the controller server code you would be using to connect to the network ;0)

rosen,

2008/10/15 Rosen Diankov <[hidden email]>

just update with the most recent values

2008/10/15 Stefan Ulbrich <[hidden email]>

Thank you  for the quick answer!

As long as you fill the ::SetDesired and ::SetPath methods, then you should be good to go. I usually create a concurrent thread that keeps on pinging the tcp for feedback and sets some type of local variable with the robot's joint values and positon. Then when ControllerBase::SimulationStep is called, I lock a mutex and set the robot values.

do you store the values together with time stamps of the tcp transmission in order to be able to provide the desired value at a given elapsed time? or is it usually sufficient to update just the actual state? 

It is also possible to lock physics and set the robot values diretcly from your concurrent thread. But if you do that, it means you have to start locking physics everytime you have a planner and want to preserve the robot state. Note that OpenRAVE always has physics locked when it calls the various SimulationStep functions.

okay.

A simple example of a player controller can be found in plugins/playerrave/simpeplayercontroller.cpp.

I'm attaching a simple TCP/IP controller I developed a long time ago, hopefully this will help get you started.

again, thank you very much,

Stefan

rosen,

2008/10/15 Stefan Ulbrich <[hidden email]>

Hello Rosen,

I have got another question this time regarding the controller plugins: I want to create a plugin that interacts with our real robot controller (www.mca2.org) via a tcp connection.

What does a controller plugin controlling real hardware to fulfill? I thought of creating a concurrent thread that permanently awaits messages from the real
controller meanwhile updates the _probot model while having the physics locked.
Could you please suggest briefly what else I have to take care of?

Thank you very much!

Best regards,

Stefan

<chaircontroller.tgz>

[Seth Koterba-2]

Hey Rosen,
   When the xml reader parses an xml reader and path to a file, for
example an .wrl file, is read, where exactly does it look for that
file?  Currently we have been specifying the full path to the file or
specifying the path relative to the openrave/bin directory.  Is there
there an environment variable that can be set to tell the xml reader
where to look, or is it possible to set it up to assume a path relative
to the parent xml file?

Seth