Technologies for Connectivity

Course reflection

For this course I set out to Improve my skills in programming by gaining experience and learning to work with API’s and the esp32 module. In combination with that I wanted to implement some meaningful interaction into the design of our module.
My contribution to the module has mostly been in terms of the design of the module. During the second challenge I handled most of the communication with other groups and I worked on building the level.
Despite my wish to do a lot of programming I did not come around to that. Within the team we had a rather clear division of tasks, so I stayed away from most of the programming side. During the testing and preparation of our level I did help out with the level controller and the changes we needed to make to the module code and API.



The brain of our module was the esp32 microcontroller. I believe it is a very suitable microcontroller if you want to make connected products as the esp32 has a WIFI chip on board.
The drawback of using the esp32 was the board is relatively new and some libraries are not supported jet, this complicated the design of our module quite a bit.
Even though I did not work with code a lot I did have a look at the code in order to test it and work on the level. This made me go through the hassle of installing the esp32 on my computer. This is surprisingly more complex then with other boards.
Going through this process gave me the confidence, and presumably skill level, to use it in future projects. I have a number of projects in mind that would be suitable for an esp32.

API design

The API we made for the KIWI was rather complex and it had a lot of different parameters that could be set. At first the API also worked differently then I expected and there was a mis match between how our level controller worked and how the KIWI worked.
We resolved this problem and at the same time improved the KIWI API and made it easier to use for the other group that used it. Their level controller work in a similar fashion as ours.
I do have a basic understanding of how to write and implement and API, although this knowledge does not extend beyond OOCSI. The basic know how will definitely come in handy in future projects but I will have to learn the specific API of the products and communication tools used.

Meaningful interaction

It would be a bold claim to say that the KIWI incorporates meaningful interaction, it does feature a level of feedback, but that is about it.
Despite that, a lot of time went into the design of the KIWI’s physical form. The fist iteration had the shape and size of a Kiwi egg, hence the name. But because the RFID we initially picked did not work in combination with the esp32 we had to switch to another one that was much larger in size.
For the second version I took the shape and size of all the components in mind a bit better. This resulted in a disc like shape that had the screen on one side and the RFID reader on the other one. The bottom was flat and held an on/off switch and a micro-usb for charging. This made the KIWI a fully stand-alone device that could be used without opening it and touching the electronics inside. It was the first time I designed a prototype in this way and the experience will certainly help the next time.
Even though I did not manage to incorporate meaningful interaction I have learned a lot from designing the KIWI. With the insights I got this time I can hopefully incorporate a level of rich interaction in the next product I make.

The Process

Our group consists of two industrial design students and two software science students. During the group work, it became clear that having knowledge about programming makes communication a lot easier. The new knowledge I gained during this course will be very useful not only when applying it myself but also when working in interdisciplinary teams. It makes it possible to collaborate more efficiently and it enables me to be the intermediary between designers and programmers.

The process we went through, both for the module and the level, resembled a design process. We started with ideating and generating ideas. Out of these ideas we selected the one that we thought was best. In hindsight, it might have been better if we picked a simpler module. The KIWI is rather complex and I think that might have been the reason not many groups wanted to use it in their level.
When we started on the level we were still working on the final version of the KIWI, of which we did two iterations as explained earlier. For the level, we stuck to the idea that we initially came up with as an example of how the KIWI could be used. We sat together to put the level together and decide the storyline, this worked very well.

This has been a very interesting course and it has given me numerous insight on various topics. During the entire course, I did have the feeling we did not enough time. We started quite late with the module, and the level controller concept followed only a few weeks later. This put a lot of pressure on the group. I think we handled this quite well, everyone took up a different part of the design and everything came together in the end rather well. It is a shame that our level did not work entirely but we tried our best to get it working to the final minute.