0% found this document useful (0 votes)
51 views20 pages

Electronics 11 02690 v2

Uploaded by

Aron Firmeza
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
51 views20 pages

Electronics 11 02690 v2

Uploaded by

Aron Firmeza
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 20

electronics

Article
Rider in the Loop Dynamic Motorcycle Simulator: An
Instrumentation Strategy Focused on Human Acceptability
Pauline Michel 1 , Samir Bouaziz 1, * , Flavien Delgehier 1 and Stéphane Espié 2

1 Université Paris-Saclay, ENS Paris-Saclay, CNRS, SATIE, 91190 Gif-sur-Yvette, France


2 TS2-SATIE-MOSS, Université Gustave Eiffel, IFSTTAR, 91190 Gif-sur-Yvette, France
* Correspondence: [email protected]

Abstract: Human-in-the-loop driving simulation aims to create the illusion of driving by stimulating
the driver’s sensory systems in as realistic conditions as possible. However, driving simulators
can only produce a subset of the sensory stimuli that would be available in a real driving situation,
depending on the degree of refinement of their design. This subset must be carefully chosen because
it is crucial for human acceptability. Our focus is the design of a physical dynamic (i.e., motion-based)
motorcycle-riding simulator. For its instrumentation, we focused on the rider acceptability of all sub-
systems and the simulator as a whole. The significance of our work lies in this particular approach;
the acceptability of the riding illusion for the rider is critical for the validity of any results acquired
using a simulator. In this article, we detail the design of the hardware/software architecture of our
simulator under this constraint; sensors, actuators, and dataflows allow us to (1) capture the rider’s
actions in real-time; (2) render the motorcycle’s behavior to the rider; and (3) measure and study
rider/simulated motorcycle interactions. We believe our methodology could be adopted by future
designers of motorcycle-riding simulators and other human-in-the-loop simulators to improve their
rendering (including motion) quality and acceptability.

Keywords: physical simulator; driving simulation; human-in-the-loop simulation; sensors/actuators


Citation: Michel, P.; Bouaziz, S.;
instrumentation; hardware/software codesign; dynamic motorcycle simulator
Delgehier, F.; Espié, S. Rider in the
Loop Dynamic Motorcycle Simulator:
An Instrumentation Strategy Focused
on Human Acceptability. Electronics
2022, 11, 2690. https://doi.org/
1. Introduction
10.3390/electronics11172690 Simulators with a human being in the loop appeared during the aviation era (around
World War I) for pilot training. The “Tonneau Antoinette” flight simulator, pictured in
Academic Editor: Wei Hua
Figure 1, is a notable example. It was used for ground training by the French Air Force.
Received: 19 July 2022
Accepted: 24 August 2022
Published: 27 August 2022

Publisher’s Note: MDPI stays neutral


with regard to jurisdictional claims in
published maps and institutional affil-
iations.

Copyright: © 2022 by the authors.


Licensee MDPI, Basel, Switzerland.
This article is an open access article
distributed under the terms and
conditions of the Creative Commons Figure 1. Ground training on an Antoinette simulator “Tonneau Antoinette” (1910).
Attribution (CC BY) license (https://
creativecommons.org/licenses/by/ Driving simulation is another field in which simulators with a human being in the
4.0/). loop can be found. The aim, in this case, is to give a driver the illusion of driving a vehicle.

Electronics 2022, 11, 2690. https://doi.org/10.3390/electronics11172690 https://www.mdpi.com/journal/electronics


Electronics 2022, 11, 2690 2 of 20

Driving simulation is mainly used in the following three areas, with different objectives
and means: research and development in the automotive industry; studies and research
on driving behavior; and (re-)training. Driving simulators consist of the following two
parts: (1) the simulated vehicle; and (2) the simulation environment, i.e., the road network
and the various actors of the situation. The driver in the loop operates the virtual vehicle
composed of a vehicle mock-up and a vehicle model. Both the mock-up and the model
can vary in their degree of complexity. In particular, the vehicle cabin can be fixed-based
or motion-based, with various possible movements and a varying number of sensors and
actuators. A simulator with a motion-based vehicle cabin is called a dynamic simulator.
It is possible to design simulators of different vehicles; however, rendering the vehicle
dynamics at scale one is particularly difficult or costly. Car manufacturers currently use
high-end simulators able to approach scale one for lane-change maneuvers (i.e., for lateral
dynamics). However, they are still limited by the simulators’ size for longitudinal dynamics.
The question is much more complex for motorcycles. A critical issue (among others) for
the design of motorcycle simulators is the impossibility of rendering the centrifugal and
centripetal forces for both right-hand and left-hand bends.
A system with a human being in the loop is defined in opposition to a system designed
to work “next to” the human user. The operator must be identified and integrated as
part of the loop for the whole system to be acceptable from the human’s point of view.
The acronym HUIL (human-in-the-loop) simulation, which can be found in the literature,
describes this type of system. This abbreviation should, in our opinion, be employed rather
than HIL or HITL, which can also describe hardware-in-the-loop simulation (i.e., testing
real hardware in a simulation loop, whereas in our case, we are testing a human being in a
simulation loop).

2. Research Questions
For all HUIL simulators, it is necessary to instrument the system for the following
two purposes: (1) to capture the operator’s actions; and (2) to provide them with sensory
feedback. Figure 2 illustrates the general structure of a HUIL driving simulation. The
driver remotely operates a vehicle model via a mock-up, which is fundamentally different
from driving a vehicle. The more closely the driver interacts with their vehicle to control
its trajectory, the more difficult the driving is to simulate. For cars, the interactions are
mainly through the steering wheel, while for two-wheeled vehicles, the interactions are
much more complex, due to the constraint of maintaining the vehicle’s equilibrium.

Figure 2. The general structure of a human-in-the-loop driving simulation (adapted from [1]). In
blue: driver’s actions; in orange: inputs and outputs of the vehicle model; in green: sensory feedback.

From the simulated vehicle’s point of view, the driver’s actions, i.e., the model’s
inputs, are perceived using sensors. The vehicle’s reactions to these stimuli, i.e., the model’s
outputs, are rendered using actuators. The driver perceives these reactions in terms of
Electronics 2022, 11, 2690 3 of 20

sensory feedback, including visual, kinesthetic, haptic, and auditory feedback. From the
driver’s point of view, sensory feedback is sensor data.
A first challenge for designing a HUIL driving simulator is its instrumentation, as the
human driver is both the initiator of the physics (kinematics and dynamics of the motion)
and the receptor of the various feedback resulting from their actions. A second challenge is
to provide feedback to the driver that matches their expectations according to their driving
experience (this is called the internal model; for more on this, please see the literature on
human motor control research [2–9]). Incongruence between the reactions of the system
and the human driver’s expectations may induce simulator sickness [10–12], which may,
in turn, lead to bias in the results acquired using driving simulators. On the contrary,
the congruence between the reactions of the system and the human driver’s expectations
guarantees the acceptability of the system from the driver’s point of view.
This article presents a rider-in-the-loop dynamic motorcycle simulator. Very few
motorcycle-riding simulators exist today. Some examples are the Honda simulator [13], the
MORIS simulator of the Perceptual Robotics Laboratory of the School of Advanced Studies
of Pisa [14], the simulator of the Mechanical Engineering Department of the University
of Padua [15], the DESMORI simulator of the Würzburg Institute for Traffic Sciences [16]
and the MOTORIST simulator of the Delft University of Technology [17]. They have been
designed to fulfill different objectives, with varying approaches depending on factors
such as the desired application and the areas of expertise of the researchers who designed
them. For this reason, they cannot really be compared. However, to the best of our
knowledge, only a very small portion of the literature describes design strategies for
motorcycle simulators. The existing research is mainly focused on addressing mechanical
and dynamic design constraints and not on system instrumentation. This is why we
suggest an approach focused on human acceptability, which can accommodate other design
specifications. We believe that human acceptability is a crucial point for all applications of
motorcycle simulators. If the simulator is not acceptable for the rider (and thus accepted by
them), then the acquired results’ validity is in question.
Our goal is to design a rider-in-the-loop dynamic motorcycle simulator and validate
the rider acceptability of all its sub-systems and the system as a whole. In order to do so,
the first part of our work was to understand the feedback loop centered on the human rider.
Identifying the rider’s behavior, particularly their reactivity, is necessary to integrate them
as part of the system, while guaranteeing its acceptability.
We argue that simulator sickness, which is a prominent sign of the simulator not being
acceptable, comes from a mismatch between the complexity of the vehicle model and the
fidelity of the sensory cues reproduced by the simulator. We designed a proof-of-concept
(POC) system to explore our hypothesis, focusing on rendering haptic cues on motorcycle
handlebars [1]. We then used this POC system in a pilot experiment with the following two
purposes: (1) validating the rider acceptability of the designed motorized handlebars (with
subjective measures); and (2) comparing controllability and task performance for a simple
control task, depending on whether the complexity of the vehicle model and the fidelity of
the sensory cues were coherent or mismatched [18].
Studying human behavior when confronted with different modalities of interfaces
with a virtual world allowed us to apprehend the insertion of the human in a simulator.
In the second phase of our work, we aim to use this knowledge and combine it with
instrumentation (sensors, actuators) constraints to design a simulator. The difficulty in a
simulator is that there are physical and virtual sensor data to take into account. For example,
in our simulator, the degrees of freedom (DOFs) are only rotations and no translations.
Thus, the speed of the motorcycle is an entirely virtual piece of data; the speed sensor is in
virtual space. Meanwhile, the acceleration data come from a physical sensor, the twist-grip
accelerator. All sensor and actuator data must be physically and time coherent.
Here, we present the design of our motorcycle-riding simulator’s hardware/software
architecture. The simulator consists of two dynamic bodies, the steering column and the
chassis. In the following, we describe these bodies, their assembly, and their electronic
Electronics 2022, 11, 2690 4 of 20

interfaces. We focus, in particular, on the instrumentation of the motorcycle simulator. This


instrumentation was designed to (1) capture the rider’s actions in real-time, (2) render the
motorcycle’s behavior to the rider, and (3) measure and study rider/simulated motorcycle
interactions. Our objective is to increase motorcycle-riding simulators’ rendering quality
and propose a methodology for a simulator design with architecture/virtual vehicle model
adequacy, which guarantees rider acceptability. The novelty of our work resides in this
particular approach. We believe our methodology could be adopted by future designers
of motorcycle-riding simulators and other HUIL simulators, regardless of the desired
application of the simulator, because human acceptability is paramount in all cases. Our
methodology is especially relevant for designing HUIL driving simulators when the vehi-
cle’s trajectory is significantly related to the interactions between the driver and the vehicle,
e.g., two-wheeled vehicles, such as motorcycles and new personal mobility vehicles, such
as electric scooters.

3. Different Modalities for Sensors/Actuators Interfaces: Examples for a


Motorcycle-Riding Simulator
HUIL driving simulators are very complex. In the context of a simulated physical
world, any stimulus or set of stimuli produced by the driver (inputs of the simulator system
measured by sensors) combines with (1) the physical reaction derived from the calculation
of the model of the vehicle in its environment (output actions rendered by actuators) and
(2) the intrinsic effects of the driver’s actions on the physical platform. Consequently,
different interfaces can be used between the driver and the virtual world to capture the
driver’s actions or render the vehicle’s actions and behaviors. In the following section, we
use the notations S for a sensor, A for an actuator, V for virtual, and R for real. The sensors
and actuators that are useful for a motorcycle-riding simulator can be classified as (using
these notations) the following:
• A “simple” interface with a virtual sensor (SV ) or virtual actuator (AV ), noted SV AV .
This interface type is represented schematically in Figure 3a (using the same symbolism
as Figure 2). Figure 3b shows examples of an SV AV interface, including a screen, a
mouse, and a keyboard.

Figure 3. (a) Representation of a virtual sensor/virtual actuator interface (in blue: rider’s actions;
in orange: data to and from the vehicle model); (b) examples of a virtual sensor/virtual actuator
interface: screen, mouse, and keyboard.

• A real sensor (SR ) on its own or in conjunction with a virtual actuator (AV ). This type
of interface (noted SR AV ) is represented schematically in Figure 4a. One must note that
a virtual actuator can be partially real, for example, if it provides kinesthetic or haptic
sensory feedback to the operator. Figure 4b shows an example of this interface type,
Electronics 2022, 11, 2690 5 of 20

a steering wheel joystick. We chose this example despite our interest in motorcycle-
riding simulators because joystick handlebars are much less common. For this type of
interface, there is no physical coupling between the sensor and the actuator.

Figure 4. (a) Representation of a real sensor/virtual actuator interface (in blue: rider’s actions; in
orange: data to and from the vehicle model); (b) an example of a real sensor/virtual actuator interface:
a steering wheel joystick.

• A real sensor (SR ) in conjunction with a real actuator (A R ). This type of interface
(noted SR A R ) is represented schematically in Figure 5a. Figure 5b shows the steering
column of our motorcycle-riding simulator, which is an example of this interface type.
The steering column of our simulator is discussed in more detail in this article. For this
type of interface, the sensor and actuator both provide data to the vehicle model (this
is represented by relations A and B in Figure 5a). Specifically, human actions produce
sensor data (A) and intrinsic motion of the actuator, which becomes input data for the
vehicle model (B: modifying the physical position). The vehicle model controls the
actuator (C). Additionally, there is significant physical coupling between the sensor
and the actuator (D).

Figure 5. (a) Representation of a real sensor/real actuator interface (in blue: rider’s actions; in orange:
data to (relations A and B) and from (relation C) the vehicle model; relation D: physical coupling); (b)
an example of a real sensor/real actuator interface in our motorcycle-riding simulator: the steering
column (copyright: TS2—SATIE—MOSS, Univ Gustave Eiffel).

Selecting interfaces for a simulator among these categories must be carried out accord-
ing to the design specifications, e.g., application domain. One must note that if we were
Electronics 2022, 11, 2690 6 of 20

considering other types of HUIL simulators, we could have imagined other examples of
interfaces, e.g., a PHANToM haptic interface. In the following section, we describe our
motorcycle-riding simulator and classify its rider/virtual motorcycle interfaces using these
categories.

4. Our Motorcycle-Riding Simulator


4.1. General Description
Our motorcycle-riding simulator (pictured during an experiment in Figure 6) was
initially developed in 2006 as part of the SIMACOM research project, supported by the
French National Research Agency (ANR). It has since been used in several human-centered
studies (most recently, in [19–22]) but is still a research object.

Figure 6. Our motorcycle-riding simulator (copyright: TS2—SATIE—MOSS, Univ Gustave Eiffel).

The simulator consists of the following elements:


• Three large, fixed screens (55-inch TVs), assembled edge to edge to obtain a quasi-
continuous visual field. The screens are arranged in the form of a pseudo-circle with
the rider’s head as the center, providing a 130◦ field of view (1920 × 1080 pixels for
each display, approximately 44 PPD);
• A 5.1 sound system;
• A motorized steering column (called dynamic body n◦ 1 in the following sections) with
the following two DOFs: force feedback handlebars and a pseudo-haptic feature that
provides the rider with longitudinal acceleration/braking cues;
• A complete motorcycle chassis, supported by a dynamic platform (dynamic body n◦ 2)
with the following three DOFs: roll (±12◦ ), pitch (±8◦ ), and yaw (±6◦ ). These DOFs
were selected with the help of psycho-physiological studies regarding motorcycle-
riding simulators in general [23] and ours in particular [24–26];
• The original motorcycle command organs, including left and right-hand control pods,
twist-grip accelerator, clutch lever, brake lever and pedal, and gearbox selector.

4.2. Two-Body Structure


The two-body physical structure used for our motorcycle simulator is highlighted in
Figure 7. This structure is inspired by the study of motorcycle dynamics that highlights the
following two groups of DOFs: (1) the specific DOF of the steering column (i.e., steering
angle); and (2) the rotations of the motorcycle (i.e., roll, pitch, and yaw) [27]. From a
computation standpoint, it allows the distribution of the calculations on multiple small
microcontrollers, which brings the calculations closer to the physical actuators.
Electronics 2022, 11, 2690 7 of 20

Figure 7. (a) CAD model of the simulator; (b) photo of the simulator (copyright: TS2—SATIE—MOSS,
Univ Gustave Eiffel).

As previously mentioned, not all the physical phenomena of motorcycle riding can be
physically reproduced by a simulator. The missing physical phenomena must be modeled
and simulated through computations. This “missing physics” is multi-modal. In reality,
all phenomena are linked by time, which is a unifying variable. Therefore, the temporal
coherence of the simulated physics must be guaranteed for the simulation to maintain
acceptability. On a traditional computer (PC), one cannot guarantee the parallelism of
the computations; unless using a specific OS, the behavior is non-stationary, sometimes
favorable, sometimes unfavorable. For this reason, we use dedicated embedded calculators
for each dynamic body, physically parallelizing the calculations.
The vehicle model is also implemented on a dedicated calculator that is as close
as possible to the physical bodies of the motorcycle-riding simulator. In this way, the
maximum latency of the calculations is equal to the longest calculation time, instead of at
least the sum of the calculation times on a PC.
The embedded calculators exchange data with each other and with a centralized PC.
The latter computes a multi-agent traffic model and renders the visual and auditory envi-
ronment to the rider. The PC can also log data if needed (for experimental purposes). The
hardware/software architecture is represented schematically in Figure 8. This representa-
tion highlights that the motorcycle-riding simulator is composed of the following two parts,
as previously mentioned: (1) the simulated vehicle and (2) the simulation environment.

Figure 8. General hardware/software architecture of the motorcycle simulator: simulated vehicle


(in the dotted frame) and simulation environment (in the dashed frame).
Electronics 2022, 11, 2690 8 of 20

The dedicated calculator computes two models of the motorcycle, an engine model
(kinematics of the motorcycle) and a dynamic model. Table 1 summarizes the timing of the
different models computed.

Table 1. Summary of the temporal constraints specific to the different models computed in our simulator.

Model Computation Period Constraint


Dynamic model 5 ms
Motorcycle model Stability of the virtual motorcycle
Engine model 10 ms
Handlebars model 5 ms Sensibility of human haptic perception
Platform model 10 ms Sensibility of human kinesthetic perception
Sensibility of human visual perception (visual
Simulation environment model ≈16 ms (60 Hz) loops usually render images between 60 Hz and
120 Hz)

4.3. Rider/Virtual Motorcycle and World Interfaces


Our simulator combines several types of sensors and actuators that can be either
real or virtual. A simple movement of the rider implies a measure (by a sensor) and
an inherent change in the simulator’s physics (e.g., modification of the center of gravity
of the simulator). Thus, there can be several ways of combining real or virtual sensors
and actuators to establish the link between the rider and the simulated motorcycle, while
maintaining the acceptability of the illusion. Notably, the illusion also strongly relies on
the quality of the simulated (and rendered) road environment and of the behavior of the
various simulated actors (such as other vehicles and pedestrians) [28].
The interfaces used in the motorcycle-riding simulator are classified in Table 2, using
the categories discussed in Section 3.

Table 2. Classification of the sensor/actuator interfaces of the motorcycle-riding simulator.

Sensor/Actuator Virtual Actuator (AV ) Real Actuator (AR )


Displays
Virtual Sensor (SV ) Not applicable
Sound system
Dynamic body n◦ 1: steering column
Real Sensor (SR ) Motorcycle command organs
Dynamic body n◦ 2: chassis

The most complex interfaces are the ones that include a real sensor and a real actuator
because of the inherent coupling brought into play. For this reason, moving forward,
we discuss, in turn, the two dynamic bodies of our motorcycle-riding simulator and the
instrumentation strategy employed for each of them.

5. Dynamic Body n◦ 1: The Steering Column


Because of the instability inherent to inverted pendulums, driving a motorcycle is a
more complex task than driving a car. The rider controls the motorcycle’s trajectory through
the following two torques: (1) the steering torque, i.e., the torque applied by the rider to the
steering column through the handlebars; and (2) the roll torque, resulting from the rider’s
body tilt or weight put on the footrests [29]. This principle is represented schematically
in Figure 9. The two torques result in a steering and roll angle of the motorcycle. This
introduces lateral and gravitational forces that are balanced by centrifugal and centripetal
forces, which allow the rider to maintain their equilibrium.
Electronics 2022, 11, 2690 9 of 20

Figure 9. Schematic representation of the two torques used by the rider to control the trajectory of
their motorcycle: steering torque (in blue) and roll torque (in red).

5.1. The Issue of the Steering Column in Motorcycle Riding


In motorcycle riding, the steering column brings together several torques, which are
as follows: (1) the torque applied by the rider on the handlebars (i.e., the steering torque);
(2) the torque resulting from the gyroscopic effect of the wheel; (3) the torque resulting
from tire/road contact; and finally, (4) the torque indirectly induced by the action of the
rider on the roll of the motorcycle chassis. The position of the handlebars is influenced by
all these torques. In our motorcycle simulator, the state of the handlebars (position, speed
and acceleration) is controlled by the vehicle model. It is evident that there is significant
coupling between the sensor and actuator in the particular case of the handlebars interface.
As previously mentioned, not all the physical phenomena of motorcycle riding can be
physically reproduced by a simulator. For example, in our motorcycle-riding simulator,
there is no wheel or road surface, which means that the torque resulting from tire/road
contact must be modeled and simulated through computations.
While riding, if we consider that the motorcycle is at an equilibrium point, i.e., at stable
vehicle speed and angular positions (steering angle, roll, pitch and yaw), to change its
trajectory, the rider can use the handlebars. This action destabilizes the motorcycle. The
motorcycle is destabilized until it reaches a new equilibrium point. One can consider
a figurative representation of this situation by displacing a ball in a bowl, where the
equilibrium point is the bottom of the bowl. The exact shape of the bowl is defined by
the riding situation at the current time. In the simulation, the bowl is different from what
it would be in reality. This principle is illustrated in Figure 10. From this, it is easy to
understand that the equilibrium point of the simulated motorcycle is different from that of
the real motorcycle. In some cases, the system cannot converge towards an equilibrium. In
this case, the rider loses control, which poses a problem for the acceptability of the simulator.

Figure 10. Schematic representation of the difference in stability parameters between a real and a
simulated motorcycle. In black: figurative stability bowl of the real motorcycle; in orange: figurative
stability bowl of the simulated motorcycle.
Electronics 2022, 11, 2690 10 of 20

One must note that the handlebars of a motorcycle have a dual function from the
rider’s point of view; they serve both a function of control and haptic perception. The
haptic sensory cues at the handlebars are essential for the rider and significantly affect their
riding behavior.
In the case of car driving, the torques involved at the steering wheel are not centrally
located [30]; therefore, their measurement and control are relatively simple. In the case of
motorcycle riding and for high speeds, the variations in the angular position for cornering
maneuvers are of low or even very low amplitude (less than 1◦ ). Moreover, if the speed
increases, the resistive torque increases. This combination of high torque (up to 80 Nm)
and low angular amplitude needs high precision to measure and control; (a) when the rider
applies torque to the motorcycle handlebars, the steering column rotates and (b) producing
high resistive torque with small angular motion is difficult, without inducing mechanical
vibrations (due the frequency of the hardware power controller). That is why we tested and
researched an actuator with minimal vibration. The servo actuators used for positioning
satellite antennas on Earth are excellent candidates. Moreover, such actuators are without
backlash, which is crucial for haptic feedback.
In order to operate in a closed loop, the simulator must be able to measure the torque
and to use the value acquired without modifying the position of the handlebars, which is a
result of the vehicle model calculation, and this must be within an acceptable time frame
for the stability of the model and the haptic perception of the rider.
Based on these considerations, we can conclude that the design of a physical motor-
cycle steering column for a simulator is a complex problem that requires technological
choices, taking into account the acceptability from the point of view of the rider in the loop.

5.2. Motorized Handlebars Design


Our motorcycle simulator’s initial handlebars motorization system (a DC motor and
a pulley-belt system) was derived from a car simulator’s force feedback steering wheel.
It could not guarantee closed-loop operation (i.e., it was not possible to measure the
steering torque without changing the state of the handlebars). That is why we replaced it.
Table 3 summarizes the design objectives derived from the detailed considerations and the
solutions we found.

Table 3. Summary of the design objectives and solutions found for the motorized handlebars system.

Design Objective Design Choice


Measuring the steering torque without movement of the
handlebars “Hardly reversible” servo-actuator (gear ratio R = 160)
Vibration-free high-torque control
Positioning:
backlash-free Servo-actuator with “backlash-free” gears (HarmonicDrive)
Within an acceptable time for haptic perception Compatible loop frequency (see [1])

These choices have their inherent drawbacks. The first one to consider is possible elec-
tromagnetic compatibility (EMC) issues (i.e., the need for electrical isolation of all sensors
and sub-systems) because for the performances specified, the servo-actuator is powered
with a three-phased 380 V supply (vs. a low voltage power supply in the initial system). An
EMC problem can cause many dysfunctions, for example, for displays. The second issue is
that the type of actuator chosen (i.e., an actuator for high-precision positioning) is not made
to motorize systems with a mechanical stopper. The motorcycle handlebars are limited by
a left/right mechanical stopper; the handlebars are blocked by the frame at ±35◦ . As the
torque involved can be of high value (around 160 Nm in the case of our servo-actuator),
this poses a significant risk of actuator breakage. To prevent this, we installed a mechanical
torque limiter, in addition to software securities.
Electronics 2022, 11, 2690 11 of 20

5.3. Steering Column Sensor/Actuator Dataflows


We have mentioned that the steering column sub-system (dynamic body n◦ 1) combines
the following two aspects: (1) steering angle control (the motorized handlebars) and
(2) handlebars/rider distance control. For the former, the new motorization system is a
servo-actuator mechanically coupled to the steering column. For the latter, a linear leg and
a brushless actuator are used. The localization of the sensors and actuators of the steering
column is detailed in Figure 11. The amplitudes of all movements can be reduced/increased
independently and “on the fly” using configurable gains.

Figure 11. (a) Localization of the sensors and actuators of the motorized handlebars; (b) CAD
model of the handlebars/rider distance control system and localization of the sensors and actuators
(copyright: TS2—SATIE—MOSS, Univ Gustave Eiffel).

The data exchanged concerning the steering column are summarized in Table 4.

Table 4. Synthesis of the data exchanged concerning the dynamic steering column.

Data Period Transmission Method Sensor/Actuator Computed Information


Handlebar actuator
5 ms Local CAN bus n◦ 1 Steering angle
Actuator position (encoder)
(M 1 and C 2 )
Handlebars linear
10 ms Local CAN bus n◦ 2 Front leg actuator
displacement
Handlebar actuator
Actuator velocity 5 ms Local CAN bus n◦ 1 Steering angular speed
(encoder)
(M and C)
10 ms Local CAN bus n◦ 2 Front leg actuator Handlebars linear speed
Actuator torque Handlebar actuator
5 ms Local CAN bus n◦ 1
(M and C) (torque sensor) Steering torque
Force (M) 5 ms Local CAN bus n◦ 1 Strain gauge
1 2
M: Measured. C: Controlled.

5.4. The Steering Angle DOF


If we consider the schematic representation of a real sensor/real actuator interface in
Figure 5a, the sensor/actuator interface of the steering angle DOF is characterized by the
following relationships:
• A and B includes the force data from the sensors (directly representing the human
action in the form of steering and roll torques) and handlebar actuator position and
velocity (modified by human actions);
• C includes the handlebar actuator and left and right actuators of the chassis, all
controlled by the vehicle model;
Electronics 2022, 11, 2690 12 of 20

• D includes the coupling that is necessary for the human acceptability of the simulator.
The actions of the steering and roll torques need to be combined when controlling the
handlebars to create motion that is acceptable, i.e., physically and time coherent.
The steering torque is computed from the actuator and strain gauge data. The relation-
ship between them was determined through a process of calibration. Since the relationship
is not dependent on the rider (only on the steering column assembly), the calibration
process does not need to be repeated for each rider. An example of the data used for
determining the relationship between steering torque and actuator torque/strain gauge
data is shown in Figure 12.

Figure 12. Data used for determining the steering torque as a function of actuator data and strain
gauge data (data collected in the case of our POC): torque measured by the handlebar actuator
(in Nm) as a function of the value measured by the strain gauge (dimensionless 12 bits value ranging
from 0 to 4095) without human action.

The flowchart in Figure 13 shows the computation process of the steering torque. The
computed value is used as an input of the motorcycle model.

Figure 13. Flowchart of the steering torque computation.


Electronics 2022, 11, 2690 13 of 20

To control the motorized handlebars, the microcontroller computing the handlebars


model can communicate with the dedicated servo-controller via a local CAN bus with
the CANopen protocol. However, this protocol is verbose and slow, posing a problem
both for the control and for the period at which feedback data are available. We have,
therefore, chosen to use a ±10 V analog input reference, rather than a reference sent over
the local CAN bus, to control the servo-actuator. For the encoder data acquisition, we
implemented direct decoding of the sine/cosine encoder signals by using an FPGA module
(DE0-Nano) because all other protocols (EnDat 2.1/01 protocol, which uses RS 485, or local
CANopen data) are too slow to guarantee real-time behavior (i.e., 200 Hz or higher for
haptic perception).

5.5. Results and Discussion


Because the steering column constitutes a complicated issue (as discussed), we have
conducted a primary acceptability test campaign for the new design of the motorized
handlebars [18]. This pilot experiment was conducted using our motorized handlebars
POC system for rendering haptic cues and a head-mounted display (HMD) for visual
feedback. The handlebars sub-system was validated using subjective measures and task
performance (objective measures) in a simple control task, stabilizing a simulated pendu-
lum’s oscillations. Figure 14 shows an example of the results obtained during this pilot
experiment regarding the computed steering torque.

Figure 14. Example of collected data: torque measured by the actuator and computed steering torque
(both in Nm) as a function of time (elapsed since the beginning of the experiment, in s) for two
subsequent control actions of a participant during the pilot experiment.

Figure 15 shows an extract of the results of our pilot experiment that highlights the
physical and temporal coherence of the signals and cues. It shows that the physical action
of the participant is captured by the motorized handlebars system and that the system is
controlled according to it. The results also support the human acceptability of the system
from an objective standpoint; the participants were asked to push the pendulum so that
its endpoint for the oscillation was in the zone delimited by the dotted lines. Here, the
participant successfully adjusts their action from one repetition to another (Figure 15a:
pendulum not pushed far enough; Figure 15b: pendulum reached the goal zone).
Electronics 2022, 11, 2690 14 of 20

Figure 15. Example of pilot experiment results: pendulum angle (predicted/without human ac-
tion vs. actual/with human action, in ◦ ), pendulum speed (predicted/without human action vs.
actual/with human action in ◦ /s), and steering torque (in Nm) as a function of time (elapsed since
the beginning of the experiment, in s) for two successive tries: (a) unsuccessful; (b) successful.

The preliminary results focused on haptic rendering on the motorcycle handlebars


align with our design and instrumentation strategy; this design significantly improved the
quality of the haptic cues and, therefore, the acceptability for the human operators/riders.
We have, therefore, fully integrated this work into our motorcycle simulator. This inte-
gration is carried out via the global CAN bus (see Figure 8). We then applied the same
instrumentation strategy to the second dynamic body of the motorcycle simulator, the
motorcycle chassis. This is what we describe in the next section.

6. Dynamic Body n◦ 2: The Motorcycle Chassis


6.1. Chassis Sensor/Actuator Dataflows
The motorcycle chassis is adapted from a real Yamaha YBR 125 cm3 and mounted on a
three DOF dynamic platform, as follows:
• Roll and pitch, rendered by two linear legs (at the front of the simulator) and brushless
actuators;
• Yaw, rendered by a slide (at the rear) and a brushless actuator.
The localization of the sensors and actuators of the motorcycle chassis is detailed
in Figure 16. As for the steering column, the amplitudes of all movements can be re-
duced/increased independently and “on the fly” using configurable gains.
The data exchanged concerning the motorcycle chassis are summarized in Table 5.
Table 5. Synthesis of the data exchanged concerning the dynamic motorcycle chassis.

Transmission
Data Period Sensor/Actuator Computed Information
Method
Left leg actuator Left leg elongation
Actuator position Chassis roll and pitch angles
(M 1 and C 2 )
10 ms Local CAN bus n◦ 2 Right leg actuator Right leg elongation
Rear slide actuator Rear slide displacement Chassis yaw angle
Left leg actuator Left leg velocity Chassis roll and pitch angular
Actuator velocity speeds
10 ms Local CAN bus n◦ 2 Right leg actuator Right leg velocity
(M and C)
Rear slide actuator Rear slide velocity Chassis yaw angular speed
Left force sensor
Force (M) 5 ms Analog inputs Roll torque
Right force sensor
1 M: Measured. 2 C: Controlled.
Electronics 2022, 11, 2690 15 of 20

Figure 16. (a) Localization of the force sensors (used for roll torque computation); (b) CAD model
of the front legs (used for roll and pitch rendering) and localization of the sensors and actuators;
(c) CAD model of the rear slide (used for yaw rendering) and localization of the sensors and actuators
(copyright: TS2—SATIE—MOSS, Univ Gustave Eiffel).

6.2. The Roll DOF


The roll motion is essential for the stabilization and guidance of a motorcycle. However,
in motorcycle-riding simulations, as already stated, it is impossible to render centrifugal
and centripetal forces. Simulator designers use different strategies to cope with this absence,
combining visual tilt and chassis roll angles [31–33]. Depending on the architecture of
their simulator, they try to establish a compromise between tilting the motorcycle with a
sufficient angular speed to signal the beginning of the rolling movement, while limiting the
roll angle to prevent any sensation of falling or critical imbalance.
The solution used in our simulator was to limit the chassis roll angle and add a visual
roll angle [26,34] by tilting the image in the opposite direction of the turn, to give the
rider the sensation of getting closer to the ground [35]. The visual gains can be configured
depending on the needs of the experiment.
To compute the roll torque, we used force sensors situated on the top of each of our
simulator’s two front legs. These force sensors are tensile/compressive force transducers
(note: only compressive force is pertinent for our case). The sensors’ positions are essential.
We chose to align them on the horizontal chassis plane, which is lower than the center of
gravity of the motorcycle plus the rider. This means that depending on the strategy used
by the rider (either modification of their center of gravity by holding on to the tank with
their legs or pushing on the footrests or a mixed action), the capture of their action may be
more or less effective.
Electronics 2022, 11, 2690 16 of 20

For this choice of instrumentation, the simulated motorcycle is systematically self-


falling if weight compensation is missing. This is because the legs’ force sensors measure
the rider’s weight; this value changes depending on the chassis roll angle. Therefore, we
take into account the rider’s weight when computing the roll torque from the force sensor
data. We implemented a correction of the measured force sensor values depending on the
chassis tilt (roll angle).
When the rider first is in position on the motorcycle chassis at the beginning of the
experiment, their weight is measured by the difference between the force sensor data for
the chassis on its own and with the rider on it. Knowing this weight, we can compute the
corrected force sensor data for all roll angles by using a relationship we found through a
calibration process. An example of the data used for calibration is shown in Figure 17.

Figure 17. Data used for determining the corrected force values as a function of chassis roll angle:
values measured by the force sensors (dimensionless 12 bits values ranging from 0 to 4095) as a
function of chassis roll angle (in ◦ ) without human action: (a) left force sensor; (b) right force sensor.

The flowchart in Figure 18 shows the computation process of the roll torque. The
computed value is used as an input of the motorcycle model.

Figure 18. Flowchart of the roll torque computation.


Electronics 2022, 11, 2690 17 of 20

The actions of the roll and steering torques need to be combined when controlling the
platform to create a motion that is acceptable, i.e., a physically and time coherent motion.

6.3. Results and Discussion


Given the complexity of the architecture of our rider-in-the-loop motorcycle simulator,
as we have tried to describe in this article, the results we have at this point essentially
concern the motorized handlebars sub-system (presented above, as well as in our previous
work), in addition to the preliminary results, which concern the temporal coherence of the
complete system.
Figure 19 shows that there is an action-reaction effect between an action of the rider
(in the form of an impulse in steering torque here) and the reaction of the virtual motorcycle
(in the form of the resulting handlebar and chassis motion). The effect is not direct because
the input stimulus passes through several models to compute the physical response, in-
cluding the motorcycle dynamic model, handlebar behavior model, and chassis behavior
model. The results are, therefore, complex to characterize.
In the results pictured in Figure 19, the rider’s input stimulus, i.e., the steering torque,
is initiated at 16.911 s. The measured handlebars speed (an output of the vehicle model and
the handlebars model) starts to change at 16.916 s, i.e., 5 ms later. This time delay fits the
design constraints for the steering column dynamic body (as described previously). The
difference between the values measured by the left and the right force sensor, an image
of chassis roll motion, starts to change at 16.938 s. This means that the chassis starts to
be significantly tilted 27 ms after the input stimulus. This time delay is longer than the
design constraints for this dynamic body, i.e., the actualization of the chassis DOFs at a
period of 10 ms. However, this does not mean our expectations are not met; the roll DOF is
significantly more limited in amplitude than the steering angle DOF. As a result, even if the
roll angle computed by the motorcycle model starts to change after 10 ms, significant roll
motion of the chassis (an output of the platform model) happens later. These preliminary
results are promising.

Figure 19. Experimental measures illustrating the action-reaction effect between an action of the
rider in terms of steering torque, represented here by the value measured by the strain gauge
(dimensionless 12 bits value ranging from 0 to 4095, in purple) and the reaction of the virtual vehicle,
represented here by the actual speed of the handlebars (value in c◦ /s, in lavender) and difference
in the values measured by the left and the right force sensor of the chassis (dimensionless value
between −123 and 123, in blue-green), which signifies the chassis motion. All values are represented
as a function of time (elapsed since the beginning of the experiment, in s).
Electronics 2022, 11, 2690 18 of 20

It is still necessary to set up several experimental campaigns with both subjective and
objective variables of interest. Further results that we are particularly interested in include
rider acceptability of our simulator (for motorcycle riders of different backgrounds and
riding experience) and its controllability. These aspects are determining factors in whether
or not our simulator will fit our expectations and needs for our use in rider-centered
applications and studies.
To summarize, designing a HUIL dynamic motorcycle simulator is one task but taking
into account its acceptability for the rider (in the simulation loop) is another.

7. Conclusions
This article details our motorcycle-riding simulator’s design, divided into two mobile
bodies, the chassis and the handlebars. In particular, we have detailed the instrumentation
choices made (including optimal data frequencies) for each of these two bodies to solve
the different issues raised by the motorcycle dynamics’ complexity and the complexity of
building a simulation tool with a human being in the loop. Our findings have allowed us
to identify design strategies for motorcycle-riding simulators and, in general, human-in-
the-loop simulators, taking into account the issue of acceptability.
The motorcycle simulator as a whole works. Because the steering column constitutes a
challenging issue, a primary acceptability test campaign concerning the new design of the
motorized handlebars has already been conducted [18]. A new campaign has been planned
to validate the complete system. It will be conducted in partnership with colleagues in
experimental psychology and involve riders from different backgrounds (such as age,
riding experience, and type of motorcycle).
Furthermore, from an instrumentation point of view, we plan to implement additional
corrections of sensor data depending on motorcycle speed to compensate for dynamic
effects, such as the inertia of the dynamic platform, plus rider assembly. We also plan to
replace the CAN (1 Mbits/s) buses with CAN FD buses (8 Mbits/s with larger data frames)
to improve transmission reliability, knowing that for our application, a substantial amount
of data is transmitted at a relatively high frequency.
From a “human-centered” point of view, we will soon conduct an experiment on
the impact of the simulator’s architectural complexity vs. the vehicle model complexity
on the feeling of presence and virtual trajectory control. One must recall that, in driving
simulations, the driver does not drive a real vehicle but remotely operates a vehicle model,
relying on the subset of the sensory stimuli of the real driving situation reproduced by
the simulator. We hypothesize that better control of the vehicle is possible when vehicle
model complexity and simulator architectural complexity (which is the limiting factor
for sensory fidelity) are compatible with each other. Good control minimizes the erratic
movements of the virtual vehicle, and the occurrence of simulator sickness is, thus, reduced.
The design of the simulator presented here, in addition to demonstrating improved rider
acceptability, is well adapted to our future studies, since many aspects are independently
configurable, including vehicle model (implemented on a dedicated calculator) and be-
haviors of the various degrees of freedom of the motion rendering (implemented on other
dedicated calculators).

Author Contributions: All authors have contributed equally to the work described in the manuscript.
Conceptualization, F.D.; methodology, F.D.; software, F.D.; validation, F.D.; resources, F.D.; Writing—
original draft, P.M.; writing—review and editing, P.M., S.B. and S.E.; visualization, P.M. All authors
have read and agreed to the published version of the manuscript.
Funding: This research received no external funding.
Acknowledgments: The authors would like to thank Adrian Braleret and Rémi Legroux of the
Laboratoire de Mécanique Paris-Saclay (LMPS) for their advice and expertise on the conception of
mechanical systems. Specifically, many thanks to them for designing and producing the torque limiter
that allows us to protect our handlebar motorization system.
Conflicts of Interest: The authors declare no conflict of interest.
Electronics 2022, 11, 2690 19 of 20

References
1. Michel, P.; Espié, S.; Bouaziz, S. Motorcycle Riding Simulator Controllability and Simulator Sickness: A Proof-of-Concept System.
In Proceedings of the 11th International Conference on Simulation and Modeling Methodologies, Technologies and Applications
(SIMULTECH 2021), Online Streaming, 7–9 July 2021; pp. 406–413. [CrossRef]
2. Shadmehr, R.; Mussa-Ivaldi, F.A. Adaptive representation of dynamics during learning of a motor task. J. Neurosci.
1994, 14, 3208–3224. [CrossRef] [PubMed]
3. Wolpert, D.M.; Ghahramani, Z.; Jordan, M.I. An Internal Model for Sensorimotor Integration. Science 1995, 269, 1880–1882.
[CrossRef] [PubMed]
4. Wolpert, D.M.; Kawato, M. Multiple paired forward and inverse models for motor control. Neural Netw. 1998, 11, 1317–1329.
[CrossRef]
5. Kawato, M. Internal models for motor control and trajectory planning. Curr. Opin. Neurobiol. 1999, 9, 718–727. [CrossRef]
6. Todorov, E.; Jordan, M.I. Optimal feedback control as a theory of motor coordination. Nat. Neurosci. 2002, 5, 1226–1235. [CrossRef]
[PubMed]
7. Wolpert, D.M.; Diedrichsen, J.; Flanagan, J.R. Principles of sensorimotor learning. Nat. Rev. Neurosci. 2011, 12, 739–751. [CrossRef]
8. McNamee, D.; Wolpert, D.M. Internal Models in Biological Control. Annu. Rev. Control Robot. Auton. Syst. 2019, 2, 339–364.
[CrossRef]
9. Pierella, C.; Casadio, M.; Mussa-Ivaldi, F.A.; Solla, S.A. The dynamics of motor learning through the formation of internal models.
PLoS Comput. Biol. 2019, 15, e1007118. [CrossRef]
10. Oman, C.M. Motion sickness: A synthesis and evaluation of the sensory conflict theory. Can. J. Physiol. Pharmacol.
1990, 68, 294–303. [CrossRef]
11. Bos, J.E.; Bles, W. Theoretical considerations on canal-otolith interaction and an observer model. Biol. Cybern. 2002, 86, 191–207.
[CrossRef]
12. Bos, J.E.; Bles, W.; Groen, E.L. A theory on visually induced motion sickness. Displays 2008, 29, 47–57, Health and Safety Aspects
of Visual Displays. [CrossRef]
13. Chiyoda, S.; Yoshimoto, K.; Kawasaki, D.; Murakami, Y.; Sugimoto, T. Development of a motorcycle simulator using parallel
manipulator and head mounted display. In Proceedings of the International Conference on Motion and Vibration Control
(MOVIC 2002), Saitama, Japan, 19–23 August 2002; pp. 599–602. [CrossRef]
14. Ferrazzin, D.; Barbagli, F.; Avizzano, C.A.; Di Pietro, G.; Bergamasco, M. Designing new commercial motorcycles through a highly
reconfigurable virtual reality-based simulator. Adv. Robot. 2003, 17, 293–318. [CrossRef]
15. Cossalter, V.; Lot, R.; Massaro, M.; Sartori, R. Development and validation of an advanced motorcycle riding simulator. Proc. Inst.
Mech. Eng. Part D J. Automob. Eng. 2011, 225, 705–720. [CrossRef]
16. Will, S. Development of A Presence Model for Driving Simulators Based on Speed Perception in A Motorcycle Riding Simulator.
Ph.D. Thesis, Julius-Maximilians-Universität Würzburg, Würzburg, Germany, 6 June 2017.
17. Grottoli, M. Development and Evaluation of A Motorcycle Riding Simulator for Low Speed Maneuvering. Ph.D. Thesis, Delft
University of Technology, Delft, The Netherlands, 2021. [CrossRef]
18. Michel, P.; Bouaziz, S.; Espié, S. Adequacy of models and sensory stimuli: How does it impact the controllability of systems?
In Proceedings of the Driving Simulation Conference Europe 2021 VR (DSC 2021), München, Germany, 14–17 September
2021; pp. 65–72.
19. Boets, S.; Espié, S.; Delhaye, A.; Teuchies, M. Impact of a Head-Up Display on motorcycle riding: A pilot study using a motorcycle
riding simulator. In Proceedings of the 13th International Motorcycle Conference (IMC 2020), Online Streaming, 5–6 October
2020; pp. 95–106.
20. Bougard, C.; VanBeers, P.; Sauvet, F.; Drogou, C.; Guillard, M.; Dorey, R.; Gomez-Merino, D.; Dauguet, J.; Takillah, S.; Espié, S.; et al.
Motorcycling performance and sleepiness during an extended ride on a dynamic simulator: Relationship with stress biomarkers.
Physiol. Meas. 2020, 41, 104004. [CrossRef]
21. Bougard, C.; Davenne, D.; Moussay, S.; Espié, S. Evaluating sleep deprivation and time-of-day influences on crash avoidance
maneuvers of young motorcyclists using a dynamic simulator. J. Saf. Res. 2021, 78, 36–46. [CrossRef]
22. Michel, P.; Nedjari Benhadj Ali, H.; Bouaziz, S.; Delgehier, F.; Espié, S. Motorcycle riders vs. Automated vehicles in a congested-
traffic situation: A simulator study. In Proceedings of the Driving Simulation Conference Europe 2022 VR (DSC 2022), Strasbourg,
France, 14–16 September 2022.
23. Yamasaki, G.; Aoki, K.; Miyamaru, Y.; Ohnuma, K. Development of motorcycle training simulator. JSAE Rev. 1998, 19, 81–85.
[CrossRef]
24. Nehaoua, L.; Hima, S.; Arioui, H.; Séguy, N.; Espié, S. Design and Modeling of a New Motorcycle Riding Simulator. In Proceedings
of the IEEE American Control Conference (ACC’07), New York, NY, USA, 9–13 July 2007; pp. 176–181. [CrossRef]
25. Arioui, H.; Nehaoua, L.; Hima, S.; Séguy, N.; Espié, S. Mechatronics, Design, and Modeling of a Motorcycle Riding Simulator.
IEEE/ASME Trans. Mechatron. 2010, 15, 805–818. [CrossRef]
26. Shahar, A.; Dagonneau, V.; Caro, S.; Israël, I.; Lobjois, R. Towards identifying roll motion parameters of a motorcycle simulator.
Appl. Ergon. 2014, 45, 734–740. [CrossRef]
27. Cossalter, V. Motorcycle Dynamics; Lulu.com: Morrisville, NC, USA, 2006.
Electronics 2022, 11, 2690 20 of 20

28. Espié, S.; Gauriat, P.; Duraz, M. Driving Simulators Validation: The Issue of Transferability of Results Acquired on
Simulator. In Proceedings of the Driving Simulation Conference North America (DSC-NA 2005), Orlando, FL, USA,
30 November–2 December 2005.
29. Cossalter, V.; Doria, A.; Lot, R. Steady Turning of Two-Wheeled Vehicles. Veh. Syst. Dyn. 1999, 31, 157–181. [CrossRef]
30. Mohellebi, H.; Kheddar, A.; Espié, S. Adaptive Haptic Feedback Steering Wheel for Driving Simulators. IEEE Trans. Veh. Technol.
2009, 58, 1654–1666. [CrossRef]
31. Kageyama, I.; Tagami, N. Development of a riding simulator for two-wheeled vehicles. JSAE Rev. 2002, 23, 347–352. [CrossRef]
32. Cossalter, V.; Lot, R.; Rota, S. Objective and subjective evaluation of an advanced motorcycle riding simulator. Eur. Transp. Res. Rev.
2010, 2, 223–233. [CrossRef]
33. Benedetto, S.; Lobjois, R.; Faura, V.; Dang, N.T.; Pedrotti, M.; Caro, S. A comparison of immersive and interactive motorcycle
configurations. Transp. Res. Part F Traffic Psychol. Behav. 2014, 23, 88–100. [CrossRef]
34. Lobjois, R.; Dagonneau, V.; Isableu, B. The contribution of visual and proprioceptive information to the perception of leaning in a
dynamic motorcycle simulator. Ergonomics 2016, 59, 1428–1441. [CrossRef] [PubMed]
35. Stedmon, A.W.; Hasseldine, B.; Rice, D.; Young, M.; Markham, S.; Hancox, M.; Brickell, E.; Noble, J. ‘MotorcycleSim’: An
Evaluation of Rider Interaction with an Innovative Motorcycle Simulator. Comput. J. 2011, 54, 1010–1025. [CrossRef]

You might also like