Ggil-pfc-itis

• Project Name: Domotic Devices

• Authors: Gonzalo Gil (ggil@gsyc.es) and Jose María Cañas Plaza (jmplaza@gsyc.es)

• Academic Year: 2009-2010

• Degree: Undergrad

• Jde Version: jde-4.3

• SVN Repository: ggil-repository

• Tags: Domotic, CM, Lamp Module, Motion Detector, Optical Flow.

• Technology: C, C++, jde suite.

• State: Developing

• Abstract: My final project is focused on controlling some domotic devices with X10 and KNX technologies.

JDERobot 4.3: installation

In order to start this ambitious project i had to install the jde platform and it's components, with enough problems in the configuration of 3D enviroments and the assembly of the firewire drivers.

For complete my learning with this new software for my i had to prove the major schemas supported by the tool and create two basic schemas more.

JDERobot 4.3: first steps

My first contact with the jderobot platform, was through the introrob scheme, it has a function that allows at user to insert a fragment of code with specific orders to realize a simulation of the robot.

Then i made some modifications in algorithms of differents schemas...

Schema: Bump & Go

This video shows the behaviour of a pioneer robot, in an environment simulated by stage/player, using a simple bump and go algorithm:

Schema: Color Filter

Color Filter gives you the possibility to apply a color filter at image, you may only adjust the threshold and select the image you want:

X10 Protocol: introduction

X10 is an international and open industry standard for communication among electronic devices used for home automation, also known as domotics.

Whether using power line or radio communications, packets transmitted using the X10 control protocol consist of a four bit house code followed by one or more four bit unit code, finally followed by a four bit command. For the convenience of users configuring a system, the four bit house code is selected as a letter from A through P while the four bit unit code is a number 1 through 16.

When the system is installed, each controlled device is configured to respond to one of the 256 possible addresses (16 house codes × 16 unit codes); each device reacts to commands specifically addressed to it, or possibly to several broadcast commands.

The protocol may transmit a message that says "select code A3", followed by "turn on", which commands unit "A3" to turn on its device. Several units can be addressed before giving the command, allowing a command to affect several units simultaneously. For example, "select A3", "select A15", "select A4", and finally, "turn on", causes units A3, A4, and A15 to all turn on.

Commands list

Code	Function	Description
0 0 0 0	All Units Off	Switch off all devices with the house code indicated in the message
0 0 0 1	All Lights On	Switches on all lighting devices (with the ability to control brightness)
0 0 1 0	On	Switches on a device
0 0 1 1	Off	Switches off a device
0 1 0 0	Dim	Reduces the light intensity
0 1 0 1	Bright	Increases the light intensity
0 1 1 1	Extended Code	Extension code
1 0 0 0	Hail Request	Requests a response from the device(s) with the house code indicated in the message
1 0 0 1	Hail Acknowledge	Response to the previous command
1 0 1 x	Pre-Set Dim	Allows the selection of two predefined levels of light intensity
1 1 0 1	Status is On	Response to the Status Request indicating that the device is switched on
1 1 1 0	Status is Off	Response indicating that the device is switched off
1 1 1 1	Status Request	Request requiring the status of a device

Protocol limitations

Commands getting lost

X10 signals can only be transmitted one command at a time, first by addressing the device to control, and then sending an operation for that device to perform. If two X10 signals are transmitted at the same time they may collide or interleave, leading to commands that either cannot be decoded or that trigger incorrect operations.

Relatively slow

The X10 protocol is also slow. It takes roughly three quarters of a second to transmit a device address and a command. While generally not noticeable when using a tabletop controller, it becomes a noticeable problem when using 2-way switches or when utilizing some sort of computerized controller. The apparent delay can be lessened somewhat by using slower device dim rates. With more advanced modules another option is to use group control (lighting scene) extended commands. These allow to adjust several modules at once by a single command.

Limited functionality

X10 protocol does support more advanced control over the dimming speed, direct dim level setting and group control (scene settings). This is done via extended message set, which is an official part of X10 standard <ref>Standard and Extended X10 Code Protocol Specification</ref>. However support for all extended messages is not mandatory, and a lot of cheaper modules implement only the basic message set. These require adjusting each lighting circuit one after the other, which can be visually unappealing and also very slow.

Interference and lack of encryption

The standard X10 power line and RF protocols lack support for encryption, and can only address 256 devices. Unless filtered, power line signals from close neighbours using X10 may interfere with each other if the same device addresses are used by each party. Interfering RF wireless signals may similarly be received, with it being easy for anyone nearby with an X10 RF remote to wittingly or unwittingly cause mayhem if an RF to power line device is being used on a premises.

JDERobot 4.3 & X10 Protocol: First steps

To start using in jderobot platform, devices that communicate via the X10 protocol I had to extend the driver code x10.conf and develop from the beginning a basic scheme that would allow the communication between a machine and a x10 device.

I decided to call it On Light

JDERobot 4.3 & X10 Protocol: On Light schema

Mi first schema is focused to controll a lamp, it will allow us to turn it on and off with a few clicks.

It used a Lamp Module (LM12) and a Programmable Computer Interface (CM11):

JDERobot 4.3 & X10 Protocol: Spy System schema

It's a control system that allows detect unexpected movement through an USB Camera, if any of the three algorithms used by the applicattion detect motion it make a sound. If we want we can record a video of 25 seconds after motion detection to find out what is happening.

This system used the follow devices:

PC Interface (CM11):

Transmitter (TM13):

Wireless Motion Sensor (MS13):

USB Camera:

This spy system allows us to detect motion using three differents algorithms.

[01/02/2010] First, Optical Flow settings

[First version 01/02/2010]:

[Second version 12/02/2010]:

[25/03/2010] Second, Pixel Difference settings

[First version 27/02/2010]:

[Second version 16/03/2010]:

[Third version 25/03/2010]:

Finally, calibration

For calibrate the diferents parameters of Spy System I used a video test and mplayer driver.

This record help me to configure Optical flow and Pixel Difference algorithms, for the calibration i'm used this video around hundred times, and I compare the results with the differents values.

Conclusions:

    -> The optimal distance at which the optical flow algorithm recognizes the movement of people is about 4-6 meters, at a further distance the algorithm interprets it as irrelevant motion.
    -> The optimal distance at which the pixel difference algorithm recognizes the movement of persons is 3-5 meters.
    -> The optimal distance at which the motion sensor detects movement is a straight line 10 meters and 4 meters at 45 degrees.