Breaking down the mechanics of the Navigation.ino file, the key features and verified through the 3DoT’s implementation was the capabilities to walk, stop, turn in any of that order depending if there is an obstacle in direct course or not in front of MicroFobo.  This implentation provided a numerous amount of data and more into how MicroFobo operates.

To start, let’s break down the reason why the exported files are called .action. In the Navigation.ino file, there is a class defined as Action. Now, Action takes precedence in the way MicroFobo works as this is the way how the servo positions are processed from the matrices from the Fobo Poser.

Action Class
These are its components and direct parameters, where it is broken into its number of frame sets, total frame set count, frame delay in milliseconds, and void name to go by.

From here, the Action class is futher defined into the way how frames are interpreted and processed over time. As shown below, this is the code of the frame set organization.

These is the function defined within the Action class

To describe what is going on here, let’s break down NextFrame(), GetCurrentFrame(), GetFrame(), and GetIntermediateFrame(). NextFrame() works in a way where the current frame position of MicroFobo it calculated and procedes to move onto the…next frame, in the current matrix, which is also the new servo positions. If the next frame exceeds the max, the frame number is reset to zero. This is then fed into GetCurrentFrame(), where the current frame is found and fed into a being attached with both the frame servo position componentsand the exact frame number in the matrix. This is then fed into GetFrame(), where the frame is calculated into the number of frames in the set, number of frames remaining, if it is above the max amount and how it is from repeating based on a percentage complete. Lastly, GetIntermediateframe()  describes taking these percentages and states of the frames. They determine how to move onto the next frame based on current and next frame servo positions before even Fobo moves to and out of it.

Now, the 1st major component is taking multiple matrices to move MicroFobo. In these matrices multiple Actions are made and saved. They are listed as…

Additionally, since there is multiple actions, it is needed that a calibration addition is placed in SetServoPositions().  Specifically, it looks like:

where the servoAngle serves a way to help Fobo recalibrated when each angle is being processed based on the preset calibration servo angles from the Fobo Poser.  This is function is found and constantly in Loop(), where the angles are in relation the adjusted calibrated servo angles of MicroFobo.

Now to sum up turning and walking, this is managed automatically by the ultrasonic sensor where it can be seen below:

Ultrasonic Sensor Code
This was in the navigation.ino file where it was provided by David A. Mellis and modified by Tom Igoe.

Now, as shown, this is pretty standard code for setting the ultrasonic sensor, as with the modifaction to make it workable through a single pingPin, which will feed the signal back to determine turning sequences when MicroFobo sees an obstacle up ahead.

UpdateAction()
This is where the magic happens for MicroFobo. Almost all the logic is concentrated into here.

Here, inUpdateAction(), this void provided the way MicroFobo determines changes in the way matrices are read and change within it’s logic.  Essentially, the way the code works is that if MicroFobo seeas an object when the current action is walking, it will change it current frame and shift it to stop in a servo position where it can start running the turning action from frame zero.  Then when the current Action is turning it will turn all the way until it is complete before it will run back to the walking action.  This loop essentially can loop endlessly, as if it keeps seeing a wall where it will keep turning till there is no wall or it will keep waking till it finds a wall.