• View
• Edit
• History
• Print

StartScript

Scripting System Start-Up and Configuration

October 23, 2014

Alternative name: Using 40 Year-Old Tools

A common problem in any Graph-based system is how does one initialize the system. This necessarily forces one to decide upon a description of system configurations.

// TODO: change example Take for example the simple setup of a mobile robot with three components; a local navigator (LN) responsible for reading distance sensors and avoiding obstacles while command the robot to move towards a goal, a mapping component responsible for building a representation of the world (Map), and a planner (A*) responsible for path planning. For this system to run, each component must be instantiated and communication between components must be facilitated.

There are several approaches. Player is run with a configuration file in which components are "drivers, with inputs, outputs, and parameters:

  driver (
	  name "artpotdriver"
	  plugin "libart_pot_driver"
	  requires ["localhost:6666:position2d:0"
	  	    "localhost:6666:laser:0"]
	  provides ["localhost:6666:position2d:1"]
	  vel_scale 1
	  dist_epsilon .1
	  goal_radius	0
  )

Composite and cFE also have their own, custom solutions. cFE's allows the user to set stack size and priority but does not make communication explicit:

  CFE_APP, /cf/hk_app.so,   HK_AppMain,  HK_APP,   50,  16384, 0x0, 0;
  CFE_APP, /cf/batt_app.so,   BATT_AppMain,  BATT_APP,   51,  16384, 0x0, 0;
  CFE_APP, /cf/eps_app.so,   EPS_AppMain,  EPS_APP,   51,  16384, 0x0, 0;

In moving my framework away from Player, I am not in a position where I need to come up with yet another init and config tool for a graph based system.

Flex and Bison

My first attempt at this problem was to write a custom tool in c. Then I started to write the parsing code, and became depressed. Writing text parsing code is a rather dull and tedious task. Fortunately I am not the first person to think so: over 40 years ago my exact problem was solved in the form of Lex and YACC. The "modern" embodiment of said tools are Flex and Bison.

My initial solution worked great for about three days, until I realized that my approach was too simplistic. So this is my second go of it.

First off, the format:

  comp filter := "(Filter)VoterC"
  comp local_nav := "(ArtPot)VoterC"
  Bench --> filter
  filter --> local_nav
  local_nav --> Bench

The first two lines describe two components, each of which is to be replicated using VoterC. These are name, and then communication is described in the next three lines. For example, filter sends messages to local_nav. Bench is a special component which acts as an interface to the simulator and also tracks timing for the entire loop. The communication model is still to simplistic; eventually types of messages and multiple in / out queues should be defined.

The first part, naming components, has the following format

TODO: Wow.. this is taking forever. Will finish eventually.

TODO: lex file, bison file, book link, example, conclusion.