Hardware Selection and Software Optimizations

Introduction

As the world moves ever forward to smaller embedded systems, the difficulty of selecting the right hardware for the job becomes increasingly difficult. Our RAPID software is built to run on Mini PCs within a towing or trucking vehicle. As a result, they need to be ruggedized to handle the extremes possible within this environment ranging from freezing to incredibly hot temperatures as well as withstanding any bumps and bruises they may receive during normal operating conditions and potential snow/water entering the cabin. We do as much as we can to mitigate potential external environmental conditions such as water and temperatures by mounting our hardware in a secure box within the vehicles as well as selecting cases for our hardware that meet our requirements for environmental conditions. Some difficulties that come with these requirements though is finding the hardware that can run our software as well as meet the conditions demanded by the environment. As such we need to make a few sacrifices in terms of hardware power, meaning we need to do some optimization on the software side to meet our customer’s requirements for features.

Hardware Selection

Determining viable hardware for our use-cases is difficult due to the necessity of keeping cost low per unit, but still being able to handle all of RAPID’s features. The biggest to manage features of RAPID is local video recording and video streaming. As such we decided to pick our hardware mostly based on how well it can handle these two features since the other RAPID features are relatively lightweight such as GPS location management, and accelerometer data reading. Our requirement for managing the video streams is the ability to record locally from at least 4 cameras concurrently as well as support live video streams from each of those cameras. So to manage that we decided to look into multithreading as our potential biggest source of optimization. As such, we needed to look into hardware that had robust threading support which is almost any respectable CPU nowadays, but that didn’t make the search easy. Just because the CPU has robust multithreading support we needed to track down and test hardware that had enough cores and processor speed to manage the camera threads. Here are a few examples from that blog of some processors we tested using a specific camera setup at 480p and 10fps.

CPU Downscaling Enabled

CPU # of concurrent streams supported Avg. CPU Usage per thread (depending on load from other applications)
i7-8700T 2.4GHz 6 Core 4 ~25%
i5-4200U Dual Core 1.6GHz 1 50-80%
Celeron J3160 Quad Core 1.6GHz ~1 70-110%
 

CPU Downscaling Disabled

CPU # of concurrent streams supported Avg. CPU Usage per thread (depending on load from other applications)
i7-8700T 2.4GHz 6 Core 8 ~5%
i5-4200U Dual Core 1.6GHz 4 10-15%
Celeron J3160 Quad Core 1.6GHz 4 15-20%
As you can see clock speed has a large effect on how well the CPU manages concurrent video streams so we needed to make sure that our CPU was cost-efficient as well as performant. We settled on using the Celeron due to its handling our streams well enough to fit our parameters but also less than half the price as the i5.

Software Optimizations

As we have covered in previous blogs, we investigated a few different hardware options before deciding on hardware that meets our specific use cases. Our goal for RAPID was to be able to offer at least 4 concurrent video streams from the device at any given time so when looking at hardware options we had to keep that in mind. We made a few optimizations to support the amount of camera feeds that our hardware could support. One of them was to use multithreading to support each camera being managed by its thread, thus one camera will not be waiting to submit its data because the CPU is managing data from other cameras.  As you can see using the lower-cost hardware-the i5 and the Celeron-it became possible for us to support our target of 4 concurrent streams as well as everything else RAPID has to do simultaneously by doing some management of the raw data streams from cameras themselves. This was not the only thing we did to optimize our software though, we can use multithreading to handle the camera feeds as well as RAPIDs other features which further increases our performance.  We utilize multithreading throughout RAPID as a simple source of optimization. For example, each camera connected records its video and images via its designated thread. Meaning we can handle multiple concurrent camera feeds without any slowdown, similarly each video stream is managed by its thread which is created when the stream is requested. RAPID also uses threads for each of its internal services such as location, event, and accelerometer management.

Fleet Management Framework

Rapidly build better fleet & asset apps, with less code.

Blog Author:

Subscribe

Sign up for our Newsletter and stay up to date on the latest at ESG USA.  New blog posts, newsletters, case studies, and more.