Rationale Behind Brightness Module
The research project I'm working on these days is suppose to make a building smart. It should know it's occupants whereabouts and have to adjust energy related parameters(light level, AC level, etc) accordingly. For example if there are 3 people occupying a 1 desk in a big room with 25 desks, it should keep lights in workable level only around the occupied desk. The ultimate goal is reducing the energy consumption while keeping occupants happy.
In order to optimally adjust the lights building should also have a sense of the brightness of the affecting area. Else there a chance to wrongfully adjust the lights and be a dumb building.
We already have a dockerized system to detect the occupancy of the building. And we have promising results for the brightness detection too(fingers crossed). So I am designing a new docker service to integrate this brightness detection to that existing system.
The responsibilities of the module are,
- access each cameras feed
- detect the brightness of each scene
- write that values to a database.
Then another service will read this brightness value and the occupancy values(output of another module) and adjust the buildings AC and lights.
To do this first we have to access the camera feed. There are about 50 cameras in the building. We are using opencv library VidoeCapture method for that. Since it's a blocking call and a expensive at that, module will have one thread to decode each camera feed. Then since detection of brightness is also comparatively a expensive operation there will be one brightness calculating thread for each camera. All this calculated brightness values will go for a single queue and a single database thread will write all these values to DB.
That's the design at the start and based on metrics it will be adjusted. After all premature optimization is the root of all evil.