locked
Implementing a delay for simulated teleoperations RRS feed

  • Question

  • I was curious if someone could recommend a process for implementing a delay between all communications to and from a robot.  This is to demonstrate interplanetary teleoperations and the difficulties associated with it. 

    For instance a drive command would be initiated by the user and say 5 seconds later the robot would actually start moving. The same would be true for the reverse direction.  A contact switch is activated but again 5 seconds later you get the indication on the user interface.  Most of the material I've found warns that using timers will block threads. Is there a way to delay messages without blocking yet still have a queue of commands and responses? 

    Thanks,
    PV

    Wednesday, May 13, 2009 10:38 PM

Answers

  • If you use a 'yield' that wait a message on a timeout port, it will not block any thread. But you should take care if you are executing a handler on an interleave in exclusive mode, you will block other handlers on this interleave.
    You should be able to do what you want by writing your own simulation services, have concurrent handlers on the main interleave that just wait with a 'yield' an amount of time and just forward the message to classic handlers (that could be exclusive, concurrent or teardown).

    Regards,
    Vincent
    http://www.simplysim.net/
    Thursday, May 14, 2009 6:36 AM

All replies

  • If you use a 'yield' that wait a message on a timeout port, it will not block any thread. But you should take care if you are executing a handler on an interleave in exclusive mode, you will block other handlers on this interleave.
    You should be able to do what you want by writing your own simulation services, have concurrent handlers on the main interleave that just wait with a 'yield' an amount of time and just forward the message to classic handlers (that could be exclusive, concurrent or teardown).

    Regards,
    Vincent
    http://www.simplysim.net/
    Thursday, May 14, 2009 6:36 AM
  • Thanks I'll try that.
    Thursday, May 14, 2009 2:12 PM
  • Perhaps you could impliment a new service (DelaySvc ?) whose only job is to take a message, hold it in a queue, and then re-post it after a delay.

    The benefit of doing this is that you could use this new service to simulate other factors in a communications link as well. For example the dleay could be variable, you could randomly drop messages (as happens in real life when there is noise etc.).

    At the risk of being slightly off topic, are you familiar with NASA's Disruption-Tolerant Networking (DTN) to meet the needs of space communication? You might like to look at: http://www.itwire.com/content/view/21781/1154/

    Thursday, May 14, 2009 3:18 PM
  • John,

    That was my original thought because I wanted to be able to demonstrate real-time command/control behavior and easily switch to delayed behavior without alot of reconfiguring or creating two services one with the timers and one without.  However, with my limited understanding of RDS I couldn't see a way to implement any solution without multiple timers. Until Vincent's response above I thought multiple timers were a big no-no. So now I'm reconsidering the single "delay" service idea again.  Hopefully this weekend I'll get a chance to sketch out some ideas on implementation.

    I had not considered the dropped message scenario but like the idea.  Also I had not heard of DTN but will certainly look into it.  

    Thanks for your help.

    PV
    • Edited by PVSyemya Friday, May 15, 2009 9:08 PM
    Friday, May 15, 2009 3:10 AM
  • This was the idea that I've had but never got around to working on (a separeate service).  If you complete it and are willing to post it, I would be very interested.  My original idea (that I cannot find the time to finish) was to build a Mars rover for astronomy outreach.  Immediate feedback to get the kids interested.  1.5 second delay for 'lunar' work and then 20 minute (while giving a slide show) to show control of the robot on Mars.  I've got the robot built, I just cannot find the time (and energy after programming all day) to finish it by adding this delay service and the 'scripting' service that I originaly had in mind.

    I wish you luck,
    Ed
    Friday, May 15, 2009 3:33 PM