15 June 2023

Slideo - Communication between cyclists and automated vehicles

For my final bachelor project, I did a project about the future of mobility, more specifically about interaction with automated vehicles (AVs). I decided to do my project about cyclists, which is a type of vulnerable road users (VRUs) and are, in my opinion, not represented properly yet in existing literature. Most existing work is about the AVs telling VRUs what to do using a display on the outside of the vehicles. I wanted to look the other direction and explore a new perspective: Allowing the cyclists to share their intentions to AVs and making themselves more predictable. This project takes a future where the big majority of vehicles on the road is automated, and where all vehicles are connected to a network to communicate all kinds of information for better safety and efficiency.

The final design concept is Slideo: Slidable handles to communicate the intention to turn. If the cyclist wants to turn left, they can slide the left handle outwards, which will be registered by the integrated electronics and communicated to the network of automated vehicles around the cyclist. When the AVs in the network are aware that the cyclist wants to turn left soon, they can collectively change their speeds in order to give the cyclist the space they need to make the turn. The handles also contain vibration motors, which will give haptic feedback (which can be felt) to the cyclist to make them aware about the response of the AVs around them.

Read the Report

Below, I reflect on the design process I went through and my developments and learning points from the steps.

Literature review

At first, I read multiple papers about external human-machine interfaces (eHMIs) positioned on AVs with the goal to either make VRUs aware of the intention of the vehicle, or to tell the VRU what they can do. Most of these papers were targeted at pedestrians wanting to cross a street and I found little work about cyclists. I couldn’t find much about VRUs sharing their intentions to the AVs, which inspired me to make my project about exactly that. My opinion and expectation is that people don’t like to be told what to do, especially not by machines. They would much rather tell the machines what they will do, so the machines can take this in mind.

So after deciding for the project to head this direction, I tried looking up more literature about VRUs communicating their intention to AVs. My results were very limited, it was hard to find literature relevant to this topic. I did find a paper about a pedestrian waving to cars that they intend to cross and one asking cyclists how they feel about being told what to do by looking at an eHMI, this only increased my aims to explore this topic. It needs to start somewhere, and if I can make a start with my project, I can only hope others will follow. Therefore, my project will be very exploratory in nature and explore only one specific case. It will also be up to others to continue this line of thinking.

Design sprint

Expertise area: Creativity & Aesthetics After the literature review, I performed a design sprint in order to quickly come to a more specified design concept to develop further throughout the project. I took and adapted some techniques from Google’s Design Sprint Kit which were possible to perform individually. Starting with writing “How Might We” (or How Might I) questions on post-its as a way to brainstorm and rapidly form different ideas, I later sorted these questions in various clusters. These clusters can be considered sort of like desired use-cases of a design. Afterwards, I mapped out the cycling process and pinpointed which step in this process would be the target of the design, and created eight quick sketches exploring various ideas. Then, selecting some aspects from these ideas, I created a final solution sketch, which was my first iteration. The result of the design sprint was already a version of the sliding handles, but more importantly, the main idea is to have a certain interaction possibility on the bike itself to intuitively indicate a direction.

A major takeaway from this design sprint, is that brainstorming is very difficult to do alone. It is always difficult, but doing it alone really showed me how important the different perspectives and different ways of thinking from other people are. Their opinions matter and their ideas are relevant, and very often one person’s ideas lead to another person’s idea, allowing someone else to tweak it. When brainstorming together, ideas are really created together. Sure, an idea always starts at one person, but other people being able to refine the ideas and be inspired by each other is what makes brainstorming in a team so important.

Did I come up with the best idea during my solo brain storming sessions? No, I’m sure it can be better. I don’t think it’s not creative, I think my ideas are very relevant, but the limited perspective from a single person will almost certainly mean some potential has been left on the table during this project. In case of another individual project, I would really consider ways to brainstorm with other people right from the start. Perhaps by doing a focus group study at the start, as I believe that getting other people’s perspectives and opinions is very valuable at this point.

Comparing different concepts

Expertise area: User & Society Since the result of the design sprint is an “interaction possibility on the bike to intuitively indicate a direction”, I created and sketched four concepts at four different locations on the bike: The handlebar, the seat, the pedals and the knees. Interactivity could be added to each of these areas in order to indicate a direction, using an online questionnaire I compared the four concepts to find which would be preferred by people and why. The results were as expected: People prefer the hands over anything else and it can be argued that this is because it’s the most familiar concept to them. One reason for this is that people already use their hands to indicate their direction, another reason is that hands are most commonly used to interact with machines.

Overall, the concepts were received negatively. On the one hand, this could be because I posted this questionnaire on a forum on March 30th (two days before April 1st), which was pointed out by multiple people who thought they are funny. Another reason however, is that people generally don’t like change, and these days AVs are especially a topic of debate. I also think I didn’t explain the concepts good enough in the questionnaire, as many people seemed to think these are meant to be an obligatory addition to make cycling safe. I should have made exceptionally clear that this is not the case. The safety should always be guaranteed by the AVs, these design concepts are merely meant to make cycling more enjoyable. This observation did however lead me to reformulate the goals more clearly, so it wasn’t all bad. Anyway, it was clear enough that the hands were the preferred option for an interaction to indicate direction.

Selecting required features

Expertise area: Business & Entrepreneurship At this point, I knew I needed some device on the handlebar the cyclist can safely interact with to indicate their direction, and that it needs to communicate this wirelessly to the network of AVs nearby. But it shouldn’t be a required part of a bike, it should always be allowed and safe to cycle without any connected technologies like this. So if this is the case, why would someone use this? More importantly, who would pay for this? And why? Using the methods learned during the Design Innovation Methods course, I set out to answer these questions. At the same time, I determined what exactly the device needs to do in order to be viable from a business standpoint.

I created two personas: Emily Brinkley and Stefan Klemaker. Emily is a real business professional and usually travels to work by bike. Her reasons are simple: It is often faster or just as fast, easier to find parking, more sustainable than driving, and healthier because of the activity. In good weather, it can even be enjoyable, while in bad weather it’s always possible to get to work in a different way like public transit or driving. Stefan is an active guy who often likes to go cycling for fun. For him, it is a leisure activity he can do alone, but more often with friends. Often, they cycle a route they are not (fully) familiar with, either because they don’t cycle there often or because they are sightseeing at some unfamiliar place. In these situations, they use navigation on their bikes, which can be quite the hassle at times when cycling in a group.

Both of these personas would value from an interactive product on the handlebar, and both of these could be interested in buying it. For each persona, a value proposition canvas (VPC) was made, which is a tool to specify the user needs, and the good and bad outcomes for the user. Based on these aspects, the product offering can be filled in and tweaked to be fitting to the user. The product offering is also called a value proposition, meaning how the product will offer value to the user. For Emily, the product will be valuable when it allows her to reach her destination faster by having to wait less for other traffic. For Stefan, the product would offer extra value if it has clear and easy to follow navigation cues which is easy to set up and can be used by all group members to avoid confusion.

This information gives me a strong basis for a product and I used it as a start to fill in a business model canvas. This tool is meant to clarify a product’s feasibility in a business environment and goes over things like the customers, the value propositions, revenue streams, partners and more. For instance, individual users are not the only ones who could pay for a product like this. It is also possible for bicycle manufacturers to buy the product in order to incorporate it in their own bicycle designs and make their own product more appealing. Bicycle rentals are also a logical customer, as the majority of their customers are cycling in an unfamiliar location and likely to use navigation. Or even large employers wanting to make cycling to work more attractive for their employees could invest in a product like this, as it saves their employees and ultimately them more time spent travelling, leaving time for other activities.

Based on the desired features defined using the VPC for each persona and the business model canvas, the following hardware would be required:

• Interactive sensing circuit (button/slider/etc)
• Vibration motor in each handle
• Communication technology to create groups and participate in network
• GPS
• Connectivity technology for operation with smartphone (adding routes/making groups/etc)
• Mountable on existing handlebar OR complete handlebar with integrated technology
• Optional: LEDs or simple display for additional information

Of course, not all of these are required for a final prototype, but a real product would have at least these requirements.

Using the business tools in order to determine what the product needs to do was a nice way to go about this. It really gave me a clear understanding and purpose of the design, allowing me to focus on making the actual design. This also means the decisions are grounded and made for a reason: Offering value to the user and it being realistic in a business setting. Even in a project like this where a product like this will obviously not be made or sold anytime soon, I believe this is still a good way to clearly define what the product needs to do, as a good business proposal naturally involves user needs.

Exploring different interactions

Expertise area: Creativity & Aesthetics The main requirement which still needs to be explored, it the interactive sensing circuit. In other words, what does the cyclist perform in order to indicate their direction? To explore different kind of sensing methods, I created an exploratory prototype, inspired by the Exploratory making course. In total, I managed to think of and make three different interactions: A simple button, a lever to push with the fingers, and of course the sliding handle concept. I also added a break handle, in order to be able to hold this prototype similar to how your hands would be positioned on an actual bike. This already rendered the lever at the bottom relatively useless, as the fingers can’t be on the break handle when you want to use this. A button is simple and easy to use, but that space on a bike could also be taken up by a gear switcher, or there may be other buttons to press as well. The sliding motion can be performed as long as you have some grip on the handle and doesn’t require specific finger placement, which is why I decided to continue with this idea.

It was a nice experience to use the exploratory making techniques in an actual project and it showed me how valuable simple interactive prototypes can be. I created an actual mechanism to allow the handle to be slid out slightly so this was the first time I could try it out. Although in this prototype it was a little bit too firm, it felt good and showed to be promising. If the sliding handle would have been a bad idea, this is the step where I would have found out about that.

Creating final prototype

Expertise areas: Technology & Realization + Math, Data & Computing Based on personal interest and the complexity of the sliding mechanism, I decided to 3D print the mechanism for my final prototype. This allowed me to first of all learn how to do this, since I haven’t done any 3D printing before. Also, by 3D printing the same parts twice, I could get two identical handles with the exact same dimensions and sliding distance. If I would make both handles and mechanisms by hand, it could be extremely difficult to get both mechanisms to feel the same. Another advantage of 3D printing is that this allowed me to make the inner diameter of the handles exactly the same as the standard dimensions of handlebars, which is 22.2mm. This way, I can mount the prototype to any bike or other handlebar with the standard dimensions.

To 3D print something, you first need to make a CAD model. Therefore, I had to learn how to use SolidWorks first. This was a nice opportunity to learn how to use this program, which is used by many companies in many different fields because of its versatility. Having some basic skills in SolidWorks can prove to be a valuable skill in the future, so the time invested in this is well worth it. After learning the basics of SolidWorks, I made the CAD model of the sliding handle, taking special care to leave room for the vibration motor, cables, a DIY button and rubber bands on the inside layer of the prototype. Since this was my first CAD model and a pretty complex one, this took a lot of time, but it was a valuable learning process.

After having every part printed twice, I had 14 separate parts to assemble into two bicycle handles. At this time, I learned that 3D printers are not perfect and do have some inaccuracy, especially with smaller scale prints like this. It took a lot of time to remove any support structures, and even more time to make everything fit and to make the mechanism work. Also, because of these inaccuracies, I was not able to actually implement a button mechanism inside the prototype, neither was it possible to add rubber bands on the inside as was originally planned. So, I needed to activate the haptic feedback from the vibration motors with an external button, and the handles will not slide back on their own. This also caused them to be very smooth and low resistance. When trying it myself on my own bicycle, they were indeed too smooth in their current state. This lead to them accidentally sliding out regularly, for example when going over bumps or accelerating. When increasing the resistance by adding some tape in between the layers, it was much better. It did not slide out accidentally anymore and also did not interfere with the steering motion.

The electronics were rather straight forward. The only slightly difficult part was that the Arduino digital pins aren’t able to output enough current for the vibration motors, so they needed to be powered from the 5V pin instead (which is able to provide enough current for both motors). The voltage applied to each motor is regulated using a transistor which is controlled by a PWM capable pin on the Arduino. This allows me to not only turn the motor on or off, but also regulate its intensity by changing how much voltage is provided. Since the motors kept breaking (their wires are very fragile and kept detaching from the motor), the eventual motors used weren’t mounted to the inside of the prototype as originally planned. Instead, I last-minute mounted them to the outside using tape.

From making this prototype, I certainly learned a lot about 3D printing. I now know what things I would do differently next time I use 3D printing. For example, I would decrease the amount of parts and try a different way to assemble them. In this prototype I tried to use small hooks in order to assemble them without using any glue, but this didn’t work and took more time than using glue would have taken.

User test haptic feedback

Expertise area: User & Society At the end of my project, I performed a user test. Since the sliding mechanism in the prototype is not in a good enough state (too smooth) to be user tested on an actual bicycle, this was no option. However, the vibration motors worked well enough and would be nice to test out in a quantitative way. I recorded a video of myself using the handles and programmed the prototype to play the vibration patterns synchronised to when I slide a handle and take a turn in the video. I showed this video to nine participants while letting them feel the haptic feedback via the prototype. This way, I compared two variations of the vibration patterns, while also testing their overall effectiveness at the same time. The findings were that it is actually a matter of personal preference which variation is preferred, but the vibrations overall were clear enough for most users without any in-depth explanation. The full results can be found in Section 3.2 in the report.

I believe this is a valuable and important addition to my project. Being able to work with users is very relevant for pretty much any project, including this one. It is also a way to validate the final design. Although it is difficult to manage the test-setup, participant recruitment, taking the tests and analysing the results all individually instead of in a group like usual, a designer should be capable of doing all these steps even if they don’t actually do all steps in a group project. This user test could and perhaps should have been done with more participants, but due to the individual nature of this project there was not enough time for this. Nonetheless, I believe the results are still valid, partly because of the differences between each participant (cultural backgrounds, ages, interests in technology, etc).

Report writing

After the user tests, which were delayed because of difficulties while making the prototype, there was not a lot of time left to finish the report. Throughout the project, large parts had already been written though, so I didn’t have to write the entire report in a short period of time. I think overall, it is decent and properly explains the project and the steps I took. It could be better, I’m not incredibly proud of it, but I’m also not disappointed.

When I completed the literature review, I wrote the introduction. When I completed the first steps of the project, I wrote the sections about these steps as well. So the report was really written gradually, which is the correct way to go about things. Only because of the rush relatively later on while creating the final prototype, I wasn’t able to keep up with the report. But in the week after Demoday, it was only sections 2.4, 2.5, 3.2 and the discussion I had to write, including tweaking some things here and there. So in general, the process of writing the report went all right and I will definitely aim to “maintain” a report while working on future projects instead of “writing” a report afterwards.

Read the Report

tags: Automation - future - explore - cycling - interaction - intuitive