15-494: Cognitive Robotics, Spring 2009
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 arm 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 Decision
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 arm while walking. This opened up the arm 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 arm 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 ScytheNodes. 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 arm 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.
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.
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 arm 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.
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.
Summary and Future WorkDespite what I was able to do with the Chiaras, there is a lot of for improvement and other work that could be done.
- Write code where the arm reaches around objects. This would take advantage of the shoulder the most because it requires the arm to be parallel to the ground in order to work.
- Add more complex motions to the arm's library such as drawing lines and shapes in space. The base code is written. All one needs is some time and a little bit of work to create a large repertoire of potential actions.
- With this code, one can start making interesting behaviors for the Chiara, such as chasing after a basketball.
- (In progress) Implement code using Rapidly-Expanding Random Trees (RRTs) to allow the Chiara to reach around obstacles. Note how in the diagram below, the extra ``shoulder'' joint of the arm is rotated upwards by ninety degrees allowing the Chiara to act like a second planar arm and be able to ``reach around'' obstacles like the green circle in order to interact with a point ``behind'' the obstacle from the Chiara's reference frame.
- Using the RFr arm as a second planar arm also has benefits where it could use its two arms and try to (awkwardly) pull an object towards itself and conversely, push the object away elegantly. This is one of the many things I wanted to work on but was not able to get to doing on time.
The shoulder joint rotated upwards by 90 degrees to allow the RFr arm to be used as a second (makeshift) planar arm.