The TiLAR Action Creator is a user interface that will allow the creation and editing of actions for different robots of the TiLAR system. The actions will be saved as files that are read and used by the TiLAR “programming” interface (the interface used to assign actions to the wiimote, etc.) It is being developed in Qt.

<br>

TO DO: There is still a lot to do.

• Make sure that key frame editing is simple.
• Drag the robot to manipulate the joint positions.
• Investigate the use/feasibility of predictive display elements and constraints for dragging the robot model.
• Add shadows and fill in the robot model.
• UI improvements here and there.
• Discuss rewriting the TiLAR Action File format. There are several limitations on the way action data is being stored right now.

<br> See the Notes section for ideas that have been brought forth about the editing process.

<br> 7/7/2011

The code for the action creator has been nearly all rewritten, with a focus on the 3D model being the main method to manipulate the robot. This refactoring has resulted in several performance increases with the robot animation and GUI elements. Currently, you have the ability to select a joint from the 3D model, and the inverse kinematics backend is in place to allow for dragging the joints, but the two functions still need to be tied together. A fully-functioning, interactive timeline is being written to allow manipulation of the action and its key frames and sounds. It is designed similarly to most video editing timelines, which I feel is simple. We had a discussion with Jake Crandall from MASDAR about the interface. See the Notes section below for some of those thoughts.

TiLAR Action Creator as of early July 2011

1/21/2011

A lot of code refactoring has been done to improve the reliability and maintainability of the program. It now has tick marks on the timeline to indicate the position of keyframes, and you can use the spacebar to start/stop the animation. The 'M' key adds a new keyframe. Click the link below to see a video of the interface in action.

Action Creator Demo

11/18/2010

After a brief hiatus during the late summer and fall, Tim has been working on the action creator again. It is mostly functional at loading, displaying, and modifying the motions for Troy, but needs the save button hooked up. Like the original design, the joint positions are controlled by sliders, and there are ways to add and remove keyframes and sounds from the action. The coolest addition is a preview area, where a model of the robot displays the action. This visual feedback is crucial. Users have a timeline they can slide to see the robot at different times, or they can play the animation all at once. Troy is the only robot that can be used with the interface right now.

TiLAR Action Creator as of November 2010

5/27/2010

The initial interface design will be a series of sliders that control the angles of the robot's various joints. Specific robots can be loaded into the interface, their joints moved, and then those joint positions are saved as an action “keyframe”. A sequence of keyframes constitutes an action. Conceptual screen below: <br> <br>

Conceptual User Interface for TiLAR Action Creator

<br>

• Users like to have key frames to refine actions that have been recorded (from Jake's research)
• Motion capture has discontinuity when keyframes are modified (from Alan)
• Snap-to/predictive display/quickening for movement w/ the 3D interface
  • Ability to deform the path if needed
  • What is the right way to display the likely, constrained path of the arm when the human starts moving it?
• What is the appropriate order of animation?
  • Motion, then sound (Jake's research suggests this)
  • Sound, then motion
  • Does the type of sound (short, speech, etc.) affect it?
• Action + interaction context (roleplaying) may bind together the stages of animation and help with the development of motions
• Do autistic children like short actions? What duration is best?
• (From the programming side) How can we incorporate sabotage into the Troy framework?
• What is the level of editing granularity needed for good motions, i.e., should we snap everything to 50 millisecond increments, etc.?
  • Or, do we warn the user about “bad” key frames (where Troy won't be able to perform the movement in the time restraints) and give them the option to change the movement range and/or time?