Compiler Design - ab3nd/TinyRobo GitHub Wiki

Compiler vs. Planner

The compiler has some aspects of a planner, in that it has to decompose the user task into a set of primitives that execute on the robot.

However, it can't be a full-on planner, because in the ideal case (limited communications, send program and let it go) the plan will rapidly become obsolete. It has to plan the actions the robot will need to take and the conditions to take them under, rather than just a list of actions to undertake

Input

A sequence of identified user gestures

Output

A robot program consisting of a list of (guard, rate, action) tuples. Actions are primitive behaviors, there's a page in the wiki on those. Guards are booleans on world state, so the sensors will possibly have to have a fixed set of world states that can be understood (rather than e.g. the very many values a floating point sensor reading could detect).

Some Notes on how the program is structured

Assuming the program consists of a grammar that can be viewed as having phases, the phases are essentially states of a state diagram, with detection of certain events causing state transitions.

This is expressed in GCPR as state flags, which are part of the guards on primitive behaviors.

For a task consisting of moving an object to a destination, wandering to find the object, finding the object, pushing the object, and stopping are all state transitions, and the states are the object not being found, the object being found, and the goal being found.

As a side note, if a single robot can push the object, it's possible to push the object to the goal by pushing it in any direction unless it's in the goal, in which case you don't push it at all. I'm not sure if this is closer to Poincaré's Recurrence Theorem or Nietzsche's. It also makes the assumption that the object can't e.g. get trapped in a state where it cannot be pushed in any direction (right triangular object in a square corner, for instance).

https://github.com/ab3nd/TinyRobo/wiki/Primitive-behaviors talks more about how to do the commands, this page is more concerned about figuring out the sections that the program is laid out in.

• Input is a task-level description, like moving the block to area A.
• Next step is to generate a sequence of actions that move the block to area A (this sounds like a planner, but I have little idea how to do planning). This also includes which robots do the actions, aka task allocation.
• Sequence of actions is translated into set of GCPR sequences (this sounds pretty straightforward).