Weeknotes project image

Weeknotes: personal reflections from the ODI research team. Keeping you informed about our projects, research and decision-making processes. By Rachel Wilson, Senior Software Developer

This week we have been leaning about the 'weeknote' format and making decisions about process and tools for creating and documenting our Digital Twin prototype.

This week's activities

  • Learning about the 'weeknote' format
  • Unpacking the Samsung Open Source Group's existing work on connected sensors
  • Making decisions about about my process and tools
  • Researching hardware

This week's observations

  • Weeknotes don't have a template format
  • Inheriting other people's work doesn't come for free, but it does accelerate learning
  • Clarity about the use case is crucial to save prototyping costs - which includes research time

Bootstrapping the weeknote format

The first thing is to figure out how one writes weeknotes.

Reading about their history and intention (see also), and listening in on some other people's efforts reveals that there is no template format. Some read like diaries – prose or bulleted – some read like retrospectives; some are brief, some are long; some are very personal, others are entirely project-work based.

Given what I'd like to communicate, and given that these notes may be compiled into another project output, I'm going to break mine into sections:

  • tl/dr section summarising the week's main activities and observations
  • main body of prose focusing on lessons learned
  • lots of pictures.  I may have to buy a camera!
  • some reflection about where this lessons from this week will take me next
  • a digest reading list
  • a personal sign off maybe?

The format will probably evolve - feedback welcome.

Thank you to Samsung Open Source Group

During our discovery phase we were lucky enough to collaborate with the Samsung Open Source Group, who have produced a working digital twin of lighting, temperature and humidity sensors in a house. The code is all open source, and their efforts have been openly documented.

I'd like to be able to replicate and build on what they've done, and there's a lot to untangle in this bundle of code and documentation. So far I've identified that it includes

  • Libraries to take sensor readings and send them to a central visualisation and control "gateway"
  • Adapters - are these sensor adapters for the raspberry pi?
  • The gateway is provided by Mozilla Gateway - a service/tool to monitor and control IoT "things", including HTTP APIs to read the sensor data
  • A visualisation in virtual reality (snazzy!)

More on the Samsung Open Source Group and contents of this project in a future weeknote. This week has mostly been an exercise in understanding the components and vocabulary.

Thinking about my process and tools

  • I've blocked out some writing time every week, but because of other project commitments I won't commit to a weeknote per week – but roughly once a week, at least once a two-week sprint
  • Normally we write everything in Google Docs, which facilitates collaborative writing and reviewing.  But given this will be a solo endeavour I'd like my weeknote musings to be closer to my personal offline research notes. I am experimenting with note taking tools, currently Evernote. So I'll try that for now and see how it goes.
  • I need to discuss with the team where and how to publish these on the web (if you're reading this I guess we decided)
  • I don't think I need any other tools for now other than hardware and related software development environment, which will come next week.

Buying Researching some hardware

I was planning to order the same hardware as used by Philippe Coval, but I'd noticed that the IoT Gateway and the sensor readings + micro-controller functions were running on the same Raspberry Pi. I think it would make it clearer to demonstrate, and explain, the technology if the micro-controllers and gateway were housed in different physical objects and communicating at a distance.

Arduino is an obvious open source choice. However, this opens up a host of Arduino model options, the numbers of which has exploded since I last dabbled – which to get? Will the sensors that Philippe uses also work on the Arduino?  My, there are a lot of different temperature sensors out there!

I'd rather only use sensors that are relevant to the energy/buildings case study we're planning to explore.  We need to be more sure of the use case and scenario. We're speaking to some experts  next week so I'm going to hold off buying anything for now and research the options once I'm clearer about the use case.

Dusting off the Arduino books

I did some tinkering with Arduino many years ago, but it was pretty basic and may be out of date. But a quick look at more recent Arduino code and tutorials reassure me that the principles of the technology haven't changed.

Reading List

Reflections

  • I enjoyed writing this weeknote. It worked both as a process to clarify my thinking, and as a planning aid
  • Clarity about the use case is crucial to save on prototyping costs – and that includes research time.  I'm looking forward to speaking with the experts next week.
  • I have a lot to learn before I can compare open source technology choices (and i have already encountered a lot of them) with industrial technology

This week I am powered by: New beginnings Thank you to: Philippe Coval and Ziran Sun for their inspiration and generosity.