Bumblebot: A state machine

Overview

These will be notes I write to myself regarding the software necessary to program the navigation, movement, observation, orientation and battery charge control of this tumbling robotic rover.

I’ll be building a state machine that represents command & control of the bot. If you’re not familiar with a state machine it’s essentially a flow chart. The flow between the ovals (conditions / modalities), squares (commands / directives) and diamonds (decisions / choices) represent, as a whole, a state machine’s operation. Imagine the following scenario regarding making coffee. In the flow of the decision + action tree the following sequences would be queried, periodically, throughout the day…

CURRENT STATE: In-Morning-Ritual

• Is the hour between 6:00 am and 9:00 am?
  • No? Exit.
  • Yes? Continue.
• Have we already had coffee today?
  • Yes? Exit.
  • No? Continue.
• Do we have the components to make coffee?
  • No? SET STATE: Lacking-Components. (This state would trigger a flag to go to the store.)
  • Yes? SET STATE: Coffee-Components-Available.

STATE: Coffee-Components-Available

• Is there a clean cup?
  • No? SET STATE: Clean-Dishes
  • Yes? Continue.
• Is there old coffee in machine?
  • Yes? SET STATE: Reset-Machine
  • No? SET STATE: Make-Coffee.

STATE: Make-Coffee

• At this point, the state “Make-Coffee” would contain its own internal state machine. We would break down the process of fetching the paper filter, filling it with coffee, filling the tank with water, flipping on the switch… You get the point.

Essentially, within the overall system there are nested states each having their own internal mini state machines. One can, at any point, examine the current state which will inform you — ‘the system’ — what to do next.

Bumblebot internal & external conditions & constraints

• Battery charge state
  • Adequate: OK to run the motors and analysis components.
  • Low: OK to run the motors — but only to acquire a solar charging position.
  • Critical: Not OK to run the motors; reduce power to lowest consumption level.
• Illumination level
  • Adequate: we should be able to perform movement and visual observation.
  • Inadequate: it’s night time or cloudy, no sense in moving about.
• Solar orientation
  • Adequate: we are receiving minimum viable charging.
  • Inadequate: we are NOT receiving MVC.
• Bot orientation
  • Level: we are ready for further instructions
  • Tumbling: we are in transit, our X & Y axes are not zeroed and/or our latest accelerometer measurements are in flux.
• Orientation directive
  • In process: initiate and perform an X (pitch) or Y (roll) axis rotation.
  • Awaiting command: We’ve completed our previous directive and are awaiting further instructions.
• Navigation directive
  • In process: head Northwest for 100 meters.
  • Awaiting command: we’ve performed our prior navigation request.
• System directive
  • Panic: conserve power until battery returns to adequate; a critical state has been reached, suspend all activity, and hope that solar cells are oriented for charging.
  • Sleep: Prepare for extended solar absence. Orient toward expected sun rise and go to sleep.
  • Wake: Determine if battery charged and goals exist to follow.
  • Proceed: continue with goal directive.
• Goal directive (variable)
  • Head south until told otherwise. Take photos and transmit every 10 meters.
  • Locate fellow Bumblebots and collect at midpoint nexus.
  • Navigate, at-will, to: 122.794101°W, 45.314562°N.
  • Circle base-station at 1 kilometer radius until told otherwise.

Next I’ll be attempting to detail the actual bot’s movement: the motor commands, gyroscope orientation and sequence of steps to roll the bot around.

Mad-scientist-esque Arduino mayhem…