Scout OS Organization¶

A general overview of how the system is organized. See below for a description of each system part.

User Behavior¶

A behavior, from Smart Runaround to Hunter-Prey to larger-scale collaborative efforts. This is where code is written after completion of the library. Code here should be very simple - the library should already define functions to set the motors, check the sensors, etc.

Code:

• Should extend the Behavior.cpp/h in the libscout/src directory.
• Should be put in an appropriate folder, eg libscout/src/behaviors/hunterprey.
• Should be named appropriately, eg HunterPreyBehavior.cpp/h

Principles:

• No ROS calls should be visible within the behavior file.
• All ROS structure should be set up with a single init() call.
• A user behavior should extend the Behavior class, which has it's own constructor and other methods.
  • The user only has to write a behavior function.

Library¶

Where all the logic goes. Provides an interface to the user behavior, and produces ROS messages and services with which to communicate with either the hardware nodes or with the simulator.

Code:

• Each sensor should have its own control unit, defined in <sensor>Control.cpp/h in the libscout/src directory.
• The Behavior interface should have its own class, defined in Behavior.cpp/h in the libscout/src directory.
• Example: MotorControl.cpp/h

Principles:

• All the "logic" should be done here. ROS communications should represent commands or reads from the hardware, but any processing of these inputs and outputs should be done in library code.
• Object-oriented design should be followed whenever possible.

ROS Hardware Nodes¶

Provide the interface to hardware. Are run separately on the Scout system, and listen for commands via ROS messages and services. Also publish output on ROS, via messages and services. Can link to one another (for example, motors may depend on serial) and use the appropriate ROS calls for abstraction.

Code:

• Found in the appropriate folder alongside libscout, eg motors. "roscd motors/" will get you to the motors node.
• Implicitly object-oriented, because of the nature of ROS nodes. However, there is no need for C++ classes.

Principles:

• Should not contain any logic, but should instead merely translate between commands and hardware.

Simulator¶

Intercepts the ROS calls made by the library, and instead of using the hardware, runs a simulation of what the robot would do.

Code:

• Found in the scoutsim folder. "roscd scoutsim/" will get you there.

Principles:

• Should compile using the msg/srv files found in the ROS Hardware Nodes. Unfortunately, this means scoutsim will depend on all those packages.
• Should not depend on the libscout directory.
• Should not contain any application logic - just its own simulation of the scout.
• Should be easy to adjust the time, add obstacles, and run different behaviors at once.
  • Different behaviors can be run at once by adding a ScoutID prefix before the ROS messages a given behavior outputs.
• Should provide launch or other files that make it easy to select and run behaviors (to ensure they all start at the same time).