Understanding the Dynamic Posture on a bike seat using Weight Distribution
Revealing overall postural ride history to a bike rider for preventive self-care
This research study has been conducted under a project on personal informatics, healthcare and HCI. The project is called ReRide. ReRide is a system designed and implemented as a platform exploring the design of personal informatics tools for motorbike commuting and help us conduct an in-situ evaluation of such tools.
This post documents the journey of my research stint at ReRide and arriving at a stable prototype that can be mounted on a bike to collect dynamic posture data.
Earlier Prototype and Research
The earlier prototype of ReRide was demonstrated at INTERACT 2017 held at IIT Bombay and consisted of a wearable which had an angle sensor (the accelerometer) to get the forward and backward lean angle and two FSRs (Force Sensitive Resistor) for suggesting the right and left lean of the rider . It was equipped with a phone display to give feedback related to the rider’s posture based on the data extracted from the sensors. Challenges were faced with Arduino BLE as the Genuino board fell short at handling simultaneous BLE connections from the sensors and the visualisation app suffered due to untimely handshakes and connection latency.
By the time I joined, the team had already taken feedbacks from the physiotherapist about the initial prototypes and gathered information about all the body parts that contribute majorly to a posture and should be taken a note of, while designing the interaction which would gather the rider’s data. Hence we had to come up with an improved and stable prototype which would be easily mountable on most of the bikes and would be more modular in terms of research exploration.
Designing a Stable and Modular Architecture
Once the vision was clear about how the prototype should be and with the information collected from the physiotherapist, we decided to use a camera sensor unit which will help us in posture detection using marker-based image processing (details about the camera program here). Then the problem was to identify the correct force sensors and configuration of the force sensors to extract as much meaningful data as we could which would further be combined with the processed camera data and then we could have most of the major parameters which would then enable us to give the rider certain feedback based on his/her posture.
I went through a lot of literature available online related to posture detection using the weight distribution of a person and after a week of detailed discussions with Naveen (Head of Program HCD at Srishti) and Gaurav (HCD Faculty at Srishti) decided to go with a matrix of optimum number of FSRs. Based on certain relevant research, the number of FSRs was fixed at six with reasonable confidence. The arrangement of the FSRs was to be decided later, by testing the FSRs on the bike itself. Then, as we had to switch from Arduino board, we decided to use Raspberry Pi Zero W which seemed to be a sufficiently powerful micro-controller option. It would also benefit in keeping our codebase mostly in one programming language, i.e., Python.
It took us a week to decide all of this and then we had to decide the higher-level architecture of the platform to design the prototype that we had envisioned. Around the same time Tomas Sokoler joined us and helped us in defining our architecture in keeping it modular and pliable enough for further experimentation. We decided to keep the different sensors in combination with a Raspberry Pi as a smart sensor unit and then the processing unit consisting of another Raspberry Pi alongwith a display feedback for the bike rider. For communication among these smart sensor units, we decided to use Websockets which would help in conveying the sensor data to the processing unit. The backend cloud system would be there for storage and processing using ML models at a later stage.
Electronic Prototyping and Hardware Interfacing
When we decided to go with Raspberry Pi, it was supposed to work well with whatever we had to use but the problem with Raspberry Pi is that it does not allow native serial interfacing with analog devices so you need to have an Analog to Digital converter (ADC) for this purpose. There are many options for this interfacing but we decided to go with the Adafruit ADS1115 16-bit 4-channel converter which supports I2C communication. This interfacing theoretically sounds easy to use and a kind of plug and play thing and should not take much time but we had issues with the Adafruit library for ADS1115 and that took time. After a lot of prototyping and solving the hardware and software issues one by one, I was able to get the FSRs up and running with Gaurav’s help.
When you are dealing with a lot of hardware interfacing simultaneously and that too for the first time on a platform that you are not familiar with, you need to be patient enough to deal with the issues which will surely come up on a regular basis. So just take them as a daily challenge and check everything one by one because sometimes even an invisible faulty jumper wire can create problems.
I came across multiple challenges while working with the force sensors:
- Getting consistent output from all the sensors through the ADC and simultaneously dealing with the issues in working with the Adafruit library for ADS1115 .
- Since we were using six FSRs and the ADC we had was a 4-Channel device, we had to use two ADCs and thus had to configure two I2C interfaces available in Raspberry Pi to use them simultaneously.
- There is an ADC noise in the output that has to be removed.
- Also, the resolution of the output from the FSRs should be large enough so that we get significant output at a higher force.
Though these problems sound not so difficult, they take time to solve and this is the actual learning that you get as you go through the datasheets available for the hardware and start looking for a solution to the problem that you are facing.
Determining the FSR configuration and Testing the Prototype
Around the time the FSR program was up and running, Gaurav had developed the camera program using the Open CV bindings which support the Raspberry Pi platform and we were able to detect 4 markers, 2 placed at the head and chin of the helmet and 2 on the left and right shoulders. After we had both of the programs running, we had to test them on the bike so that we could identify the issues which we would keep in mind while designing the final prototype for the bike. Thanks to Vineeta (HCD faculty at Srishti) and Chakra (Industrial Design M.Des. student at Srishti) who helped us with the product design needed for in-house testing of the prototype. They literally made a cardboard bike in the lab which was modular enough to help us test the prototype consisting of the NoIR camera interfaced with Raspberry Pi and provided us the agility in developing the prototype.
The camera sensor unit was tested on the modular bike with good results. However, before testing the whole camera and FSR setup on an actual bike we needed to identify the pressure points where we would place the FSRs on the bike-seat. For this, we needed to have a kind of pressure map which could suggest us the regions of significant pressure applied on the seat by the bike rider. There are a good number of options to get a pressure map such as by using thermo-chromic ink, but the availability of the things define what you opt for. We decided to do this using alternatives that were readily available. We tried different materials and then combined some to get the desired results. We used charcoal on tissue paper, carbon paper with tissue paper but these things were not leaving an impression which would suggest us what we wanted to extract when we put them on a seat and sat on it. Finally after many iterations of using a combination of these materials, putting some oil on the carbon paper and then putting it in between tissue papers and taking the impression by sitting on it worked. This gave us enough information about the significant pressure regions which can govern the parameters that contribute to a posture. And now we had our six points where FSRs could be put and the actual testing could be done on the bike.
After we had the FSR matrix configuration in place and had the Camera and FSR program ready, we took the setup on the bike and did the testing and recorded the FSR readings and the live camera feed that we got from the NoIR camera setup with Raspberry Pi. That helped a lot in understanding the dynamics of the bike while commuting and we got to know the problems that we should be taking care of while designing the final prototype.
Moving over to Display Feedback Visualisation
After the initial tests, I started working on the visualisation for the interaction of the rider with the bike which would intuitively give feedback to the rider about his/her posture. This was one of the parts that I was dealing with for the first time, so there was a great bit of learning for me. As mentioned before, the task was to make the visualisation intuitive and at the same time assist the rider to get to a healthy posture sub-consciously over time. Thanks to Vineeta for taking this up with me and helping me learn the basics that we should focus on when working on such interactions, to make it more fluid and human-centered. To rethink the visualisation for the project, we revisited the premise of ReRide and the research studies conducted before for preventive self-care, the detail of which will be explained in a subsequent blog post.
Concluding Remarks
This blog is a more tech-descriptive one, and I hope that it conveyed the details of the project that I worked on this summer. I will be posting another blog about my internship experience and the brilliant work culture at Srishti.
Stay tuned.
Do send me your feedbacks on the blog and don’t forget to appreciate it if you liked it.
Project Team: Dr.Naveen Bagalkot (Srishti, Bangalore), Dr.Tomas Sokoler(ITU Copenhegan), Gaurav Singh (Srishti), Anchit Shukla (IIT Roorkee), Vignesh Chakkravarthy (Srishti), Vineeta Rath (Srishti)
