Using A Scripting Language To Script Robot Behaviour

[Greg McKaskle]

My input would be to focus on the core libs. You can start with simple C/C++ code to sequence through core routines and test the initial autonomous.

Once you have that under your belt, you want a way to safely and quickly write alternative auto routines. If you don't want much flexibility, you simply make it data driven using XML or another text format, or even Excel or other spreadsheet. If you want to be able to loop and make decisions, these lack enough flexibility, so you pull in a safe high-level language.

If you don't get the core stuff done, you'll find yourself writing too much code in the scripting language, which will hurt the performance and will turn difficult since scripting languages typically run into issues doing low level stuff.

Greg McKaskle

[Tom Line]

Exactly.

In fact, if you want easily changed code, it's easy enough to read waypoints or other direction and distance data from a text file on execution of the code. Then changing behavior is as simple as modifying a text file of waypoints or something to that effect.

[JesseK]

The basic need for scripting in a large integrated system comes from the need to reload non-core files without having to reboot due to relatively long reboot times (even 30 seconds is too long in some cases). Configurations are typically done in xml or some othe proprietary format, whereas procedures are typically done with shell scripts. It also allows for an adhoc content management setup so that a single link points to the current script file to use when there are multiple options/versions available. Changing the link (manually or automatically via code) changes which script a procedure points to. The nifty thing about this is that it allows for bug fixes post-deployment, yet remember we're talking about large software systems here...systems that may run on the stock market, large multi-manned vehicles, satellites, etc.

An architecture for a robot is easily extracted from this setup, yet there must be a core process that runs and calls the scripts continuously. Race conditions must be accounted for, as well as file I/O issues such as stale handles to files that were deleted/replaced.

It seems trivial and easy, yet the reality is that scripting in such a way will cost more overhead that it's worth for most typical robots. You would need an engine to handle the scripting, file I/O, and robot control all at once. While I agree that a gaming engine is the closest neighbor to that requirement, a typical robot processor (particularly an isolated, remote autonomous robot) does not have the juice or power longevity to support it. FRC robots may have the processing power to handle it, but do not nearly have the necessity for it given all of the matured development tools.