Implementation Details

15-494: Cognitive Robotics, Spring 2009
Richard Ha

Class List

There are only two classes for this library:

The former is used for interacting with objects while it is at a standstill and the latter was made with the intention of letting the Chiara use the leg while walking for many purposes such as clearing obstacles or just touching objects but as of the time of writing, its feature list is still very minimal.

Issues/Resolutions and Important Design Decisions

5-Legged walk

The first important issue that came up was how the Chiara walked. Before, Tekkotsu did not have support for walking with less than 6 legs on the Chiara. This took only a day's amount of work to patch and resolve and resulted in the Chiaras' walk parameter files (the plists) to have an extra boolean entry labeled ``Usable'' that tells the XWalk engine to not use the specific leg while walking. This opened up the leg for other purposes.

As shown from the following two diagrams, now when the Chiara walks using my walk5.plist, it does not use the RFr leg anymore when walking. The numbers indicate the order in which the Chiara moves its legs when it starts its walking cycle.

To `Point *' or not to `Point *'

Another issue (and first design decision) that came up was how to let a Tekkotsu programmer interface with ScytheNode. Because the programmer usually initializes the entire state machine in the parent StateNode's overridden setup() function, one would expect the programmer to just pass a DualCoding::Point object around in the function calls to the ScytheNode but given that the leg is going to be used to interact with the environment, and also given that assuming that the environment will always stay static is a bad and limiting assumption, passing in a Point object that can never be changed without manually modifying the ScytheNode's internal DynamicMotionSequence is not very appealing. Thus, I made the addAction function accept only pointers to Point objects (Point *) rather than a Point object so that the programmer is able to change the destination later. More information about using the ScytheNode is available on the Examples page.

Lazy Evaluation

The ScytheNode takes on a lazy evaluation approach in constructing the DynamicMotionSequence. The justification for this is that because of the above reason where the programmer is expected to pass in pointers to Point objects that can be modified at any time until the ScytheNode is activated, it would be unwise to intialize the DynamicMotionSequence from incomplete or uninitialized data. Thus, an eager evaluation schema would not be ideal.

Infinite Actions

The original plan was to let the ScytheNodes accept action frequency values of -1 to indicate that the next action in the list was to be executed infinitely, but a couple of issues resulted. First, this conflicted with the lazy evaluation schema because the parent DynamicMotionSequenceNode did not have anything that resembled an internal loop, so it couldn't construct the loop upon activation. But it could not construct the DynamicMotionSequence with an eager evaluation schema either because there was no way it would be able to again, construct an internal loop that represented an infinitely repeating action without constructing an infinitely long DynamicMotionSequence. Also, even if such values existed, the ScytheNode should have some sort of way of determining that all other actions added after the infinitely repeating action are a waste of space and should actively reject them rather than collecting space. Because of these reasons, I decided to not accept negative action frequency values and rather, if a user wants an inifinitely long action, they should specify a separate ScytheNode that follows from the first whose sole purpose is to repeat one or more actions.

Using the RFr leg while walking simulataneously

As mentioned before, despite being able to walk on 5 legs, there needs to be a lot of work and fine-tuning that needs to be done in order to make the Chiara walk reliably, not lose balance, and not veer off to one side.

Signals

Inspired by the XWalkNode's feature of taking in a WalkRequest from a signal event and walking to a destination without issues of initialization that the ScytheNode had (and avoided with addAction), I realized that the ScytheNode had lots of potential with that regard too where a node in the state machine could just signal a ScytheNode to dynamically perform an action on the spot rather than a semi-predefined action through addAction. Unfortunately, there was not enough time for implementing this feature to the fullest potential of the ScytheNode outside of just accepting a single Point object (not a Point *) and poking it. This would be something I would want to work on in the future if given more time.