I'd like to start by thanking all the community members who have participated in the element14 community's InnOvaTors project, including shabaz, dougw, Workshopshed , Instructorman, beakersbro, Blacksheep32, beacon_dave, Robert Peter Oakes, balearicdynamics, pihaume and rogerpena. I realize you all are very busy people so I appreciate your participation. Your input has a lot of value here at element14. Thanks again.
If you haven't had opportunity to participate, let me recap the InnOvaTors Project:
What is the element14 InnOvaTors Project?
The goal of the InnOvaTors project was to solve a problem, just like you would do on your day jobs as engineers, developers, coders, consultants, etc. The problem to solve for this project was how to use IoT technology to develop a product that would protect a stroke patient who lives alone at home and has a tendency to lose her balance and fall. We proposed this scenario to (A) get insights into the IoT product development and brainstorming process, and (B) to provide useful feedback to the IoT vendors we support so they can better serve the needs of the engineering and developer communities.
If you are still interested in participating, feel free to visit the element14 Internet of Things space and click on any of the Help Us Put the IoT in Innovation links: Part 1, Part 2, Part 3 or Part 4.
What Did We Learn from the InnOvaTors Participants?
For simplicity, we split the InnOvaTors project into four parts. Starting with workflow processes (Part 1), we then progressed to sensor node design (Part 2), followed by gateway design (Part 3), and, finally, cloud platforms (Part 4). The participants offered ideas, opinions and advice, just like they would do on the job. There were some lively conversations throughout the 4-part project, so I encourage you to read them.
Like most other projects, this one required some thought about planning, organization and scoping. Developing a home healthcare IoT product is not necessarily an easy task. So an overall plan, requirements gathering, and work flow priorities were discussed first. Researching the current market (Workshopshed) for similar products and sharing them with the other participants was a good springboard for discussion. As noted, IoT-related healthcare devices have already been developed. Clearly, the demand for them is growing and that's why we chose to focus on this type of product for the InnOvaTors project.
We also learned that you could approach the problem in two ways: you could monitor the space or monitor the patient's movement within the space and look for daily pattern anomalies. Monitoring the activity in the space instead of the patient's movement within it was a surprising suggestion. In the end, most of the participants leaned towards monitoring the person's movements via a wearable sensor although the other approach may be worth investigating.
There was also a brief discussion on whether an IoT product would be an appropriate solution for this problem. For instance, beacon_dave framed the problem using both reactive (non-IoT) and proactive (IoT) approaches. As the InnOvaTors project moved to a technical discussion of the node, the opinions started flying and the intensity of the discussion ratcheted up a few levels. A discussion of the types of movements that needed to be sensed was a hot topic of discussion. The next subject was the use of a wearable device. Not everyone agreed that a wearable device was viable. "I would be super-inclined to do as much as possible passively or without wearables, to try and reduce patient error (e.g. forgetting to wear a device)," said shabaz.
There were two other interesting discussion points concerning the nodes: (A) how much intelligence should the node have in order to do more processing close to the patient and (B) the need to utilize sensor fusion generated by several types of sensors in order to build a complete picture the the patient's physical movements.
Three types of wireless connectivity technologies were also considered for the node: sub-1GHz wireless for short range, WAN connectivity for long range, and 4G/LTE because normal mobile phone could be used [by the patients]. dougw also suggested the Open Beacon RFID tracking system for location tracking. Cellular connectivity came up several times in the discussion, but there was some concern voiced by beacon_dave regarding the loss of cell service during power outages impacting the reliability of the IoT device.
The discussion about the gateway got a little fuzzy, which I expected because brainstorming is about possibilities and not necessarily certainties.The use of smart phones and robots were part of the mix. beacon_dave did some research and said that Omron Healthcare already has a Bi-Link Gateway that uses NFC and USB to transfer a patient's vitals data to Omron's Health Management platform in the cloud. This seems to be the trend since building your own cloud infrastructure and applications is such an onerous task. Utilizing cameras for remote assistance was another idea tossed around in the discussion.
What's Your Preference: Dev Boards or IoT Dev Kits?
The other goal of the InnOvaTors project was to gather feedback on the current generation of IoT development tools for the benefit of element14's product vendors. As far as dev boards go, Robert Peter Oakes recommended "using the TI BOOSTXL-SENSHUB via a sub GHz radio to a local hub connected to the Internet to alert response teams or a cell module to call instead." This is a great idea. I did some research and found other dev boards that could be useful in developing home healthcare IoT products. Here they are with a few salient specs:
| Warp7 | RiotBoard | TI LaunchPad | Intel Edison |
|---|---|---|---|
 |  |  |  |
|
|
|
|
Have you used any of the above dev boards? Would you consider using these for a project like the one described in the InnOvaTors project? If not, what do they lack and what could be added so they would be a great dev tool for this type of project? If you have the time, please offer your thoughts below in the comments.
Some of our vendors are beginning to provide "turn-key" IoT dev kits instead of only dev boards. I did some research on these kits and put them in the table below:
| Sierra Wireless mangOH Starter Kit | ARM IBM-Mbed IoT Starter Kit | BeagleBone Black IoT Solution Kit | element14 IoT Learner Kit |
|---|---|---|---|
 |  |  |  |
| mbed Enabled Freescale K64F
mbed Application Shield
|
|
|
It seems like offering IoT dev kits will be the trend, rather than only the dev board alone. The most obvious advantage of the kit is time and cost savings. But these kits run the gamut from the Sierra Wireless mangOH kit which has everything you need to provide an end-to-end IoT solution to the BeagleBone Black IoT Solution Kit, which provides the basics. Would you be more inclined to look for a turn-key IoT dev kit over simply the dev board? Do these kits offer you what you need to start building a product like the home healthcare monitor that was discussed in this InnOvaTors project?
If you have the time, please offer your thoughts in the comments.
Top Comments