|
|
|
# Contents
|
|
|
|
|
|
|
|
* [About this project](#About_this_project)
|
|
|
|
* [Roles and Workloads](#Roles_and_Workloads)
|
|
|
|
* [Challenges](#Challenges)
|
|
|
|
* [Achievements](#Achievements)
|
|
|
|
* [Researched technologies](#Researched_technologies)
|
|
|
|
* [Used technologies](#Used_technologies)
|
|
|
|
* [Architecture](#Architecture)
|
|
|
|
* [Roles and Workloads](#Roles_and_Workloads)
|
|
|
|
* [Results](#Results)
|
|
|
|
* [Game views](#Game_views)
|
|
|
|
* [gRPC](#gRPC)
|
|
|
|
* [Bluetooth beacon](#Bluetooth-beacon)
|
|
|
|
* [Gitlab CI](#Gitlab_CI)
|
|
|
|
* [Manuals for individual components](#Manuals_for_individual_components)
|
|
|
|
* [Attachments](#Attachments)
|
|
|
|
|
|
|
|
## About this project
|
|
|
|
|
|
|
|
In short, VirtualFriend project is a system hosted in hospital environment to reduce fears of children that are visiting doctor for short duration, Aproximately two hours.
|
|
|
|
In short, VirtualFriend project was a system hosted in hospital environment to reduce fears of children, that are visiting doctor for short duration. The target stay we decided was aproximately two hours.
|
|
|
|
|
|
|
|
VirtualFriend idea is brainwork of one and only Marko "Narsu" Rintamäki, who wanted to have a living environment for kids when they stay at hospital. Original idea had the kids that have to stay longer, often and sometimes overnight as a main target group, but that was changed during the project to kids who are don't go so often and stay aproximately two hours.
|
|
|
|
VirtualFriend idea was brainwork of one and only Marko "Narsu" Rintamäki, who wanted to have an living environment for children when they stay at hospital. Original target group consisted of children, that have to stay longer, often and sometimes overnight, as a main target group, but that was changed during the project. We decided that our new target group would consist of children, that do not have to stay for too long and don't visit that often, we decided that two hours was good length of the visit
|
|
|
|
|
|
|
|
Idea was to "create a game like environment, where the environment reacts to kids presence in some way". Technologies given were RuuviTag and Raspberry pi microcomputers
|
|
|
|
Idea was to: "create a game like environment, where the environment reacts to kids presence in some way". Technologies given were RuuviTag and Raspberry pi microcomputers
|
|
|
|
|
|
|
|
Some initial ideas based on conversations between Marko and Rami included Lemmings like view where many players would simultaneously view their virtual friends on the screen where they would do stuff together with other virtual friends, Other ideas were enliven screens that didn't have game like components but were meant to distract kids.
|
|
|
|
Some initial ideas based on conversations between Marko and Rami, included Lemmings like view where many players would simultaneously view their virtual friends on the screen. Virtual friends would play and do things together with other virtual friends. Other ideas were enliven screens that didn't have game like components but were meant to distract kids from fear.
|
|
|
|
|
|
|
|
## Roles and Workloads
|
|
|
|
|
|
|
|
|Name|Role|LinkedIn|Technologies|
|
|
|
|
|-|-|:-:|-|
|
|
|
|
| Rami Ojala | Team Leader | [Link](https://www.linkedin.com/in/raojala/) ||
|
|
|
|
| Joona Hautamäki | Junior Software Developer | [Link](https://www.linkedin.com/in/jotahau) ||
|
|
|
|
| Aku Karttunen | Junior Developer | [Link](https://www.linkedin.com/in/aku-karttunen) ||
|
|
|
|
| Mika Tuoriniemi | Junior Software Developer | [Link](https://www.linkedin.com/in/mika-tuoriniemi) ||
|
|
|
|
| Konsta Mustonen | Junior Software Developer | [Link](https://www.linkedin.com/in/konsta-mustonen) ||
|
|
|
|
| Santeri Suihkonen | Junior Software Developer | [Link](https://www.linkedin.com/in/santeri-suihkonen/) ||
|
|
|
|
| Pinja Ylönen | Wellness Technology Consultant | [Link](https://www.linkedin.com/in/pinja-ylonen) ||
|
|
|
|
| Kasper Syri | Junior Developer | [Link](https://www.linkedin.com/in/kassyri) ||
|
|
|
|
| Carita Tammelin | Junior Software Developer | [Link](https://www.linkedin.com/in/caritatammelin) ||
|
|
|
|
| Teemu Tikkanen | Junior Developer | [Link](https://www.linkedin.com/in/teemutikkanen) ||
|
|
|
|
| Aarni Ylhäinen | Concept artist, Illustrator, Animator | [Link](https://www.linkedin.com/in/aarniy) ||
|
|
|
|
| Sasu Karvonen | Concept artist, Illustrator, Animator | [Link](https://www.linkedin.com/in/sasu-karvonen-07129a163?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base_contact_details%3ByPgU9gstQiqrqeBYav%2Bl4Q%3D%3D) ||
|
|
|
|
|
|
|
|
## Challenges
|
|
|
|
|
|
|
|
Initial challenges were finding technologies that worked together and on top of ARM. First spring and half of the second sprint went researching game tech that would run on Raspberry Pi 3. After 3 weeks of figthing we decided that Raspberry Pi 3 just wasn't the right technology for the job and Rami salvaged old computers from JAMK garbage.
|
|
|
|
Initial challenges was finding technologies that worked together and on top of ARM. First and half of the second sprint, was used to research game technology, that would run on Raspberry Pi 3. After 3 weeks, we decided that Raspberry Pi 3 just wasn't the right technology for the system and Rami salvaged old computers from JAMK SER-garbage.
|
|
|
|
|
|
|
|
After the Raspberry Pi 3 choke point was solved, we decided on technologies for the game views and we went with Monogame, because our development environment was on Ubuntu 18.04.
|
|
|
|
After Raspberry Pi 3 choke point was solved, we decided on technologies for the game views and we went with Monogame, because our development environment was on Ubuntu 18.04.
|
|
|
|
|
|
|
|
RuuviTag programming was done with Python from the start because that was the code our RuuviTag programmers were familiar with.
|
|
|
|
|
|
|
|
Rami wanted to integrate gRPC to communicate between all the game views and python, because gRPC has support for so many different languages and they can communicate together and he saw that this technology would be usefull for everyone in the future.
|
|
|
|
Rami wanted to integrate gRPC to communicate between all the game views and python, because gRPC has support for so many different languages which can communicate together. Another reason was that Rami saw this technology to be usefull for everyone in the future.
|
|
|
|
|
|
|
|
Monogame Unit testing proved to be difficult since the reference material was pretty much non-existent and anything that required monogame game component could not be tested.
|
|
|
|
|
|
|
|
## Researched technologies
|
|
|
|
|
|
|
|
* Godot game engine
|
|
|
|
* Phaser.js game library
|
|
|
|
* Phaser editor
|
|
|
|
* Electron
|
|
|
|
* gRPC
|
|
|
|
* Python
|
|
|
|
* Monogame C# game framework
|
|
|
|
* Node.js
|
|
|
|
* Sonarqube and Sonarscanner
|
|
|
|
* Gitlab runner
|
|
|
|
* Docker
|
|
|
|
* Jest
|
|
|
|
* Nunit
|
|
|
|
* PyUnit
|
|
|
|
|
|
|
|
Monogame Unit testing proved to be difficult and undocumented project.
|
|
|
|
## Used technologies
|
|
|
|
|
|
|
|
* Monogame C#
|
|
|
|
* gRPC
|
|
|
|
* Python
|
|
|
|
* Node.js
|
|
|
|
* Gitlab runner
|
|
|
|
* Sonarqube
|
|
|
|
* Sonarscanner
|
|
|
|
* Nunit
|
|
|
|
* Jest
|
|
|
|
* PyUnit
|
|
|
|
|
|
|
|
## Architecture
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Achievements
|
|
|
|
## Results
|
|
|
|
|
|
|
|
We managed to make a working concept demo for open doors, which was developed inside a week after getting our technology stack to work.
|
|
|
|
|
|
|
|
During our time in WIMMA Lab we were able to create several different game like views for the concept and the whole stack is functioning inside a closed network.
|
|
|
|
|
|
|
|
## Researched technologies
|
|
|
|
### Game views
|
|
|
|
|
|
|
|
Godot game engine, phaser.js, Phaser editor, Electron, gRPC, Python, Monogame, Node.js.
|
|
|
|
We started this project with the presumption, that we would be using Godot game engine for couple of different reasons. First, our development environment was on top of linux. Second we wanted to use C#, because that was the language majority of us were familiar with.
|
|
|
|
|
|
|
|
## Used technologies
|
|
|
|
After fighting with Godot and ARM for a while and not getting them to work together, we moved on to Phaser.js and Phaser editor. We were able to get tutorial games to work from Raspberry pi 3 chromium. There were major performance issues, because Chromium was eating a lot of resources.
|
|
|
|
|
|
|
|
Monogame, gRPC, Python, Node.js
|
|
|
|
Narsu threw us an idea "Could you remove the browser underneath it?" and Rami remembered Electron framework which did just that. We were able to make the system work as intended in our development environment with these technologies, but gRPC and Electron did not build properly to ARM and views were barely working on Raspberry pi 3.
|
|
|
|
|
|
|
|
## Architecture
|
|
|
|
After we decided that Raspberry pi 3 was a no go, we went directly to monogame, since Godot had other issues and we were running out of time for open doors. Everything started working a lot better, after we removed the choke points from the system, we were able to make a basic demo in a week and it was done just before open doors.
|
|
|
|
|
|
|
|
|
|
|
|
After the open doors was over, we used the demo as a template for our other views. We were able to create following views: Fruit catching, Daycare, Dressingroom, Birdfeeding (not finished), Fishing game and Racetrack game.
|
|
|
|
|
|
|
|
## Roles and Workloads
|
|
|
|
We used Nunit to unit test what we could, but we couldn't find proper reference material and our unit tests were left lacking.
|
|
|
|
|
|
|
|
|Name|Role|LinkedIn|Technologies|
|
|
|
|
|-|-|:-:|-|
|
|
|
|
| Rami Ojala | Team Leader | [Link](https://www.linkedin.com/in/raojala/) ||
|
|
|
|
| Joona Hautamäki | Junior Software Developer | [Link](https://www.linkedin.com/in/jotahau) ||
|
|
|
|
| Aku Karttunen | Junior Developer | [Link](https://www.linkedin.com/in/aku-karttunen) ||
|
|
|
|
| Mika Tuoriniemi | Junior Software Developer | [Link](https://www.linkedin.com/in/mika-tuoriniemi) ||
|
|
|
|
| Konsta Mustonen | Junior Software Developer | [Link](https://www.linkedin.com/in/konsta-mustonen) ||
|
|
|
|
| Santeri Suihkonen | Junior Software Developer | [Link](https://www.linkedin.com/in/santeri-suihkonen/) ||
|
|
|
|
| Pinja Ylönen | Wellness Technology Consultant | [Link](https://www.linkedin.com/in/pinja-ylonen) ||
|
|
|
|
| Kasper Syri | Junior Developer | [Link](https://www.linkedin.com/in/kassyri) ||
|
|
|
|
| Carita Tammelin | Junior Software Developer | [Link](https://www.linkedin.com/in/caritatammelin) ||
|
|
|
|
| Teemu Tikkanen | Junior Developer | [Link](https://www.linkedin.com/in/teemutikkanen) ||
|
|
|
|
| Aarni Ylhäinen | Consept artist, Illustrator, Animator | [Link](https://www.linkedin.com/in/aarniy) ||
|
|
|
|
| Sasu Karvonen | Consept artist, Illustrator, Animator | [Link](https://www.linkedin.com/in/sasu-karvonen-07129a163?lipi=urn%3Ali%3Apage%3Ad_flagship3_profile_view_base_contact_details%3ByPgU9gstQiqrqeBYav%2Bl4Q%3D%3D) ||
|
|
|
|
### gRPC
|
|
|
|
|
|
|
|
Original idea was to use C++ or Go for the gRPC programming, but after the gRPC was left solely to Kasper, he decided it would be best to use Node.js.
|
|
|
|
|
|
|
|
gRPC was pretty much done after the first sprint. There has been updates to the protobuf message during these 5 sprints and updates have been made.
|
|
|
|
|
|
|
|
Jest was used to unit test 78.7% of the code in gRPC.
|
|
|
|
|
|
|
|
### Bluetooth beacon
|
|
|
|
|
|
|
|
RuuviTag was used as a beacon for our system. RuuviTag was also used as an input device, based on Tilt, Shake or Acceleration.
|
|
|
|
|
|
|
|
All the programming was coded using python and the scripts were unit tested using PyUnit framework.
|
|
|
|
|
|
|
|
There were some problems using eddystone firmware on RuuviTag. Eddystone firmware doesn't send any accelerometer data (neither does Ruuvi firmwares URL mode) and initially we weren't able to use a single RuuviTag to handle all the inputs and we had to ducktape two together. This was later fixed by Mika and Aku as they found a proper firmware that would work with all the necessary inputs.
|
|
|
|
|
|
|
|
We were forced to use many different python 3rd party libraries to get all the functionality we wanted and we needed to use two different bluetooth interfaces to achieve the best performance. We also modified Ruuvi firmware to make it send data more frequently and that's why we used two different bluetooth interfaces together, different data each, other for RSSI value and the other one is used to collect sensor data, this is achieved in a single script.
|
|
|
|
|
|
|
|
### Gitlab CI
|
|
|
|
|
|
|
|
We had Gitlab CI set up the way that it would run unit tests automatically with each push. Sonarqube was also set up to run code analysis on each branch, as they were pushed
|
|
|
|
|
|
|
|
## Manuals for individual components
|
|
|
|
|
| ... | ... | @@ -74,6 +136,7 @@ Check this projects [Technical documentation](https://gitlab.labranet.jamk.fi/Io |
|
|
|
* [Monogame](https://gitlab.labranet.jamk.fi/Iotitude/Virtuaalikaveri/wikis/monogame-setup-guide)
|
|
|
|
* [Python RuuviTag integration](https://gitlab.labranet.jamk.fi/Iotitude/Virtuaalikaveri/wikis/python-ruuvitag-integration)
|
|
|
|
* [gRPC](https://gitlab.labranet.jamk.fi/Iotitude/Virtuaalikaveri/wikis/grpc-manual)
|
|
|
|
* [Gitlab CI]()
|
|
|
|
|
|
|
|
## Attachments
|
|
|
|
|
| ... | ... | |
| ... | ... | |
