1.8. Floor¶

The SensFloor® helps to track people inside the apartment, to know where they are and perhaps adjust the activity of other sensors. Multiple modules can be combined and allow to track the staying frequency in specific areas. Other scenarios which could be established with the floor are for example: Security (Intrusion detection), Safety (Detect unconscious people), Input device (Use gestures or as a playing field). Depending on the scenario, the capacitive floor can be an ambient sensor which does not require a specific user attention or it could be used consciously as an input device.

The Floor component actually consists of four specific components:

• FLOOR-Base
• FLOOR-View
• FLOOR-Sim
• FLOOR-Input-Emulator

Additionally a seperate FLOOR-Lib has been developed to provide an API for rendering and interacting with the floor-patches in graphical user interfaces.

The FLOOR Modules are hardware tiles which are installed in the apartment kitchen and sportsroom. Each module consists of eight triangular segments. They sense capacity changes and send them wireless to the FLOOR-Gateway. This is a small receiver which must be connected via USB to one of the PC’s in the apartment. This PC should execute the FLOOR-Base component which reads the incoming data from the USB, encapsulates it in an RST packet and sends in out on a specified scope via RSB. All other applications use the incoming RSB Data and process it for their individual needs. The FLOOR-Sim is also able to generate RST Data to emulate motion events for testing purposes. This data is published via RSB in the same way as in the FLOOR-Base component.

The RST Datatype encapsulates the data from the FLOOR Modules which is described in the SensFloor Receiver Document which is linked in the References section. Each FloorModuleState should contain eight FloorSegmentState(s) which hold the information about the individual segments (active: true/false, capacity: 0-255). Additionally the FloorModuleState contains information about the position of the module. This is also extracted from the information that the FLOOR Modules transmit to the FLOOR Receiver (each Module has an encoded position).

message FloorModuleState {
    message FloorSegmentState {
        /**
         * The capacity values for each of the eight segments in a module.
         */
        required int32 capacity_segment = 1;
        /**
         * The activation values for each of the eight segments in a module.
         */
        required bool activation_segment = 2;
    }
    /**
     * The activation and capacity combined in one message.
     * Each module consists of 8 segments, so normally this field should be
     * repeated 8 times. The segments are ordered clockwise, starting at
     * 12 o' clock position.
     */
    repeated FloorSegmentState segment = 1;
    /**
     * The Position of the module in the room (from the transciever).
     */
    required int32 position_col = 2;
    required int32 position_row = 3;
}

1.8.3. Examples¶

Starting the FLOOR-Base component in two different ways:

 floor_base PARAMETERS
 floor_base --scope-device-manager SCOPE [PARAMETERS]
 floor_base --scope-device-manager /devicemanager/registry/ctrl
 floor_base --scope-device-manager /devicemanager/registry/ctrl --usb-receiver-id Future-Shape_SE3-P_0285000
 floor_base --scope-custom [ID=SCOPE]*
 floor_base --scope-custom 0286=/home/sports/floor 0284=/home/kitchen/floor

Starting the FLOOR-View component in two different ways:

 floor_view [PARAMETERS]
 floor_view [--room <roomName=roomScope>] [--schematic <SchematicFile>]
 floor_view --room SportsRoom=/home/sports/floor/ --schematic sportsRoom.floor
 floor_view --scope-device-manager SCOPE
 floor_view --scope-device-manager /devicemanager/registry/ctrl

Pictures of some of the components:

FLOOR-View

FLOOR-Sim

FLOOR-Input-Emulator