WO2023118952A1

WO2023118952A1 - Two-wheeler integrated system for an improved riding experience

Info

Publication number: WO2023118952A1
Application number: PCT/IB2021/062333
Authority: WO
Inventors: Vera Patrícia CASTRO VILAS BOAS; Maria Isabel ALMEIDA DA COSTA PINTO LISBOA; Rui Manuel FERREIRA GOMES; Ricardo Jorge RAMOS PESSOA
Original assignee: Bosch Car Multimedia Portugal, S.A.; Universidade Do Minho
Priority date: 2021-12-22
Filing date: 2021-12-27
Publication date: 2023-06-29

Abstract

"Two-wheeler integrated system for an improved riding experience" The present application describes a human-machine interface system for a two-wheeler vehicle rider. The developed system comprises an audio module configured to decipher voice instructions collected from a microphone installed in a rider helmet; a hazard detection module configured to catalogue and prioritize surrounding hazards of the two-wheeler vehicle; an electronic control unit configured to exchange voice data with the audio module, exchange data with a multiple service platform and with a personal assistant cloud service; and receive data from the hazard detection module; wherein the audio module is further configured to play audio notifications on a headset installed in the rider helmet.

Description

Two-wheeler integrated system for an improved riding experience

Technical Field

The present application describes a human-machine interface system for a two-wheeler vehicle rider .

Background art

Document US2011224893A describes techniques for generating and using information regarding road traf fic in various ways , including by obtaining and analysing road traf fic information regarding actual behaviour of drivers of vehicles on a network of roads . Obtained actual driver behaviour information may in some situations be analysed to determine actual delays for vehicles encountering various particular road features in the network of roads , such as for identi fied decision points at which drivers face choices corresponding to possible alternative routes through the network of roads ( e . g . , intersections , highway exits and/or entrances , etc . ) and/or for other traf fic flow impediments . The identi fied and determined information from the analysis may then be used in various manners , including in some situations to assist in determining particular recommended or preferred routes of vehicles through the network of roads based at least in part on actual driver behaviour information .

Document US20160047662A1 describes methods and systems for an improved navigation environment are provided . The navigation system can route users to preferred locations based on user profile data and past experience with the present driver and other drivers . The system provides more cost-ef fective and time-sensitive routing by incorporating other information about destinations . Further, the navigation system provides enhanced guidance in foreign or unfamiliar locations by incorporating experience from other drivers and other data .

Document US2010250106 describes a method for providing messages indicating potentially hazardous road conditions using a wireless communications network . Vehicles using the network include sensors that are able to detect various potentially hazardous road conditions , such as rain, fog, icy road conditions , traf fic congestion, etc . A plurality of vehicles that detect a speci fic road condition provide a confidence value that the condition exists . The confidence value is then aggregated by the vehicles with the confidence value of the detected condition from the other vehicles to provide an aggregated result that identi fies the probability that the detected road condition is occurring . The aggregated result is then transmitted to other vehicles approaching the road condition, possibly in a multi-hop manner . Alternately, the confidence value from all of the vehicles that detect the condition can be transmitted to approaching vehicles who will provide the aggregated result identi fying the potential that the condition exists .

Summary

The present invention describes Human-machine interface system for a two-wheeler vehicle driven by a rider, comprising : an audio module configured to decipher voice instructions collected from a microphone installed in a rider helmet ; a hazard detection module configured to catalogue and prioriti ze surrounding hazards of the two-wheeler vehicle ; an electronic control unit configured to exchange voice data with the audio module , exchange data with a multiple service platform and with a personal assistant cloud service , and receive data from the hazard detection module ; wherein the audio module is further configured to play audio noti fications on a headset installed in the rider helmet .

In a proposed embodiment of present invention, the electronic control unit is further configured to display visual noti fications on a Head-up display (HUD) installed of the rider helmet .

Yet in another proposed embodiment of present invention, the audio noti fications comprise audio alerts , preconfigured voice alerts or preconfigured voice questions .

Yet in another proposed embodiment of present invention, the visual noti fications comprise visual graphical alerts , visual text alerts or visual text questions .

Yet in another proposed embodiment of present invention, the voice data comprises voice commands and voice noti fications .

Yet in another proposed embodiment of present invention, the surrounding hazards comprise data from sensors installed in the two-wheeler or data from Vehicle to all other vehicles (V2X ) hazards services

Yet in another proposed embodiment of present invention, the multiple service platform comprises at least one of a cloud email service , a cloud calendar service and a cloud weather service . Yet in another proposed embodiment of present invention, the personal assistant cloud service is configured to gather rider information and compute said information through learning algorithms to predict rider routines or behaviors .

Yet in another proposed embodiment of present invention, the audio noti fications and the visual noti fications are triggered by the electronic control unit through multiplecriteria decision analysis of at least one of a data provided by the audio module or data provided by the multiple service platform or data provided by the personal assistant cloud service or data provided by the hazard detection module .

Yet in another proposed embodiment of present invention, the personal assistant cloud service comprises at least one of a j ourney track, weather forecast , points-of-interest information, events and or accidents not scheduled on the route .

Yet in another proposed embodiment of present invention, the data from sensors installed in the two-wheeler comprises at least one of a two-wheeler sensor suite , for example , one of an acceleration and deceleration information .

The present invention further describes the method of operation of the human-machine interface system for a twowheeler vehicle driven by a rider according to the above mentioned description, wherein the hazard detection module catalogues and prioriti zes surrounding hazards of the twowheeler vehicle ; the electronic control unit exchanges data with the multiple service platform and with the personal assistant cloud service , and receives data from the hazard detection module; the electronic control unit exchanges voice data with the audio module which plays audio notifications on the headset installed in the rider helmet; the electronic control unit displays visual notifications on the HUD installed of the rider helmet; the rider interacts with the audio module through a microphone installed in the rider helmet providing voice commands.

General Description

The present invention describes a system designed specifically for riders to assist both riding (e.g., giving riding suggestions or route suggestions) , and everyday tasks (e.g., displaying calendar or email notifications) . Most importantly, the system is also able to learn from the rider's routines and make smart suggestions (e.g., the system suggests another route if the usual route is unavailable) and it privileges voice interaction via internal speakers placed inside the helmet. The system is designed for users of two-wheelers, in particular, for motorcycle users.

In comparison with the automobile industry, the development of human-machine interface (HMI) technologies for motorcycles is lacking behind. Most of present days existing technology is directed and particularly designed to two- wheels plus vehicle drivers, conveying information in an optimal interaction modality to be perceived and acknowledge, lacking, therefore, technical developments for this particular need.

The development of the present invention arises from the need of providing the two-wheel vehicles with driving assistants . Since the experience of riding a two-wheel vehicle is , nevertheless , a very distinct one , thus , a direct application of the automobile developments to a motorcycle must be taken carefully . First , the HMI and rider interactions mostly happen in an open environment . The interaction must thus work within a noisy environment ( aggravated by both the engine and the wind sound) , and under di f ferent weather conditions ( the rider is directly exposed to airstream, sun or heat , and precipitation; solar reflection can be a problem for visual interaction with a display) . Second and most importantly, interacting with an interface while riding on two wheels can be very dangerous .

Riders are more exposed to traf fic risks than two-wheels plus vehicle drivers , and an error or a distraction is more likely fatal : riders do not have a vehicle structure surrounding them as vehicle drivers do ; and they also lack the vehicle-common safety features , such as seat belts or airbags ; finally, riders are overlooked much easily than drivers of larger vehicles on the road . As a result , fatalities in motor crashes are much more likely to happen for involved motorcyclists than car passengers , with some studies reporting that the risk of being killed is 20 to 32 times higher for motori zed two-wheeler users than for vehicle occupants . Cons idering these limitations , it is thus critical to design and develop HMI speci fically designed and adapted for riders needs to assist and increase the safety of riding in a two-wheeler .

Since motorcycles have less locations where an interface could be installed, and display interaction while driving is very di f ferent , the best visual interactions for riders are conveyed via Helmet-Mounted Displays . However, it should be taken in account that two-wheel drivers also suf fer from solar reflection which might interfere with visual interaction with a display . For the proposed invention, truly critical features were considered as the presence of hazards like oil spills on the road, strong side winds or torrential rain .

The herein disclosed invention endeavors to provide information that is speci fically and particularly relevant for two-wheel drivers , achieve this in an easy and safe manner for motorcyclists . The system is thought to allow riders to access useful information ( that may even be critical to their safety) while riding and, in addition, provide information to enhance their riding experience while assisting their daily activities .

Overall , present disclosed intention aims to overcome state- of-the-art flaws with regard to the existent HMI solutions particularly thought for two-wheel plus driver only, providing a particular and speci fic solution for motorcycle riders .

Thus , the developed system, mainly described as a rider personal assistant , is the first to comprise a set of relevant functions speci fically thought and developed for two-wheel riders , such as :

( 1 ) calendar noti fications , including both email and calendar noti fications ;

( 2 ) ride/route planner : this function is related to the experience of riding as a leisure activity in weekends or holidays ; the rider can plan in advance trips in group or alone using the rider personal assistant ; and the system suggests the best routes for riding considering future meteorological information, preferences of the rider, points of interest, and when, where and how long the rider intends to ride; the rider plans the trip and can add the trip to his/her calendar and share its riding plan;

(3) route suggestions: it considers the rider's daily calendar events to suggest a route to a specific destination when the rider approaches the motorcycle; it also suggests alternative routes when the usual one is blocked or congested, and/or when the preferred road has potentially hazardous conditions specifically relevant for riders such as oil spills, strong side winds or torrential rain;

(4) points-of-interest suggestions: this feature is particularly important on riding trips, where the system suggests and is able to generate a detour route based on the interest point; points of interest might include museums, monuments, restaurants, bike parking or gas stations; and

(5) riding suggestions: includes suggestions of fuel consumption minimization -eco mode-, cornering aid and speed limit warnings.

The motorcycle main system functions can also be incorporated in the user's mobile phone, personal computer, notebooks, handheld devices, or other portable products via an app . While riding, the system-rider interaction is fast, intuitive and thought within the particular context of riding a motorcycle, thus, it is done via voice commands using simple voice instructions, requiring minimal distraction of the rider from the primary task of riding. Brief description of the drawings

For better understanding of the present application, figures representing preferred embodiments are herein attached which, however, are not intended to limit the technique disclosed herein .

Fig . 1 - illustrates a block diagram of the architecture of the rider personal assistant system, where the reference numbers relate to :

100 - inputs ;

101 - riders ' microphone ;

102 - cloud, email and weather services ;

103 - personal assistant cloud service ;

104 - motorcycle sensors ;

130 - audio interface ;

140 - internet connection;

150 - V2X hazards interface ;

160 - voice commands ;

170 - voice notifications ;

180 - audio notifications ;

190 - video / visual noti fication;

200 - rider assistant system;

201 - voice-to-text and text-to-voice module ;

202 - riders ' assistant Electronic Control Unit (ECU) ;

203 - hazard detection module ;

300 - outputs ;

301 - rider helmet headset ;

302 - rider helmet Head-up display (HUD) .

Fig . 2 - illustrates the behavioral block diagram of the Email/calendar noti fication use cases logic of the rider personal assistant system, wherein the reference numbers are related to:

400 - Email/calendar notification use cases logic;

401 - new email?

402 - yes;

403 - play audio sound notification: new email;

404 - acknowledge in t=10sec;

405 - yes;

406 - clear notification;

407 - event in 10 min?;

408 - yes;

409 - play audio sound notification: event in 10 min;

410 - acknowledge in t=10sec;

411 - yes;

412 - clear notification;

413 - event now?;

414 - yes;

415 - play audio sound notification: event now;

416 - acknowledge in t=10sec;

417 - yes;

418 - clear notification.

Fig. 3 - illustrates the behavioral block diagram of the route planner webapp case logic of the rider personal assistant system, wherein the reference numbers relate to:

450 - route planner webapp logic;

451 - load tracks near home and weather along them;

452 - done?;

453 - yes;

454 - show track list on app screen w/weather;

455 - track selected?;

456 - yes; 457 - fill the email of the participants, create a calendar event and upload the track to all bikes.

Fig. 4 - illustrates the behavioral block diagram of the route planner notification logic of the rider personal assistant system, wherein the reference numbers relate to:

500 - route planner notification logic;

501 - journey in server?;

502 - yes;

503 - load journey;

504 - journey day?;

505 - yes;

506 - Audio Message: "today is journey day! Start GPS?";

507 - Visual message: "today is journey day! Start GPS?";

508 - accept journey?;

509 - No;

510 - Discard journey notification;

511 - yes;

512 - Audio Message: "Journey has started. Please follow the new GPS instructions";

513 - Visual message: "route accepted".

Fig. 5 - illustrates the behavioral block diagram of the route based on calendar events location notification logic, wherein the reference numbers are related to:

550 - route based on calendar events location notification logic;

551 - events on calendar?

552 - yes;

553 - location set?

554 - yes; 555 - Audio message: "Are you heading for your event [EventName] . Start GPS?"

556 - Visual message: "Bad weather in your route. Accept alternative?";

557 - Accept route?

558 - No;

559 - Mark and discard route;

560 - Yes;

561 - Audio message: "Route has been set. Please follow new GPS instructions";

562 - Visual message: "Route accepted";

563 - Accept route;

564 - Mark event route complete.

Fig. 6 - illustrates the behavioral block diagram of the accident in route notification logic of the rider personal assistant system, wherein the reference numbers relate to:

600 - accident in route notification logic;

601 - blockage in route?

602 - no;

603 - yes;

604 - compute new route;

605 - Audio message: "There are unexpected delays/dangers in your route. We've found an alternate route. Do you accept?" - each audio and/or visual sentence can be adjusted depending on the type of event found along the route;

606 - Visual message: "Unexpected delays/dangers in your route. Accept alternatives";

607 - accept route;

608 - No; 609 - Yes;

610 - accept route; 611 - Audio message: "Route has been accepted. Please follow the new GPS instructions.";

612 - Visual message: "Route accepted.";

613 - Discard route;

614 - No;

615 - New day?;

616 - Yes .

Fig. 7 - illustrates the behavioral block diagram of the POI (Point Of Interest) suggestion notification logic of the rider personal assistant system, wherein the reference numbers relate to:

650 - POI suggestion notification logic;

651 - POI in range?;

652 - yes;

653 - Audio message: "You have a supermarket 1km ahead on your right. Change destination to the POI?";

654 - Visual message: "You have a supermarket 1km ahead on your right. Change destination to the POI?";

655 - Change destination?

656 - No? in t=10s;

657 - Yes;

658 - Audio message: "Destination is now Supermarket. Please follow the new GPS instructions.";

659 - Visual message: "Route accepted";

660 - Compute new route;

Fig. 8 - illustrates the behavioral block diagram of Hard acceleration/breaking notification logic of the rider personal assistant system, wherein the reference numbers relate to:

700 - Hard acceleration/breaking notification logic;

701 - ECO mode? 702 - No;

703 - Yes;

704 - Accelerating hard?

705 - Yes;

706 - Audio message: "You are accelerating to hard. Soft accelerations save fuel.";

707 - Visual message: "You are accelerating to hard. Soft accelerations save fuel.";

708 - Hard braking;

709 - No;

710 - Yes;

711 - Audio message: "You are braking to hard. Soft braking saves fuel and your braking pads.";

712 - Visual message: "You are braking to hard. Soft braking saves fuel and your braking pads.";

Fig. 9 - illustrates the behavioral block diagram of the cornering aid notification logic of the rider personal assistant system, wherein the reference numbers relate to:

750 - Cornering aid notification logic;

751 - Corner aid ON?;

752 - Yes;

753 - No;

754 - Roll > ten degrees?

755 - Yes;

756 - No;

757 - Audio Message: "Hard lef t/right ! " ;

758 - Visual Message: motorcycle sketch indicating present motorcycle inclination and the preferable motorcycle inclination;

759 - ten sec;

760 - Clear all the notifications. Description of Embodiments

With reference to the figures, some embodiments are now described in more detail, which are however not intended to limit the scope of the present application.

The developed rider personal assistant is a system designed and configured to assist the two-wheel rider on different tasks associated with riding and personal life. As depicted in Figure 1, the core building blocks of the rider personal assistant system (200) are an Electronic Control Unit (ECU) (202) , an Audio module (201) , or a Voice-to-text/Text-to- voice and a Hazard Detection module (203) .

The Electronic Control Unit (ECU) (202) of the Rider Personal Assistant (200) is the central processing unit that manages all systems and ensures all information and resources are properly used to achieve the best safety results and user experience .

For the HMI (Human-Machine Interface) the Rider Personal Assistant comprises an Audio module (201) that relies on voice recognition to accept audio commands and is also configured to play audio notifications (180) and/or visual notifications (190) and suggestions. It works as an audio- to-text/ text-to-audio converter (201) where it accepts rider's voice commands and processes them. To achieve this, the Rider Personal Assistant (200) is connected to the helmet headset, e.g., helmet speakers and microphone (101) .

The Rider Personal Assistant (200) comprises a hazard detection module (203) , which is responsible by cataloguing and prioritizing all possible hazards either detected in the motorbike's environment by reading appropriate bike sensors (104) or communicated Vehicle to all other vehicles (V2X) hazards by other nearby vehicles.

The hazard detection module (203) not only sends/receives V2X hazard events (150) , but it also interacts with the server by sending information regarding the rider' s routines and habits to run machine learning routines on the server side and receive suggestions based on those habits. This information can also be distributed through both local and server storing means. Hazards that rely on bike high-rate sensors data, will compute the hazard risk in the local hazard detection module (203) and publish them via V2X to the cloud servers to inform other vehicles of what is happening. Conversely, on the server side, all the information from all vehicles (cars, trucks, bikes, etc) present on all roads is collected and other type of hazards are computed for that particular bike rider (e.g. collision with other vehicles risks) , fed back to the bike via internet and module (203) and prioritized with the locally computed hazards. The kind of information collected on the bike side (client side) includes vehicle position, velocity, acceleration, distance to nearby vehicles and more. Examples of self-accident estimation detection includes, for instance, detecting extremely high accelerations due to collisions (that would trigger an Airbag in an automobile) , or unexpected bike falls detected by unexpected roll data, or weird vehicle behaviours using pitch data, sensor distance to nearby vehicles, and so on. On the server side, information as vehicle position, velocity, heading, acceleration, etc. (at slower data rates) , could be useful to detect possible future vehicle collisions and avoid accidents . The minimum requirements to ensure the real time data connections between the proposed modules of the system (200) is a reliable mobile network connection, preferably 5G, and a computational system that allows to ensure both cloud service and communication interfaces. The theoretical sources of information are already vehicle installed sensors, potential future sensors that need to be installed in the vehicles and communication and computation technologies (5G networks, servers, security and algorithms) to facilitate the exchange of information between vehicles.

Once the prioritization is complete, some of the most important hazards are communicated via a warning audio message (180) played on the helmet headset (301) ; further comprising a secondary channel which can also include a visual notification in the Heads-Up Display (HUD) (302) . The HUD (302) can comprise two different implementation approaches. One can resort to the use of glasses with special lens with projected images therein. Another approach can lay on the projection of the information inside the helmet, directly over its' frontal face shield visor from the inside making it a transparent screen.

The Personal Assistant Cloud service (103) is responsible for collecting and storing all the information regarding the rider's routines and habits, as well as dynamically interact with appropriate learning algorithms so they can predict the rider' s routines more accurately based on the most recent data. This personal data is stored and optimized in a remote manner through existing cloud services that are ensured through internet connections (140) supported by network technologies duly adapted for this purpose, and which are later accessed by the Electronic Control Unit (202) .

The Cloud Email, Calendar & Weather services module (102) , which is remotely accessed via an internet network connection (140) by the ECU (202) , is a service responsible for the connection with a cloud server (multiple OS compatible) to collect information regarding emails, calendar events and weather. The required Internet connection (140) presupposes the rider' s authentication credentials must be set using the cluster configuration menu so the bike can collect the information regarding those services. Only after this step is complete, the rider's assistant can make suggestions and present them in the form of audio (180) and/or visual notifications (190) .

Figure 2 illustrates the behavioral block diagram of the Email/calendar notification use cases logic (400) of the rider's personal assistant system (200) , wherein the email (401) and calendar (407, 413) notifications are transmitted to the rider by playing short audio notifications such as "10 min to event" (409) , "event is starting now" (415) or "new email received" (403) . The rider can dismiss these notifications by issuing an acknowledge voice command such as "Ok" or "Yes" (405, 411, 417) . If no action is taken, the notifications (401, 407, 413) will dismiss themselves after a few seconds.

The route planner takes mainly the form of a web application where riders prepare and plan their next journey, possibly in the next weekend or holidays. The top-level functional logic is depicted in Figure 3. The web application starts by connecting to the Personal Assistant Cloud service (103) to collect the most popular journey tracks (451) riders like to travel, nearby home location, and present them as a list together with review ratings done by other riders. The list shows also an overview of the weather along each journey for the desired journey date. This presupposes a query to a weather cloud service (102) for each journey. The rider then chooses the one based on its length, duration, location and points-of-interest (POT) along the track, such as restaurants, gas stations, tourist attractions, hotels, etc. Once selected (455) , the web app communicates with the Personal Assistant Cloud service (103) storing the desired journey and triggering its upload to the bike and to the rider personal calendar (102) . As an alternative, the rider can add other journey participants so they can receive the same calendar event and have their bikes uploaded with the same journey (457) .

At the same time, the web application saves the rider's preferences in terms of journey characteristics so it can rank future journey queries based on those specific personal preferences. That data will be used to calibrate appropriate machine-learning algorithms on the Personal Assistant Cloud service (103) and used upon request.

When ready to start the journey, all bikes automatically suggest starting the GPS using the pre-planned journey track. GPS units will then give the same instructions to all riders within the selected group so that they follow the same path/route .

The Rider Assistant ECU (202) , on the other hand, as illustrated in Figure 4, will check if there is a stored journey (501) in the Personal Assistant Cloud service (103) and downloading it (503) and setting a journey notification flag. On the journey day (504) , the assistant outputs an audio and visual notification (506, 507) as suggested and illustrated in Figure 4. If the journey is accepted (508, 511) , via the voice recognition module (201) , another audio and visual notification (512, 513) confirms the option. Otherwise, the notification is discarded (509) and only accessed from a proper menu available on the integrated cluster graphical user interface (GUI) .

Figure 5 illustrates the logic used to suggest the destinations based on the rider' s calendar events and in learning rider's routines (550) . When the bike is initiated, the rider's assistant ECU (202) queries the rider's calendar (102) and looks for events within, for example, the next 30 to 180 minutes (551) . If the next calendar event is found with the location properly set (553) , it suggests starting the GPS route towards to that destination (557) . As in previous procedures, the assistant (200) outputs an audio (555, 561) and visual (556, 562) notifications through the existing outputs (300) , particularly on the headset (301) and on the HUD (302) , on the definition and setting of the location (553) and on the accepting of the route (557) enquiries .

The flowchart in Figure 6 describes the logic employed when road blockages (accidents, oil spills, construction work, bad weather, etc.) occur along the pre-selected route and the assistant suggests a new route. The rider can either accept or reject, and the response can come either from the voice recognition module or by touching a button on the handlebar (or on the motorcycle integrated cluster's touch screen) . When the road blockage is reported along the predetermined route (601) , the Rider Personal Assistant ECU (202) requests a new route (604) and plays an audio and visual message (605, 606) alerting for the problem and suggesting a new route. If the rider accepts the new route (607) , a confirmation audio and visual message is heard and seen (611, 612) and the GPS notifications change to the new route, giving instructions on the integrated cluster or using audio instructions. If rejected (613) , the calculated route is discarded.

To receive suggestions about specific types of points-of- interest (651) , accordingly with one of the suggested embodiments described in Figure 7, the rider must subscribe to them first. Once the system knows what the rider is interested in, it can inform them via audio and video/visual information in the HUD (302) . Audio notifications can take the form of "You have a POI 1 Km ahead on your right. Change destination to the POI?" (653) , and the visual information might comprise displaying "You have a POI 1 Km ahead on your right. Change destination to the POI?" (654) . Some POI categories include supermarkets, pharmacies, gas stations, tourist points, and more. If the rider is interested in changing the destination for the desired POI (655) , the bike can recognize a voice command, or alternatively, the rider can simply wait a few seconds and the notification dismisses itself (656) .

There are several driving suggestions that can be made to the rider. Some of them include fuel consumption minimization (eco mode) (701) , cornering aid, speed, among others.

With respect to fuel consumption minimization, and as illustrated in Figure 8, an accelerometer can be used to detect longitudinal accelerations. If this acceleration is above a certain threshold either positive (braking) (708, 710) or negative (accelerating) (704, 705) , a visual notification is emitted on the HUD screen (707, 712) . Since frequent audio notifications of this class can be rather annoying at least when combined with all other triggered audio notifications (706, 711) , it is possible to disable this feature in the configuration menu on the cluster.

In terms of cornering safety, it's very important to have a route anticipation system where the radius of curvature can be predicted ahead of the current time so the rider can plan the curve. This information can be presented to the rider in the form of bike roll inclination as suggested in figure 9. For example, a curvature radius of 40m at a speed of lOOkm/h yields a roll inclination of X degrees (let's consider 10 degrees as an example) . If this inclination is higher than 10 degrees, the notification described in Figure 9 is displayed where a motorcycle sketch (758) is printed on the HUD screen (302) suggesting how much the rider should incline (gray) and how much the rider is currently inclined (black) . The assistant can also issue speed warnings depending on both the bike's speed and the road's speed limit, or the safest speed the rider should tackle the next turn based on its curvature radius.

Claims

1. Human-machine interface system for a two-wheeler vehicle driven by a rider, comprising: an audio module (201) configured to decipher voice instructions collected from a microphone (101) installed in a rider helmet; a hazard detection module (203) configured to catalogue and prioritize surrounding hazards of the two-wheeler vehicle ; an electronic control unit (202) configured to exchange voice data with the audio module (201) , exchange data with a multiple service platform

(102) and with a personal assistant cloud service

(103) , and receive data from the hazard detection module (203) ; wherein the audio module (201) is further configured to play audio notifications (180) on a headset (301) installed in the rider helmet .

2. Human-machine interface system for a two-wheeler vehicle driven by a rider according to claim 1, wherein the electronic control unit (202) is further configured to display visual notifications (190) on a HUD (302) installed of the rider's helmet.

3. Human-machine interface system for a two-wheeler vehicle driven by a rider according to any of the previous claims, wherein the audio notifications (180) comprise audio alerts, preconfigured voice alerts or preconfigured voice questions.

4 . Human-machine interface system for a two-wheeler vehicle driven by a rider according to any of the previous claims , wherein the visual noti fications ( 190 ) comprise visual graphical alerts , visual text alerts or visual text questions .

5 . Human-machine interface system for a two-wheeler vehicle driven by a rider according to any of the previous claims , wherein the voice data comprises voice commands ( 160 ) and voice noti fications ( 170 ) .

6 . Human-machine interface system for a two-wheeler vehicle driven by a rider according to any of the previous claims , wherein the surrounding hazards comprise data from sensors installed in the two-wheeler or data from V2X hazards services ( 150 ) .

7 . Human-machine interface system for a two-wheeler vehicle driven by a rider according to any of the previous claims , wherein the multiple service platform ( 102 ) comprises at least one of a cloud email service , a cloud calendar service and a cloud weather service .

8 . Human-machine interface system for a two-wheeler vehicle driven by a rider according to any of the previous claims , wherein the personal assistant cloud service ( 103 ) is configured to gather rider information and compute said information through learning algorithms to predict rider routines or behaviors .

9 . Human-machine interface system for a two-wheeler vehicle driven by a rider according to any of the previous claims , wherein the audio noti fications ( 180 ) and the visual notifications (190) are triggered by the electronic control unit (202) through multiple-criteria decision analysis of at least one of a data provided by the audio module (201) or data provided by the multiple service platform (102) or data provided by the personal assistant cloud service (103) or data provided by the hazard detection module (203) .

10. Human-machine interface system for a two-wheeler vehicle driven by a rider according to any of the previous claims, wherein the personal assistant cloud service (103) comprises at least one of a journey track (451) , weather forecast, points-of-interest information, events and or accidents not scheduled on the route.

11. Human-machine interface system for a two-wheeler vehicle driven by a rider according to any of the previous claims, wherein the data from sensors installed in the two-wheeler comprises at least one of a two-wheeler sensor suite, for example, one of an acceleration and deceleration information .

12. Method of operation of the human-machine interface system for a two-wheeler vehicle driven by a rider according to any of the previous claims 1 to 11, wherein the hazard detection module (203) catalogues and prioritizes surrounding hazards of the two-wheeler vehicle ; the electronic control unit (202) exchanges data with the multiple service platform (102) and with the personal assistant cloud service (103) , and receives data from the hazard detection module (203) ; the electronic control unit (202) exchanges voice data with the audio module (201) which plays audio notifications (180) on the headset (301) installed in the rider helmet; the electronic control unit (202) displays visual notifications (190) on the HUD (302) installed of the rider helmet; the rider interacts with the audio module (201) through a microphone (101) installed in the rider helmet providing voice commands .

26