Home > RobotC Code > Classes for virtual Sensors–Bumpers

Classes for virtual Sensors–Bumpers

As I rework the behavior-based robot framework, I am encountering other areas of code that could also use improvement.  In the case of some of my sensor wrappers, I am not even sure if I ever published them.  I sometimes create virtual sensors when a group of sensors is used for specialized purposes.  The robot programs are more readable and internal logic can be abstracted from the rest of the program making for an easier implementation.

Bumpers – An example of a virtual sensor

I have a tendency to use bumpers on the front of my robots for easy (bump and escape) navigation.  Over the years I have created a couple of code sets that treat the bumper as one sensor even if I use two or more physical sensors to create it.  This article shows why and how I created a class to hide the details of a “Front Bumper” implementation.

Why create virtual sensors?

There are times when one or more physical sensors need to work as a unit on the robot.  Any combination of sensors that work as one should be considered for this treatment. 

  • Readings can be taken at the same time, and used after that to make decisions for the sensor group.
  • Different combinations and value readings from the sensor group can be combined into specialized output values
  • Different behaviors within the same program use one common set of methods for access data.

Two Switches to Make a Front Bumper

  • Two Bumpers connected to different ports – A good example is a left and right bumper pair on the front of a robot.

In this case, the programmer may be concerned about a bump on the left, right or both.  Most programs set up routines for reading the left and right bumpers separately.  This works in most cases, but does introduce some problems.

  • The sensors are read sequentially, so they are not processed at the same time which could lead to problems when programming correct actions.
  • The sensors are usually read in the same order, so the robot has a tendency to respond to the first positive hit and forget the second.
  • It is difficult to analyze when both bumpers are triggered.  Is this a state that is interesting?  It might be.
  • The programmer needs to understand the bumper implementation (normally-open/closed) and account for this in programs.
  • There is little code reuse.  The programmer needs to reinvent the process for each robot.

In the case of the “two bumpers/ two sensor port” scenario, I created a class that can be instantiated within a program that provides simple, easy to use methods.  It hides the raw data and implementation.  Here are the methods:

1 TwoBumper(_cls, r, l, rtyp, ltyp); //CREATES A NEW TWO BUMPER CLASS 2 void TwoBumper_Read(clsTwoBumper &_bumper); //READS SENSOR VALUES 3 bool TwoBumper_isBumpedRight(clsTwoBumper &_bumper); //RETURNS IF RIGHT IS TRIGGERED 4 bool TwoBumper_isBumpedLeft(clsTwoBumper &_bumper); //RETURNS IF LEFT IS TRIGGERED 5 bool TwoBumper_isBumpedBoth(clsTwoBumper &_bumper); //RETURNS IF BOTH ARE TRIGGERED

The class is created with TwoBumper(..).  The Read() method takes readings from both switches, and sets values internally for use later when the values are retrieved.  The rest of the methods are very self explanatory.  They are used to retrieve the state of the TwoBumper virtual sensor.

Here is the sample code: TwoBumper.zip – Sample program and class file for a Two Bumper Virtual Sensor

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: