Posts Tagged ‘robot car’

Top Down Robot Car!

Friday, June 29th, 2012

So with a title like Top Down Robot Car I bet you think I’m talking about a convertible version of a robot car. Sorry, not this time, although the reason a robot might want to implement the feature of ‘roof retract-ability’  could be an intriguing question – improved chances of picking up robot-girls perhaps?

In this case I’ll be talking about the design process for specifying and modelling a robot car using a top-down approach.

Disclaimer: I have never built a robot car before, in fact, I am just learning about artificial intelligence in my current Udacity class (cs373) which uses a robot car as the sample problem. I am however a systems engineer with experience in the aerospace industry. As such I thought it might be beneficial to compare and contrast a method familiar to me (top down) with the approach being used in the class (bottom up).

In my previous post, I essentially captured a bit of the bottom up approach being used to teach the class. One of the lowest level questions possible, was the first one asked; from the robot perspective – where am I? That question, and its answer in implementation, embodies the function of ‘localization’. The Data Flow Diagram in that post described the input-process-output for localization in functional analysis notation.

Here I will sketch out a top down design wherein localization but one of a number of lower level functions. Note that part of this approach is similar to the problem solving method taught by Peter Norvig in Udacity, cs212, the Design of Computer Programs.

The top level requirements of a car might be – provide point to point transportation over a road network while observing driving rules and avoiding collisions with other objects in the environment.

A simple concept inventory then might be:

  • transport (the car, or platform)
    • location
    • speed
  • environment (the network of roads, traffic signals, etc.)
  • points (different locations along the path of the car, starting with the origin, ending with the destination)
  • sensors (detect environment, state, and objects)
  • guidance (what is the next point along the path?)
  • control (what speed and steering commands will get to the car to the next point on its path?)
  • rules (constraints on how car moves in environment)
  • objects (anything that enters the car’s area of concern)

Upon translation of these concepts to a data flow diagram format several important distinctions have been made as described below.

a simple data flow diagram

a rough draft, likely to need revisiting as class proceeds

Things external to the system are abstracted as rectangular shapes. Functions internal to the system are enclosed in ovals, and information that must be shared is represented by a data store symbol, two parallel lines. Data flows are represented by directional arrows.

One other important note about abstraction. The class is about artificial intelligence as applied to cars; it is not about cars themselves – cars are mundane. As such the car is simplified into the ‘transport’ function. At the end of the class we’d just buy a car and bolt on all the required sensors, and associated AI componentry, as an appliance. Important functions like sense, guide, control are isolated and shown to interact with the car (or ‘platform’) via data flow. Understanding of these is germaine to the class and warrant standing alone for the purposes of functional analysis.

This crude model will have to be revisited as we go, but for now it suffices as a good starting point, and provides a reasonable introduction to top down design principles.