In the last part, we finished the description of our network protocol and its advantages over other encrypted video streaming protocols. In this part, we shall discuss how we created our hardware prototype for the body camera system and what performance problems we had to resolve when we implemented the software part of it. At the end of the article, we shall show you how much our prototype costs and a sample budget for doing something similar.

But before that, let’s first see what our competition was and what features they had for their cameras.

Axon Body 2

The Axon Body 2 is a camera system incorporating an audio and video recording device. This camera is designed for use in harsh environmental conditions encountered in law enforcement, corrections, military, and security activities. The Axon Body 2 camera is designed to record events for secure storage, retrieval, and analysis via Evidence.com services. The recorded events are transferred to your storage solution via the Axon Dock or by using Evidence Sync software installed on a Windows computer.

  • HD Video and Dual Audio Channels: Record in low-light and HD, and make voices more distinct with automatic tuning and noise reduction.
  • Wireless Activation: Axon Signal reports events, like when you open the car door or activate the light bar, so your camera can start recording.
  • Wi-Fi & Bluetooth Connectivity: Use Wi-Fi to stream videos and Bluetooth to assign metadata.
  • Mobile App: Connect with Axon View to stream, tag, and replay videos from your phone.
  • Unmatched Durability: Handle in extreme weather and brutal conditions.
  • Full-Shift Battery: Record for more than 12 hours.
  • Axon RapidLock Mounts: Keep your shot steady with versatile mounts.

Motorola V300 Body Camera

This camera is built specifically for law enforcement. The V300 continuous-operation body-worn camera is ready to go when you are with its detachable battery, 128GB of storage space, wireless uploading, and Record-after-the-Fact® technology. Integrated with the technology you use daily to enhance your focus and combined with powerful device and evidence management software, the V300 body-worn video solution enables you to capture every encounter. 

  • Detachable Battery: Easily change the V300’s rechargeable battery while on the go. Keep an extra battery at the ready for unexpectedly long shifts, extra shifts, or part-time jobs where a body-worn camera is required.
  • Natural Field of View: Eliminate the fisheye effect from wide-angle lenses that warps video footage. Our distortion-correction technology provides clear and complete video evidence.
  • Built-in Display: A clear LCD on the top of the camera allows easy viewing of device status.
  • Absolute Encryption: Elevate your data security with encryption at rest and in transit. The V300 guards your data and your reputation.
  • Rugged & Durable: Tested ruthlessly to survive in a public safety environment, the V300 is shockproof and waterproof to IP67.
  • Automatic Wireless Upload: Send critical video back to headquarters while still in the field. When docked in the car, the V300 body camera uploads to cloud-based or on-premise evidence management systems via wireless networks like LTE and FirstNet, anytime, anywhere.

During the time of development, these were the two main competitions. Both of them lacked the real-time streaming support we wanted. However, both of them had pretty exciting features, without which our solution would not have enough commercial traction. 

After a good amount of market analysis and tests of different technologies, we decided our body camera system to have the following features:

  • Full-Shift Battery: Record for more than 12 hours.
  • Automatic Upload: Send critical video back to headquarters while still in the field.
  • LTE Real-Time Streaming: With adaptive bitrate, we could make our camera system send data during the whole shift.
  • Rugged & Durable: Tested ruthlessly to survive in a public safety environment
  • Built-in Display: A clear LCD in the camera system to allow easy viewing of system status.
  • Absolute Encryption: We wanted data security with encryption at rest and in transit.
  • Fisheye Field Of View: We wanted our camera system to support more than 100 degrees field of view.
  • Low Light Vision: Having in mind that most of the crimes happen during the night, we wanted this feature.

But we had a problem. Being a small, underfunded team located in Burgas, we did not have access to many hardware vendors, nor did we have the hardware team who could implement a body camera system from scratch. We had to take another approach. After a couple of weeks of analysis, we decided to implement a pluggable system using manufactured customer devices. The final system design consisted of the following components:

Hardware

  • Android-based hardware device: For the last decade, almost all Android devices have supported USB On-The-Go. USB On-The-Go (USB OTG or just OTG) is a specification first used in late 2001 that allows USB devices, such as tablets or smartphones, to act as a host, allowing other USB devices, such as USB flash drives, digital cameras, mouse or keyboards, to be attached to them. USB OTG allows those devices to switch back and forth between the roles of Host and Device. A mobile phone may read from removable media as the Host but present itself as a (USB Mass Storage) Device when connected to a host computer. In short, we could attach a standard USB web camera to a typical smartphone.
  • Body mounted USB camera: Here, we had quite an interesting problem. Standard USB web cameras are not tailored for body mounting, neither are they durable enough. We spent a good amount of time checking how to solve this issue, and finally, we managed to find a suitable USB camera vendor using Sony-based camera sensors. The vendor could mount any lens to the camera sensor, and the whole board came with a good amount of mounting holes. After that, one of our hardware people designed a custom mountable case for our USB camera and 3d printed it.
  • New extended battery: The standard battery of our Android device was around 4100mah. Unfortunately, after multiple tests, we saw that with every needed hardware capability activated, aka LTE, USB OTG, GPS, and microphone, the Android device was taking around 800-900mah per hour. And this was not enough for the whole 12 hours shift. So we took the extraordinary decision of creating our battery. Finally, we managed to produce a proof of concept 12400 mah battery replacement for our Android device. And indeed, it took 12 hours to recharge.
  •  Mount for cars and bicycles: We wanted our system to support multiple different mounting points. So, to allow this to happen, we bought standard multi-camera mounts for vehicles and bikes and created adapters for our 3d printed camera to enable attachment to the stock mounts. 

Software

On the diagram, you can see a sample architecture diagram of the solution. With that architecture, we managed to achieve 22 frames per second with streaming and encryption.
  • UDP streamer module: This module’s main functionality was sending UDP packets and receiving answers for these UDP packets. It sent analytics data to the Adaptive bitrate control module to decide how to switch between different formats and resolutions.
  • Encryption module: This module was highly optimized to perform hybrid encryption and decryption of byte objects. We managed to optimize the performance, so the module supported encryption and decryption of real-time h.264 frames coming from the USB module.
  • Network protocol module: Main functionality here was to construct and decode UDP datagrams messages. It used the encryption module to encrypt the data before sending it to the UDP streamer.
  • Adaptive bitrate and codec control module: This module controlled what type of compression strategy to use to ensure that the headquarters will receive data no matter the LTE signal. 
  • Objects pool module: The idea of the module was to reuse different bytes arrays during the lifecycle of the h.264 packets. With around 24 frames streamed per second, creating and destroying many bytes arrays would entirely kill our application.
  • USB camera module: This module wrapped the communication and handling of the USB video camera bus. The idea was to support multiple different cameras and formats here.
  • Telemetry module: In this module, we collected all the additional data we had – current battery consumption, remaining battery time, GPS coordinates, sd card storage, etc.
  • h.264 decoding module: This module’s main functionality was to transfer video frame data in a different format. For example, we supported h.264 frames, png, and jpeg formats. The application was intelligent enough to decide when to switch between the different formats.

We used Java and C++ programming languages for the implementation of all the modules. The only C++ part was the USB camera module because of the low-level communication with the USB bus. 

Let me share some notes on why we decided to use an Android device. We could implement our body camera system using an ARM-based board with Linux installed on top of it. It would dramatically reduce our software efforts. However, from a hardware point of view, most ARM-based boards lacked good CPUs, battery support, and housing. Not to mention, the development of a custom ARM board was entirely outside of our budget. Fortunately, our software was designed this way, so we could easily switch the hardware platform in case of investment or more considerable client interest.

In conclusion, our body camera system managed to fulfill our initial requirements for MVP. It worked well, and we made multiple videos and streams testing it in various environments and locations. Our system even managed to send data through 3G mobile cells in areas where LTE/4G was not supported.

A sample video of how the system works could be found here

Some photos of our POC build. With that build we managed to fulfill our requirements.