locked
Scripting for end users of my MDRS application? RRS feed

  • Question

  • Hi,
    I want to develop a MDRS application so that end users of it can write simple algorithms to create or modify different navigation techniques.
    The typical end user would be a roboticist with basic skills in programming (if-then-else statements, for-loops, while-loops, functions, arrays).
    But they wouldn't be capable of dealing with the complexity of the CCR and DSS stuff (messages, notifications, handlers, etc)
    Is it possible to make a simple scripting system available for these users? I think game developers use this technique to make simple modifications to the games without having to recompile.
    My idea is that an orchestrator service calls (at each tick of a timer, or at each sensor notification) a simple script (written by the end user in some scripting language).
    But I don't know if this schema can be compatible with the CCR architecture.
    The script should be edited as a simple txt in Notepad, or ideally in a simple IDE that allows the user some debugging capabilities (watching variables, setting breakpoints, step by step execution, etc).

    Do you think this approach can work? Any ideas, suggestions?


    Thanks in advance

    Gonzalo

    Thursday, July 10, 2008 3:03 PM

Answers

  • Hi Gonzalo,

     

    Interesting suggestion. You might be aware that VBScript can be used to create custom programming environments. However, there are some interesting technical issues. Erik mentioned multi-tasking.

     

    Perhaps a better approach is to try to wrap up a lot of the CCR/DSS functionality to provide a simplified environment. For instance, many people expect to be able to call a DriveDistance method and have the program wait until it completes. As you know, this type of operation is not synchronous. So the wrapper needs to hide the details from the user and effectively make it appear synchronous. 

     

    Erik's suggestion is also a good idea for beginners. However, people who have had some exposure to programming might prefer to use a more conventional programming language. I think that handling arrays is a lot easier in a normal language for example.

     

    Trevor

     

    Friday, July 11, 2008 8:13 PM

All replies

  •  

    Hi Gonzalo,

     

    Check out the VPL, this is where the Visual Programming Language is for! Users can drag & drop items.

     

    You could make seperate activities in the VPL, one for the "game logic", and one for the user to modify, with simple steps. The debugging is also in there. Remember, the VPL uses the same approach as some LEGO software, which is used by kids, so it isn't that hard to use it.

     

    Writing your own script would make it difficult, and how to handle the multithreaded behaviour?

     

    Erik

    Friday, July 11, 2008 6:56 AM
  • Hi Gonzalo,

     

    Interesting suggestion. You might be aware that VBScript can be used to create custom programming environments. However, there are some interesting technical issues. Erik mentioned multi-tasking.

     

    Perhaps a better approach is to try to wrap up a lot of the CCR/DSS functionality to provide a simplified environment. For instance, many people expect to be able to call a DriveDistance method and have the program wait until it completes. As you know, this type of operation is not synchronous. So the wrapper needs to hide the details from the user and effectively make it appear synchronous. 

     

    Erik's suggestion is also a good idea for beginners. However, people who have had some exposure to programming might prefer to use a more conventional programming language. I think that handling arrays is a lot easier in a normal language for example.

     

    Trevor

     

    Friday, July 11, 2008 8:13 PM
  • Hi Gonzalo,

     

    This just sparked a thought.  I believe there is an old language calle "Turtle" or something like that.  It was a primative language for elementry school kids where you gave a list of instructions like "straight, straight, left, straight, ..." and when you "ran" it, a showed a screen with a little turtle that executed the moves.

     

    maybe you could write a service that is a "Turtle Interpretor" that would take any program written in Turtle and connect to generic drives to drive any robot.

     

    Somtimes I get off on wild tangents.

     

    Dogulas

    Friday, July 18, 2008 9:03 PM
  • Yeah there was a thing called "Turtle Graphics" in a language called Logo. You could move the turtle around, and also use Pen Up and Pen Down commands. This allowed you to draw pictures by issuing instructions to the turtle (which from memory was just a simple triangle on the screen).

     

    The Myro environment, which is based on Python, also exectutes commands "immediately". Have a look at http://www.ipre.org. The environment supports a couple of different types of robots, but it is not based on MSRDS (yet).

     

    The idea has some merit. Maybe when I have some spare time ... :-)

     

    Trevor

     

     

     

    Saturday, July 19, 2008 1:32 AM
  • Thank you for your replies.

    I think my idea could be implemented by embedding IronPython as a scripting engine in my orchestration service. This service (the hosting application) could make its own objects available to the IronPython engine, allowing users to write scripts in IronPython that can access to sensor data and set values for the actuators.

    Do you think this technique is feasible?

     

    Gonzalo.

     

     

    Saturday, July 19, 2008 2:49 PM
  • I don't know what is involved in embedding IronPython in an application. However, that being said, I don't see any reason why you could not write a service that connected to, say, a differential drive and exposed it to the user so that you could have commands like DriveDistance and RotateDegrees.

     

    If you make progress on this, please post a note to this forum.

     

    Trevor

     

     

    Sunday, July 20, 2008 4:18 AM