The senses component provides classes for accessing hardware elements (sensors and effectors) and some higher-level concepts such as rangefinder (which can be a laser, or a sensor mounted on a servo turret). All basic classes ​are abstract (e.g. Sensor or Servo), because most sensors and effectors behavior and configuration depend on hardware specificities. Since these specificities actually depend on the hardware controller used(e.g. an SSC-32 controller),​ there is one version ​of each basic class for each hardware controller supported in HBot (e.g. SSC32Sensor or SSC32Servo). To support these derivated classes, a controller class per hardware controller provides settings, atomic commands, communication,​ factory concept for instantiation of the specific sensors and effectors. ​

+

The senses component ​mainly ​provides classes for accessing hardware elements (sensors and effectors), hiding the differences ​and complexity of interfacing to the rest of the stack. Some higher-level concepts ​are here too, such as rangefinder (which can be a laser, or a sensor mounted on a servo turret), because they are either one hardware device (laser) or a combination of hardware devices (sensor mounted on servo). The abstraction of hardware differences is rendered as C++ abstract ​classes ​(e.g. the Sensor or Servo classes), because most sensors and effectors behavior and configuration depend on hardware specificities. Since these specificities actually depend on the hardware controller used(e.g. an SSC-32 controller),​ there is one implementation ​of each basic class for each hardware controller supported in HBot (e.g. SSC32Sensor or SSC32Servo). To support these derivated classes, a controller class per hardware controller provides settings, atomic commands, communication,​ factory concept for instantiation of the specific sensors and effectors. ​

===== Devices =====

===== Devices =====

Line 8:

Line 8:

==== Controllers ====

==== Controllers ====

-

For the moment, three types of controllers ​exist in HBot:

+

As of v0.7.7, here are the types of controllers ​existing ​in HBot:

* SSC32Controller,​ that enables the use of an [[SSC-32]] controller from lynxmotion

* SSC32Controller,​ that enables the use of an [[SSC-32]] controller from lynxmotion

* FakeController,​ that provides stubbed version of sensors and effectors

* FakeController,​ that provides stubbed version of sensors and effectors

* PlayerController,​ a wrapper for accessing the Player hardware abstraction layer from the [[dependencies#​player_stage|Player/​Stage]] project

* PlayerController,​ a wrapper for accessing the Player hardware abstraction layer from the [[dependencies#​player_stage|Player/​Stage]] project

+

* RoombaController,​ handling the communication with the Roomba Open Interface from iRobot

+

* OSIFController,​ that enables the use of the [[http://​www.openservo.com|OpenServo]] Interface controller (note: this controller is only partially implemented)

+

* BluetoothController,​ wrapping the local bluetooth stack to establish connection and communication with bluetooth devices.

==== Effectors ====

==== Effectors ====

Line 44:

Line 47:

===== Instantiation =====

===== Instantiation =====

-

Controller classes implement several factory interfaces depending on the type of devices physically attachable to a controller. ​

+

Controller classes implement several factory interfaces depending on the type of devices physically attachable to a controller. The Controller abstract class itself is a Controller factory. All configuration provided through lua scripting is passed to the factory method, that match the configuration strings with the correct implementing class constructor.

===== Repositories =====

===== Repositories =====

-

To facilitate ​sensors and effectors ​management, ​they are automatically registered into global repositories. All repositories are accessible by including the devicerepository.h header, which defines a class template DeviceRepository,​ which is a singleton, and accessors for instances of each repository (e.g. servoRepository,​ sensorRepository...)

+

To facilitate ​devices ​management, ​all the objects that represent a hardware device ​are automatically registered into global repositories. All repositories are accessible by including the devicerepository.h header, which defines a class template DeviceRepository,​ which is a singleton, and accessors for instances of each repository (e.g. servoRepository,​ sensorRepository...).