Robotic Obstacle Recognizer –
NASA Skills Demonstration Project
Introduction:
This
is a quick description of a Robotic Obstacle Recognizer. For more detail,
follow the appropriate links.
Problem statement:
A problem statement is given by NASA to write an application that will help a robot navigate around a messy lab. Here’s a 360 degree view of the environment. Here’s the detailed problem statement.
Assumptions and Requirements:
To attack this, I started off, writing some assumptions and requirements.
Design:
Next, I produced an initial draft of the design. It was basically a class definition with some documented assumptions.
Prototyping and Implementation:
I started writing some preliminary code, to show my C++ chops. My code included use of the vector class in the Standard Template Library and development of a singleton class I call, ObstacleDetector.
Agile Technique:
I wrote up pseudo code to describe the essential steps each of the member functions would take in doing their job, and then I started to code that up. As I learned more during the implementation, I modified the design. This really demonstrated use of the Iterative/Incremental idea in first the Unified Process by Ivar Jacobson, Grady Booch and James Rumbaugh. More recently, that idea has been adopted and augmented by those using Agile development. With each iteration, I learned more, developed more working functionality and resolved more problems.
State Behavior:
However, the complexity of all the different scenarios was just something that I kept cycling on. So, I put together what I call the Obstacle Identification State Machine. It helped me to adapt behavior based upon the state of the detector and what had led up to the current state.
Verification:
Now, I had a much more structured way to think about
operation of this detector. It became a matter of defining what happened with
each of the transitions as the machine flows from state to state. At this
point, I iterated on the code and the state machine. That became a bit
intractable 
until I added a spreadsheet with test cases. With each
test case, I documented what happened on each state transition. And then, I
used this as a guide for actually performing the tests cases and a recording
tool for capturing test results. Once I had done this for my own data, then, I
knew I was ready to do this for NASA Data.
Validation:
“Validation” is the process of verifying that the
requirements were written properly and the system performs as intended. In the
case of this demonstration project, 
obstacle recognition
data (top/amber) tracked NASA supplied features data points
(bottom/blue) with no adjustment to the code or the parameters.
Project Deliverables:
The code, documents and drawings used to realize the solution and verify behavior are accessible on myGitHub Robotic Obstacle Recognizer Project.
Safety:
You can follow a recipe and perhaps create the wrong product. Ariane flight V88 cost $370 US because of a software flaw. So, the code can be written superbly--and it should be. But, if response to errors are not imagined creatively and resolved in development guided by a System Safety Assessment Process, then it could all be for nought. This is why safety is typically achieved by using guidelines such as ARP4761A.
This Obstacle Recognizer Project demonstrates all the processes listed above, except for the safety process due to time limitations. Also, there would be no safety implications for such a demonstrator project. However, if a robot was acting on data received from this process, some safety implications could be applicable.
Contact Information:
Scott Vigil July 16th, 2024