STEAM DOCTOR

Demo

Steam Doctor is a disinfection chamber designed to provide steam powered sterialization for people in public places. It also has audio/visual output features.

In this project I was responsible for design and development of the firmware that operates the system.

Requirements:

  The system is required to have the following properties:

• Detect human presence.
• Output audio feedback through speakers to notify the user about status and/or call to action.
• Take user’s temperature.
• dispatch sterilising steam.
• Read user’s proximity inside the chamber.
• Output Text on two LCD screens (8x2 and 16x4).
• Detect Water level inside boiler
• Auto fill the boiler from disinfectant solution container.
• LED lights for visual status feedback.
• Output Error Messages (audio/text/LED).
• Auto disperse steam every x seconds to get rid of any condensation.

Workflow:

The basic workflow of the machine is as follows:

• The user enters into the chamber.
• Machine Greets Him (audio and on the screen).
• User is asked to get closer in order to take temperature.
• After taking his temperature, machine will output feedback about his temperature (Normal, or High)
• Steam is released for x seconds.
• Output thank you feedback.
• Wait for next user.

This workflow is running infinitely, and during this flow the machine is always self monitoring to look for any issues and respond accordingly. For instance when water level inside the boiler drops below a certain threshold, the machine checks the water level inside the main solution container, and then check if it has enough solution to refill the boiler.

Challenges:

  When you think about the system requirements, it might sound easy to implement. I mean indeed, the system requirements could be simply described as collect a bunch of data from various sensors, send output to screens, play audio through speakers and open/close some valves. Pretty simple, what could go wrong? apparently, many things.. I wouldn’t consider myself to be an advanced embedded systems engineer, however, I always have managed to get around projects using my software skills, in addition to my partner’s electronics skills. However, this project, is much more complex and delicate than any other similar project I have worked with, for the very fact that it has some dangerous properties which could lead to serious damage if not controlled strictly. I could ramble and go into a lot of details just describing the challenges that I have faced while working on this project, but that would really make this post extremely long, so I will only about the one I found to be most challenging to me (feel free to reach out if you would like to have some discussion about it).

The single most challenging issue about this project I would say is Writing the whole system to run in non-blocking mode, i.e no delays are allowed (I did use some but maybe or two for very short duration), however, the machine is controlled using an ATMega256 micro-controller, meaning the whole system is to be run synchronously on a single thread. I would say this was the most critical challenge of the whole project and the reason for this is that there are two thermostats to be controlled while the system is running to make sure that boiler would never go above or below certain temperature and pressure thresholds, so imagine if the system in a state where the thermostats are ON and something block the execution thread. This could lead to really serious damages. There are safety valves installed on the boiler of course, but I have learned that I should take nothing for granted when working with hardware, because it can fail unexpectedly, one of the main reasons I dislike embedded systems projects.

Also at the time of building the project, there was an open issue with a core arduino library wire.h that had been open for more than 9 years! This library is used by the sensors which were communicating over i2c. The issue was that in case of a problem during transmission of the data, the system will block, not just the sensor that cause it, the whole arduino code will hang forever until manual reset. Thankfully, I found another library that implement a timeout behaviour to mitigate that, but this wasn’t ideal because any libraries that were relying on wire.h had to be changed into the new one, and every time there is an update for say the LCD library, it had to be modified manually. Luckily though just before handing over the project, the arduino wire.h library patched a fix, and we switched to that.

Techniques used to mitigate this challenge:

• Avoid using delay() and revert to using mills() which is a way to fake asynchronous execution on a single threaded micro-controller.
• Use watchdog timer as a safety fallback for when the system hangs if an error occur at the i2c bus.(which happened few times in testing)
• We also decided to use a second micro-controller chip to monitor the temperature and pressure inside the boiler and shut the system off in case of an emergency. However,this didn’t make it to the MVP).

Things I would do differently

During the initial phase of system design, I realised that this system is a perfect candidate for a state machine design pattern. However, my C++ skills are a bit rusty and I was behind a very tight deadline for the MVP handover and I didn’t want to risk breaking the contract, so I wrote a simpler code. However, I’m totally certain that a state machine would have made things much much easier to maintain, debug and understand.

Results:

The MVP was delivered successfully and I learned a ton of things from it, however, there is a huge risk involved with such product (again I’m not a embedded systems expert nor I aspire to be one). Also, I believe that this project is definitely not a good fit for a freelance to take into production because many domains and stakeholders need to be involved (firmware engineers, electronics engineers, testing, product designer, legal, safety engineer, etc..), and the client had nothing close to that nor was showed a will to do so, so eventually after the handover of the prototype, I decided to not proceed any further with it.