Recently an undergraduate student came to me with an idea for his final course project, a hardware project for a fatigue detection system for use in automobiles.
The idea is basically to use a camera attached to the windshield that would track the driver’s eyes and if the eyes are closed for more than 1 second, an audible alarm would be triggered.
He was excited about the idea and would carry out this project with the Arduino, as he already had a kit and was already familiar.
He even imagined that if successful, this could be a prototype of a low-cost commercial project.
Well, I Started to Raise Some Points that he hadn’t thought about:
- Would one camera be enough? If the driver is on a curve and his head is not necessarily directed towards the front camera, maybe 3 cameras are needed;
- The camera (or cameras) should be able to work in low light so that it can be used at night;
- If the driver wears glasses, the solution should be able to identify the eyes even over glasses;
- Would just closed eyes indicate actual fatigue? I have already driven with sleep and often your eyes are open, but your peripheral vision is greatly altered by the effort you make to keep your eyes open;
- And probably the most important, the Arduino platform would be able to handle these situations and would it have the necessary performance? Imagine that you would have to identify the driver’s face, eyes and, in the case of identifying the closed eye, you would have to trigger the alarm in a very short time (in the next second). Another important point is the support for SDK as OpenCV that I honestly don’t know if it supports or is supported by Arduino.
After reading the above, you should imagine what I intend to write next.
Often in the anxiety of realizing a dream/idea, we seek to go straight to the implementation on the hardware platform that we have mastery or that we have at hand and this would not always be the correct flow, especially for projects with commercial aspirations.
In a commercial project, we have several factors that must be considered, such as the final cost of the solution, estimated amount of sales, among other commercial factors that impact the definition of the hardware architecture and the commitments that will be assumed in this step.
In my view, every project of a hardware system must begin with the evaluation: to meet the objective.
I can use a software solution in a generic processor or I need a customized hardware solution (Microcontroller, CPLD, PIC, FPGA, ASSP, ASIC, SOC, PSOC, etc.), platforms such as Arduino and Raspberry are excellent and have the merit of popularizing the DIY maker culture relatively easily and with little expense, but they are not always suitable for all needs.
If we look at the market, for example, the FPGA did not kill the development of customized ASICs, although the development cost using an FPGA (NRE – Non-Recurring Engineering cost) is relatively low, we have some challenges, such as performance (time closure), consumption (power) and the recurring cost (each FPGA unit tends to be more expensive than an ASIC).
Returning to the world of embedded systems, the first and most sensible point to consider is to assess whether the objective can be achieved using software in conjunction with generic hardware (PC, industrial PC, Mini PC as Raspberry or Microcontroller / PIC as Arduino).
If you need hardware acceleration, first perform a search and search for ASSP’s (Application Specific Standard Product), SOC’s, etc.
Finally, if you don’t have what you need in the market, evaluate the customization of hardware, with the initial focus on the FPGA and lastly an MPGA / SOG solution (practically dead) or ASIC (the latter being justified only when the product is estimated final unit has a volume of units produced in the thousands).
Concluding this article and the history of fatigue detection, it would probably be possible to implement using OpenCV with Raspberry and perhaps some acceleration via Hardware (FPGA, Brainard) specifically for pattern recognition, in this case, the driver’s eyes in the hundredths of a second