For the last few months now I have been focused on creating a wearable camera for the Dare to Dream Different contest. Okay, wearable is a relative term, especially since I am not exactly known as a fashion maven, but keep in mind my current design is only a prototype. Basically I am trying to achieve what a cell phone camera and camcorder can’t, the integration of recorded video into the daily life of the wearer. This means no more stopping to record video hoping that the subject matter will hold still.
Inevitably such use of ubiquitous video capture will contain unwanted video sequences. For this reason the camera will possess a sensor array to allow the scene content to be analyzed before video capture is activated. A diagram of how this prototype might appear is included below, though it has already changed to accommodate certain mounting problems.
Ideally as this prototype evolves the camera will become much smaller, and will eventually mount to the wearers clothing in some manner. For now, I have settled on mounting the sensors and camera lens to the brim of a baseball cap. Though it appears in the picture that the camera and sensors are contained in a single unit, I have actually mounted the sensors on one servo and the camera to another servo, both of which are mounted side-by-side to the baseball cap. By separating them I can allow the sensors to scan the field for objects of interest, or to track an object in motion, before actually repositioning the camera. I will provide pictures of me sporting the sensor/servo equipped baseball cap in a future blog post.
So what would someone want with a wearable camera you ask? Well, if you just imagine how cameras get used today to collect a record of a particular event or to monitor an area for possible intrusion, there are three distinct usage scenarios that come to mind.
Law Enforcement
Most law enforcement actions with video monitoring are limited by the location of the camera, vehicle mounted in the case of traffic stops, and wall mounted when monitoring public spaces. If the camera could follow the law enforcement person as he/she enters harm’s way, the video coverage could be used as a means of recording a complete record of the event, including the interaction with suspicious persons.
Tourist
When traveling, most of the great shots are often missed or the person is forced to strap a camcorder to their hand and walk around staring at an LCD display to compose a good video sequence. This usually comes at the cost of interrupting some other vacation activity, and can become a nuisance to those of us who just want to get on with it. Here again, if the camera was being worn in an unobtrusive way it could be forgotten and a video record of the day automatically captured.
Adventurer
Those who engage in risky athletic activities may want to record their death defying feats as they occur. This is obviously not the time to be holding a camera, especially if both hands are required to avoid disaster. A camera mounted to some part of the wearer’s gear could capture all of the exciting details, and would lead to far fewer “fish stories.”
Issue
As I see it, the most common issue to the use of a wearable camera in all of these scenarios is the over abundance of video data. The camera must be as smart (or smarter) than the wearer and capable of capturing only those scenes that the wearer might be inclined to record if they were controlling the camera manually. This is where the sensors come in. The wearer will have an LCD display from which the threshold levels of each sensor can be configured in combination with all other sensors. Each threshold level can then be logically and’ed and or’ed together to create a video profile which describes the conditions under which a recording sequence is activated. Of course the complexities when attempting to fully characterize scene content vis-à-vis the sensor compliment (and eventually video analysis) are endless. I can see a day where an XML based declarative representation of the video profile could be devised.
Engineering Log
The engineering of this prototype is well underway using the .NET Micro Framework and the Tahoe II board from Device Solutions graciously provided by Microsoft to the those who passed round 1 of the competition. I am new to the .NET MF so initially it was slow going, but it didn’t take long to get going since I have used C# for other projects.
I will be posting every week for the next few weeks as the round 2 deadline of the Dare to Dream Different contest draws near. I will try to convey my successes and frustrations as things come together, and give you my first impressions of the .NET MF as a tool for embedded developers.
Onward!