FALL 2015 MicroBiPed Preliminary Design Documentation

MISSION OBJECTIVE

Fall 2015 MicroBiPed (μBiPed) is inspired by the BiPed designed by Jonathan Dowdall of Project BiPed. The objective for this year’s project is to use the BiPed & μBiPed designs to prototype a toy robot that resembles a Velociraptor. To push the objective towards prototyping a toy requires a large emphasis on cost. Although the mission is yet to be determined, the μBiPed must be controlled and be able to communicate with the Arxterra™ Android application.

 

REQUIREMENTS & VERIFICATION

Level 1 – Program Requirements

  1. According to the CSULB Fall 2014 Academic Calendar, the μBiPed robot shall be tested by December 10, 2015; the date of the last day of 400 D.
    1. Verification: https://web.csulb.edu/depts/enrollment/registration/final_exam/fall_chart.html
  2. According to 2014-2015 ARXTERRA µBiPed’s parts list, the project shall cost no more than $400.00.
    1. Verification:
      http://arxterra.com/final-documentation-microbiped/
  3. To push the objective of the μBiPed towards the remote control toy industry, the lifetime & playtime shall be constrained to the mental development of a child 7-12 years old.
    1. Verification:
      https://www.cpsc.gov//PageFiles/113962/adg.pdf

Level 1 – Project Requirements

  1. In accordance with the project name, the μBiPed shall travel on 2 legs.
    1. Verification:
      https://en.wikipedia.org/wiki/Bipedalism#Bipedal_robots
  2. To be considered a miniaturized BiPed robot, the μBiPed shall range between 0.6 (120mm) ± 10% of Rofi’s dimensions according to the ratio of an MG92B μservo to Rofi’s servo.
    1. Verification:
      1. http://web.csulb.edu/~hill/ee400d/Project%20Folder/Robots%20and%20Drones/BiPed%20Robot/RoFi%20Project/ROFI%20CDR.pdf
      2. http://www.headsuphobby.com/Towerpro-14g-MG92B-Digital-Metal-Gear-High-Torque-SubMicro-Servo-A-537.htm
  3. In accordance with the obstacle course, the μBiPed shall walk up an incline that starts initially at 8° and then decreases to a 6° slope in relation to level ground.
    1. Verification:
      http://www.discountramps.com/wheelchair-ramp-length/a/B20/
  4. In accordance with the obstacle course, the μBiPed must walk over or on an object at about a 45° angle and a height of 2 cm.
    1. Verification:
      The μBiPed will walk over an object of about 2cm ± 1cm. The 1 cm is for margin of error. This will be measured by a ruler.
  5. In accordance with the obstacle course, the μBiPed shall walk on surfaces of varying friction coefficients:
    1. Carpet: 1.0 static [1] Verification:
      http://www.sciencedirect.com/science/article/pii/S187770581000367X
    2. Linoleum: 0.5 static [2] Verification:
      http://www.sciencedirect.com/science/article/pii/S187770581000367X
    3. Rubber: 1.0 static [3] Verification:
      http://www.sciencedirect.com/science/article/pii/S187770581000367X
  6. In accordance with customer specifications, the μBiPed shall communicate on Bluetooth -to an Android phone app.
    Verification:
    https://www.arxterra.com/final-documentation-microbiped/
  7. In accordance with customer specifications, the μBiPed shall have a payload that outputs a toy-like behavior.
    1. Verification:
      The current proposal for a payload is to use a cheap sensor that can react to certain changes in the environment.
  8. To follow toy safety regulations, the μBiPed shall comply with the federal toy safety standard, ASTM F963-11.
    Verification:
    http://www.cpsc.gov/en/Business–Manufacturing/Business-Education/Toy-Safety

For information on how these requirements will be verified, please see the Level 1 Requirements post.

Level 2 – System Requirements

  1. According to CSULB 2015 Fall Finals Schedule, all subsystems shall stay within the time phasing to complete project μBiPed (by the due date of 12/10/15) and thus meet Level 1, requirement 1.
    1. Verification:
      The current task in the project schedule is planning. Along with the remaining tasks, (manufacturing, software integration, testing, and project video) the schedule will determine the allotted time for each phase of the project.
  2. To have a realizable budget, the chassis shall be manufactured directly at CSULB and thus meet Level 1, requirement 2.
    1. Verification:
      3D printers and CNC machines are available at the behest of their respective departments.
  1. To create a toy built for the attention span of a child between the ages of 7-12 years old, the μBiPed shall last 7-15 minutes and meet Level 1 requirement 3.
    1. Verification:
      To incorporate the mission objective of building a toy, the 4 AA batteries must be able to maintain system operations regarding the loads of chassis and 6 servos.
  1. To facilitate all the algorithmic functions of a walking BiPed, the Arduino MICRO with an ATmega 32u4 Microcontroller will be used to meet Level 1, requirement 4.
    1. Verification:
      With the reduced amount of servos, the amount of PWM pins required are also reduced. Therefore the Arduino MICRO is the better choice in comparison to the Arduino UNO.
  1. To maintain balance (while retaining core features of a BiPed), installment of a head & tail will be incorporated to the chassis to adjust the center of balance and thus meet Level 1, requirement 4.
    1. Verification:
      The reduced freedom of movement also means less ways to balance while moving. To compensate, alternative appendages can be attached to maintain the center of balance while moving.
  1. To reduce the dimensions of the BiPed, the μBiPed shall use a two-servo to one-leg system to eliminate bulkiness and meet Level 1, requirement 5.
    1. Verification:
      The previous semesters utilized 6 servos per leg to increase the articulation, but increased the bulk, weight, and the height. A more mechanical approach will be used to control the legs to imitate a velociraptor model.
  1. For the μBiPed to detect and adapt to inclines, a gyroscope shall be used to preserve chassis balance and meet Level 1, requirements 6 & 7.
    1. Verification:
      Level 1, requirement 6 & 7 indicates that the BiPed shall move up and down inclines. To adapt to such scenarios, the μBiped must be able to keep the body balanced by adapting to its relative center of gravity.
  1. In regards to bluetooth communication with the Arxterra app, an IGT-3200 wireless adapter will be used to meet Level 1, requirement 9.
    1. Verification:
      To be controlled by an Android app, the machine must have a wireless adapter to enable wireless communication.
  1. To adapt to different friction coefficients due to varying surfaces, an interchangeable shoe system will be used should the course terrain be changed..Level 1, requirement 8.
    1. Verification:
      This requirement is for flexibility in case linoleum tiles and carpet are no longer the terrain.
  1. To produce a toy that complies with remote control safety regulations, the μBiped must be designed for the ages of 7-12 years old and thus meets Level 1, requirement 11.
    1. Verification:
      To create a remote controlled toy, the μBiPed must comply with US Consumer Product Safety Commission for age determination guidelines.
  2. The μBiPed must avoid walls at a distance of (TBD). Determined by the mission profile. The distance may be determined based off of the constraints of the parts used to determine distance, or the customer may indicate distance.
    1. Verification:
      Will have the μBiPed walk towards an object, i.e. a wall, and see if the μBiPed will stop or try and change path. The distance will be measured with a tape measure.

 

DESIGN INNOVATION
Paul Oo (Project Manager)

Balanced Walking

Due to previous BiPeds using higher amount of servos for better articulation, the project has shifted towards having large legs/feet and heavy/bulky design. This year’s μBiPed design will be pushed towards prototyping a toy (specifically TITRUS III). This objective shall be the reference for system and subsystem designs.

Step 1. Brainstorm

  • Finalized Balancing Attributes:
    • Type of Legs – Velociraptor (reverse joint)
    • Head – Purely payload (sensor)
    • Tail – Oppose head movement
    • Feet – Multipurpose (shoes)

Step 2. Lateral Thinking

  • Finalized Forced Relationship:
    • Rubberband – Head and tail in opposing directions
    • Top – Gyro detects chassis orientation

Step 3. Solution  

  • Design Conclusion

To produce a toy-like design, the listed attributes must remain simple. By considering the design innovations of TITRUS III, the μBiPed will base its attributes on the concept of minimalism. Furthermore, the addition of shoes (for different terrains) will give customers incentive to invest into the product’s future developments.

 

ELECTRONIC SYSTEM DESIGN

block d final

System Block Diagram:

This block diagram explains the system architecture of the μBiPed in regards to its connections. The μBiPed can be broken down into three main subsystems: inputs, outputs, and microcontroller. The inputs consists of an ultrasonic sensor (HC-SR04™), a gyroscope (TBD), and a bluetooth system (HC-06™). The outputs consists of 6 servo motors (MG92B). Finally, the microcontroller board consists of a battery and the Arduino Micro (ATmega 32u4).

Interface Definitions:

  1. Ultrasonic Sensor (HC-SR04TM) – LED EYES
    1. The ultrasonic sensor will connect to 4 pins on the microcontroller for 5V power, ground, triggering, and echoing. It will be used to detect obstacles in the way of the robot and prevent the µBiPed from hitting the object.
    2. The reason for using an ultrasonic sensor is to possibly add a transducer to the sensor. Addition of the transducer will reduce the ultrasonic frequencies to a level that humans can hear. This audible sound is a toy feature.
  2. Gyroscope (ITG-3200) – ORIENTATION
    1. The gyroscope will be attached to the SDA and SCL pins on the microcontroller. It will be used to detect the orientation of the µBiPed to allow the microcontroller to make balance-based corrections.
    2. The reason for using a gyroscope, rather than an accelerometer, is due to the multiples degrees of movement the legs will have to resemble a hip-based leg.
  3. Bluetooth Device (HC-06TM) – COMMUNICATION
    1. This Bluetooth device will be a slave to the microcontroller. It will be attached to the RX and TX pins of the microcontroller. The HC-06TM will be used to communicate to an Android phone and receive commands from the Arxterra™ application.
    2. The reason for using a bluetooth system is based on customer specifications.
  4. Microcontroller Board (Arduino Micro – ATmega 32u4) – Control
    1. The microprocessor must be cost efficient, small, and be able to use Dowdall’s code for the Arduino IDE.
      1. Requirements of the microprocessor:
        1. Dynamic memory or SRAM: 4.7 KB
        2. Flash memory: 14 KB
      2. Meeting these requirements are imperative for the μBiPed group because the variable initialization does not take up the most dynamic memory (only about 17% of the dynamic memory is used by the global variables). Map() function requires the most dynamic memory.

 

Fritzing Diagram
Michael Balagtas (Manufacturing)

fritzing

Trade off studies
Railly Mateo (Computer Systems)

 

Servo comparison

Servo Price  (1unit) Torque Speed Weight Dimensions
MG90S $4.35 4.8V = 1.8kg/cm6.0V = 2.2kg/cm 4.8V = 0.10sec/60deg6.0V = 0.08sec/60deg 13.4 g 22.8 x 12.2 x 28.5mm
MG92B $7.00 4.8V = 3.1kg/cm6.0V = 3.5kg/cm 4.8V = 0.15sec/60deg6.0V = 0.11sec/60deg 13.8 g 22.0 x 12.0 x 31.0mm
SG90 $4.31 4.8V = 1.0kg/cm 4.8V = 0.12sec/60deg 9.0 g 22.0 x 11.5 x 22.5mm

The above chart compares 3 possible servos to use for the µBiPed project. The chart compares torque, speed, weight, rotation, and price.

  1. Torque is important because if the servos do not have enough torque the µBiPed will not move.
    1. Heavier servos means larger batteries.
    2. Slower servos means larger batteries due to a larger operation time to complete the course.
  2. Speed and weight are important for the sizing of batteries.
  3. Rotation is needs to 180 degrees to complete the required range of motion.
  4. Pricing is a desired to lower the cost of the total budget.

After comparing the servos, the group decided on using MG92B for the purpose of having a higher torque rating.

  1. Although MG90S and SG90 have less weight and lower cost than MG90S, they don’t have as much torque to move the µBiPed.
  2. The MG92B is also a U.S. products and thus can be delivered much faster than other servos not listed in the chart.

 

Microcontroller comparison

Microcontroller PWM Digital I/O pins AnalogInputpins Input Volt. Dimension Flash & SRAM Price
Arduino MicroATmega32u4 6 6 7 – 12V 68.6 x 53.4 mm 32 kB & 2 kB $9.00
Arduino UnoATmega328 7 12 7-12V 48 x 18 mm 32 kB & 2.5 kB $25.00

The above chart compares 2 possible microcontrollers to use for the µBiPed project. The chart compares pins, input voltage, dimension, memory, and price.

  1. The amount of pins available for analog and digital I/O’s are important because of the amount of sensors and servos the microcontroller will be connected to.
    1. We will need to connect 6 servos to analog pins on the microcontroller.
    2. We will need to connect 2 PWM pins to the payload.
  2. Input Voltage is used for understanding the amount of voltage the batteries must supply.
  3. The dimensions are key to creating a transparent embedded system.
  4. Pricing is desired to lower the cost of the total budget.

After comparing the microcontrollers, the group decided on using the Arduino Micro for the purpose of having a smaller and most cost efficient microcontroller.

  1. Although MG90S and SG90 have less weight and lower cost than MG90S, they don’t have as much torque to move the µBiPed.
  2. The MG92B is also a U.S. products and thus can be delivered much faster than other servos not listed in the chart.

 

Payload comparison – LiDar vs Ultrasonic Sensor – HC

SENSOR Sain SmartHC-SR04 LIDAR-Litev2
POWER SUPPLY 5V 6V
WORKING CURRENT 15Ma 2Ma
DIMENSION 45mm x 20mm x 15mm 20mm x 48mm x 40mm
RESOLUTION 0.3 cm 1 cm
PRICE $10.00 $115.00 

The above chart compares 2 possible payloads to use for the µBiPed project. The chart compares power supply, working current, dimensions, resolution, and price.

  1. Determining the amount of power and current needed is important because the microcontroller has a limit of 5V output.
  2. The dimensions are key to creating a transparent embedded system.
  3. Resolution is also considered to determine which sensor can provide a better user interface performance.
  4. Pricing is desired to lower the cost of the total budget.

After comparing the two sensors, the group decided on using the Ultrasonic Sensor for the purpose of having a more cost efficient payload.

  1. Although Lidar-Lite has better resolution than the HC-SR04, the cost to purchase a single LIDAR overweights its positive trade-offs.

 

Rapid Prototyping

In order to test the µBiPed, the code from Dr. Dowdall will be uploaded onto an ATmega microcontroller but will be modified to control only six servos. The choice of six servos is to allow for the manipulation of one leg. The purpose is to experiment with leg motion. As the µBiPed is required to step over an object of a certain height, it is important to track the default motion of the leg. This means that if the default movement of the legs does not rise of the 2 cm height a modification to the code will have to be made in order to allow for the ability to walk over an object of 2 cm.

 

Interface Matrix
Brian Walton (Control & Image Processing)

pinout pinout 2 final

 

Task Assignments
Michael Balagtas (Manufacturing)

Michael Nico Balagtas

  1. Construct physical models of the μBiPed for fast prototyping and error analysis.
  2. Computer Aided Design(CAD)
    1. Mechanical- Use Solidworks or DesignSpark to draft preliminary designs for critical review.
    2. Electronic – Use EAGLE software to draft final PCB design for fabrication through a third party
  3. Acquire information on how to use CSULB CNC machines or 3D printers for either metal or plastic builds.
  4. Manufacture parts for final mechanical product using either metal or plastic materials.
  5. Assemble final product through soldering and occasional post processing.

 

Railey Mateo

  1. Will learn C++ programming language to code algorithms using the Arduino IDE.
  2. Will work with Controls division member to optimize servos and gyroscopes.
  3. Will browse through datasheets of equipment to locate the appropriate registers of the peripheral equipment.
  4. Learn how to use IGT-3200 Wireless adapter.
  5. Algorithms
    1. Modify frame capture code from Mr. Dowdall to accompany a new two servo design.
    2. Create state diagrams for the walking frames and the transitions from each frame to the next.
    3. Code complex algorithms to determine behavior of μBiPed when on or approaching inclined surfaces.
    4. Code algorithms to calibrate and read input from gyroscopes using I2C communications.
    5. Develop code to process incoming images from LiDar sensor to make μBiPed respond according to specifications.

 

Brian Walton

  1. Servos
    1. Conduct mechanical stress tests to specify the maximum torque allowed by servos.
    2. Conduct tests to determine the appropriate PWM signal to acquire proper servo rotations.
  2. Gyroscope
    1. Will test gyros for tolerance values and resolution to develop mathematical formulas for the equations
    2. Will test for any changes to the chip
  3. LiDar
    1. Will test and research LiDar sensor to determine optimal operation with algorithms.
    2. Will develop equations for operation of LiDar system.
  4. Will work with Computer Systems and Software to optimize servos and gyroscopes.
  5. Will constantly scrutinize design for noise or power issues.

 

 

Fall 2015 MicroBiped Level 1 Requirements

By Paul Oo

Approved by Paul Oo (Project Manager)

Approved by Michael Balagtas (PCB Design and Manufacturing)

 

Objective

The CSULB μBiped project provides its members with the opportunity to not only design and produce a control theory project, but also to define a purpose for this project. A Biped Robot is designed to model the movement of the human lower body. The goal of this project is to prototype a μBiped that resembles a toy raptor. By customer’s request, this μBiped shall be controlled by Bluetooth on an Android phone. Due to an evolving objective, the payloads shall be determined by the customer.

Level 1 Requirements

Program Requirements:

In order to meet logistical expectations, the following program requirements have been set:

  1. According to the CSULB Fall 2014 Academic Calendar, the μBiped robot shall be tested by December 16, 2015; the date of the last day of finals.
  2. The μBiped shall be able to successfully navigate a course with obstacles, inclined path of up to 6o, and varying surfaces.
  3. According to 2014-2015 ARXTERRA µBiPed’s parts list, the project shall cost no more than $400.00.

Project Requirements:

In order to meet our objective to construct a robot that models human legs, the following project requirements have been set:

  1. In accordance with the project name, the μBiped shall travel on 2 legs.
  2. To be considered a miniaturized Biped robot, the μBiped shall range between ½ (120 mm) ±10% of Rofi’s dimensions according to the ratio of an MG92B μservo to Rofi’s servo.
  3. In accordance with customer specifications, the μBiPed shall be controlled by Bluetooth on an Android phone app.
  4. Based on evolving needs, the payloads shall be determined by the customer.

Micro BiPed Introduction

Mission Objective:

The project mission is inspired by the BiPed designed by Jonathan Dowdall of Project Biped, completed in previous semesters of EE 400D. The goal is to scale down the BiPed design by changing standard servos to micro servos to yield the μBiPed, which will result in design changes to the robot. The robot must be able to communicate and be controlled by the Axterra™ application. The final deliverable of this project is to have the µBiPed maneuver through an obstacle course, while being able to resist outside disturbances.  The course may include multiple surfaces, an incline, and an obstacle avoidance portion; however, the challenges in the obstacle course may change.

Mission Profile:

The μBiPed must complete an obstacle course on a figure 8 track in ~ 7 minutes. The obstacle course will require the μBiPed to cross over a threshold, at approximately a 45° angle and a 2 cm height. From there the μBiPed must ascend an incline that is initially an 8° slope which then decreases to a 6° slope. Half way through the course the μBiPed must then start its descent down the incline towards the threshold again crossing over it at about a 45° angle proceeding towards its start position until an object (i.e. a wall) causes the μBiPed modify its path. Additionally the μBiPed must be able to withstand external disturbances. Finally the μBiPed must be able to traverse multiple types of surfaces which will include carpet, linoleum tile, and metal. All of this must be completed while using the Arxterra™ interface as per requirements. It has also been specified that microServos must be used.

Course

*The above diagram was created in AUTOCAD™ 2014.

*Measurements were provided by the microSegway group, and confirmed by the microBiPed group.

 

Spring 2014 Biped Final Thoughts

By Kevin Huynh, Project Manager

Tasks Complete:
Alternative movement code to the one provided by projectbiped and robot poser. Alternate code includes statically stable forward walk, left turn, right turn, and obstacle avoidance code.

Remote control of ROFIA through Arxterra. ROFIA can be commanded to stand up straight, walk forward, turn left, and turn right.

Servo overcurrent protection using polyfuses.

Ideas for future classes:
Develop the ability to walk backward or to walk sideways. Add these abilities to the Arxterra control panel along with options to move the head servos.

Consider using lower torque servos for joints that do not need to rotate as much weight to minimize current consumption. For example, look at how ROFI has the higher torque servos (Power HD 1501) to control the hip, upper leg and middle legs and lower torque servos (Towerpro MG99R) to control the
knee, lower legs, and ankles.

Look into implementing an IMU board into ROFIA for active control and the ability to react to external forces.

Minimize the mass unbalance caused by the USB cable from the phone to the Arduino.

Find a way to monitor the voltage of the LiPo batteries for safety purposes.

Biped Movement Codes

By Kevin Huynh, Project Manager / Computer Systems and Software

Objective:
This blog will focus on the ideas behind how the code from projectbiped and the code from Spring 2014 handle the animation playback for walking and turning. It will also go into the reason for the switch.

ProjectBiped Code :
The most recent code can be found here:
http://www.projectbiped.com/prototypes/rofi/programs/arduino-action-playback

The code on project biped uses a timing system for the playback of the robot’s walking animation. The Action class holds all of the code for this movement method.

Update

The timing system starts with the function Update, which calculates playbackTime with the variables currentTime, lastTime, playbackSpeed, and duration. The currentTime variable is determined by the Arduino command millis() which returns the number of milliseconds since the microcontroller began running the program. The lastTime variable is equal to the previous currentTime value from the last time the walking animation frame was updated.

The playbackSpeed is determined by the user, based on the speed they chose when creating action frames with in RobotPoser. The calculation value is assigned to a variable called playbackTime, which is used in the function GetCurrentFrame to get the frame the robot should be on. If the calculation for playbackTime resulted in a value greater than the duration, the duration value is subtracted from the playbackTime, to create the animation loop.

Actions

In the most recent code, the duration of the action is determined by the numberOfFrames variable multiplied by 30, but in the code exported from RobotPoser, it is multiplied by 20. ~I’m not exactly sure what those numbers are, but they are likely values for milliseconds per frame. This would result in a time value. For the most recent code, the duration would be 2.52 seconds for the entire walking animation.

durationCalculation

GetCurrentFrame

Once playbackTime and duration are calculated, they are used in the GetCurrentFrame function. The parameter passed into GetCurrentFrame is a blank 1×12 array for containing the animation frame the robot will move to. The pointer sourceFrame points to the address of the frames array plus a value based on the playbackTime and numberOfJoints. From that address, the frame array takes 12 (numberOfJoints) from the frames array and the robot is told to move the servos to the specified positions.

Example:
When the robot starts up, the there is lastTime is set to 0. Suppose the value retrieved from the millis() command is 1000 ms, so currentTime = 1000 ms. The playback time is then equal to 1000 ms. Since the playbackTime is less than the duration of 2520 ms, there is no subtraction.

Then the GetCurrentFrame function is called and an empty 1×12 array named frame is passed into the function. From the equation, sourceFrame is equal to the address of the frames array + ((int)1000/30)*12. Since 1000/30 is type-casted to an integer type, the value is rounded down to 33, so sourceFrame = (address of the frames array) + 396. This points to the address of the first value of the 33th (if the first row is counted as the 0th row) frame of animation. Afterward, there is a for loop that loops 12 times to get all 12 values of the 33th row to put into the frame array for use in the SetServoPositions function. The frame array at 1 second should be:
{382, 70, -2837, 420, 4275, 1102, -1770, -472, 972, 0, -1520, -2612 }

Spring 2014 Code:
PlayFrames
The code used for Spring 2014 used a simpler method for playing the action frames. Rather than use a timing system to determine which frame the robot should be on, the new code uses two loops to run through every element of the action frame array. One loop runs through the elements of each row to update each servo. The second loop moves from row to row to progress the animation. A playbackDelay variable is used to determine the speed of the action progression. The action of moving the servos to their positions is based on the SetServoPositions function from the original code. The rest of the code is similar to the original code.

Reason for the switch:
When creating the animations and testing them out on RobotPoser, there were no significant issues with the playback. However, when attempting to have the microcontroller handle the animation in a standalone code, the robot would start on a frame in the middle of the walking animation, rather than start on the first frame.

This issue became more prominent as more code was added to handle the obstacle avoidance using the ultrasonic sensor, since the delays caused by the use of the ultrasonic sensor affected the timing of the animation. The problem was found when two things happened. The first was that the incorrect leg oved forward at the start of the playback. The second was the effect of the addition of the ultrasonic sensor code and the right turn code on the forward walk layback. After the robot turned right in response to an object 30 cm in front of it, the forward walk would start on the incorrect frame.

With the new program, the robot will always start on the first frame and run through the animation without skipping a frame. The addition of more code has been simplified because of the minimal impact on the animation playbacks, since the playback speed is controlled by a manual delay. In addition, the new code will hopefully be easier to understand at first glance.

Main Code (without Arxterra):
https://github.com/kh0/Spring-2014-ROFIA/blob/master/ROFIACode/MovementCode

Note: The Arduino code exported from RobotPoser does not include the functions that apply the calibrations to the frames of animation.