Implementing plugin(s) for haptic robot control?

Support
1

Hello Mworks developers,

I’m considering Mworks to run an experiment that would use a haptic robot. For now I use my own program, but a lot of MWorks niceties would be nice to have ! In such a scenario, the robot handle position would control a cursor on the screen, and forces would be rendered by the robot.

Typically, the robot is controlled by a library with two simple commands, one to get the position of the robot handle, and one to tell the robot to apply a given force. In my current implementation, these are called in a busy loop that runs on a separate thread, and the update rate is 4KHz (which is the optimal and maximal refresh rate). The function which sets the force appears to be waiting which explains the fixed rate (if the time is missed, it will wait 250us more).

The forces are most of the time computed as a function of the position/speed of the robot handle. For example if you want to simulate a spring, you set the force vector to k.(p_handle-p_origin), or if you want to simulate viscosity, the force is -k.velocity. Currently I use a set of force “objects” (which state changes during a trial). You can imagine them as the equivalent of visual objects of a visual scene, but those are rendered haptically: the force to output is just the sum of the force vectors generated by each object.

Would the architecture of Mworks be suited for such an application ?
By discussing with mworks user in my lab, there were suggestions of writing plugins for the robot, for the force objects, and I guess also for a renderer. In that scenario, we would have:

  1. Robot plugin gathers the position

  2. Cursor (visual object) position is set from the robot position

  3. Force objects are informed of the robot position/speed

  4. Forces of the force objects are retrieved, summed

  5. The obtained force is send to the robot by the robot plugin.

  6. and 5) must be separated by less than 250us. It’s of course desirable that the force obtained is computed from the last position read, not the previous one or a mix of the two. Would such an update rate be possible ? How difficult would that be ?

Thanks for your input,

Pierre

2

Hi Pierre,

Thank you for your interest in MWorks!

I think the architecture suggested by your fellow lab member makes sense. You’d have an I/O device component representing the robot, a set of components representing the various force types (which would be queued/dequeued much like visual stimuli), and a visual stimulus component for rendering the cursor. Implementing all of that should be relatively straightforward.

As for the timing: MWorks doesn’t impose many restrictions on what plugins do, so you’d be free to spawn a separate thread for the robot I/O and force computation, much like you do now. If you’re able to achieve a 250us update rate in your current code, then the same should be possible within MWorks, assuming your system has enough CPU cycles to go around.

Out of curiosity, what is the interface between the robot and the computer? USB? Ethernet?

If you have more questions, please don’t hesitate to ask!

Cheers,
Chris Stawarz

3

Thank you for the answer.

I was asking the question about the timing because I looked at the implementation of the eyelink plugin from Philipp, which retrieves samples at regular times through the use of a function called by the MWorks Scheduler as far as I understood. Does your answer means that a different method is possible ?

The robot (Force Dimension Delta) interfaces through USB 2, which explains the 250us rate (USB frames).

Cheers,

Pierre

4

Hi Pierre,

I was asking the question about the timing because I looked at the implementation of the eyelink plugin from Philipp, which retrieves samples at regular times through the use of a function called by the MWorks Scheduler as far as I understood. Does your answer means that a different method is possible ?

The MWorks scheduler doesn’t do much other than spawn a thread and then invoke your callback function at the requested rate. You can make a scheduler thread busy loop (by requesting, say, a 1us repeat interval and instructing it to drop missed executions), but in that case you aren’t deriving much benefit from the scheduler infrastructure. For your application, I think you’d be better off spawning your own thread (which MWorks plugins are absolutely free to do).

Chris

5

Hi Chris,

I understand your point about the scheduler.

One other thing I’m wondering about is your comparison with visual stimuli. I see that a plugin can correspond to an IO device, to a stimulus, or some kind of filter. The stimulus class seems to be quite specific for visual stimuli, and the queuing/dequeuing is for graphical rendering. These basic functionalities seem to be part of MWorks core.

In my case, the force stimuli are quite different, and they probably would need a different queue (since the rendering is not graphical but haptic, and would be requested by the robot IO plugin). Would the implementation of a second “haptic” queue be possible only with plugins, without diving in the MWorks core ? As far as I’ve seen, most plugin objects seem to have simple fields (eye position, stimulus color…), but not associated actions. Ideally one would like the robot I/O plugin to have actions to queue/dequeue haptic stimuli. Would that be possible ?

Is there some documentation about plugin writing (I could ask people in the lab, but, I would like to start during the holidays !) ?

And last (this is more to satisfy my personal curiosity, and is out of the scope of the current problem), is there a plan to move MWorks to C++11 instead of boost now that a good part of the functionality used in MWorks is supported by Apple compilers ?

Pierre

6

I believe that the Apple USB stack won’t let you poll USB ports faster than every 1ms. This was true for Snow Leopard, at least in my experience. I could sometimes get round trips to a USB device at 0.6-0.8ms, but the time varied and would often be greater than 1ms. There didn’t seem to be any Mac OS X settings that would improve this.
It’s been a long time since I looked however, and I wouldn’t be shocked if I missed some setting.

7

The library provided by the robot constructor works at a higher level than that, through these get_position and set_force functions. I do not know how they get to these rates internally and how they handle the polling. They provide several USB settings: async, sync…but I do get what seems to be real 250us updating for every one of them.
The device is USB 2, so in theory there is a high speed mode with 8 microframes per millisecond.

8

Hi Pierre,

In my case, the force stimuli are quite different, and they probably would need a different queue (since the rendering is not graphical but haptic, and would be requested by the robot IO plugin). Would the implementation of a second “haptic” queue be possible only with plugins, without diving in the MWorks core ? As far as I’ve seen, most plugin objects seem to have simple fields (eye position, stimulus color…), but not associated actions. Ideally one would like the robot I/O plugin to have actions to queue/dequeue haptic stimuli. Would that be possible ?

Yes, what you describe is absolutely possible via plugins; in fact, this is exactly what I had in mind. Your plugin would need to implement three kinds of components:

  1. The robot I/O device, which does the real work and serves a role analogous to the stimulus display device.
  2. A set of components representing the different force types. These are analogous to visual stimulus components, but they’re really a whole new category of component and would therefore derive from the base Component class, rather than one of its existing subclasses.
  3. A set of actions for queuing/dequeuing forces and doing whatever other custom control you need. These would take the robot device and (potentially) a force component as parameters.

The visual stimulus infrastructure could have been implemented in much the same way. It’s part of the core more out of convenience and history than necessity.

Is there some documentation about plugin writing (I could ask people in the lab, but, I would like to start during the holidays !) ?

Unfortunately, no. I’m happy to answer any questions you have (although I’ll be out of the office 12/24-1/1). I can also create a “shell” plugin for you, with empty implementations of the various components you need; that would save you the trouble of figuring out much of the mechanics of component and plugin development, so you could focus on the actual working code. I don’t think I’ll have time for that this week, though.

And last (this is more to satisfy my personal curiosity, and is out of the scope of the current problem), is there a plan to move MWorks to C++11 instead of boost now that a good part of the functionality used in MWorks is supported by Apple compilers ?

Well, C++11 and boost aren’t mutually exclusive. I’d love to start using C++11 features in our code. I already laid the groundwork by making the switch from llvm-gcc to clang and ensuring that our code compiles against libc++, which supports the new standard. However, libc++ isn’t available on OS X 10.6 (Snow Leopard), so in order to make the switch, we’d have to bump our minimum supported OS version to 10.7 or 10.8. I’m planning to poll current MWorks users about the feasibility of such a bump.

However, even if we do start using C++11 features, it by no means follows that we would stop using boost. Boost is a great set of tools, and our code depends on it in a multitude of ways. Trying to excise it from our codebase would be extremely difficult and time consuming.

Are you specifically thinking of boost::shared_ptr vs std::shared_ptr? Replacing all usage of the former with the latter would probably be doable, but I don’t know what the benefit would be. In fact, my preference would be for MWorks’ code to keep using boost::shared_ptr, and for boost to make that an alias for std::shared_ptr when available. However, there may be differences between the two implementations that prevent that.

Chris

9

Hi Christopher,

Thank you very much for the answer and the proposition. I’m glad that the plugins can be this modular !

I ended up being unable to look at things during the holidays as well, but if the offer for a “shell” plugin still holds, I would gladly take you up on it. If so, should we switch to a different discussion channel to talk about the particulars if needed ?

The C++11 question was more curiosity-driven, but underlying it is the fact that I only have recent macs around, which only run with 10.8, and that I’ve noticed that MWorks is supposed to work best with 10.6.

10

Hi Pierre,

(It looks like your last reply was automatically flagged as spam for some reason. Sorry about that.)

I ended up being unable to look at things during the holidays as well, but if the offer for a “shell” plugin still holds, I would gladly take you up on it. If so, should we switch to a different discussion channel to talk about the particulars if needed ?

Sounds good. I’ll send you a private email shortly.

The C++11 question was more curiosity-driven, but underlying it is the fact that I only have recent macs around, which only run with 10.8, and that I’ve noticed that MWorks is supposed to work best with 10.6.

I see. You should be fine with 10.8. (I’ve been developing and testing under 10.8 since it was released, and I haven’t had any issues.)

Chris