Abstract

The rising interest in sustainable modes of transportation has increased demand for the design and implementation of bicycle facilities in the United States. However, as compared to the vehicular mode, bicycle facilities have relatively less development, research, and understanding. The availability of a bicycling simulator has the potential to contribute to the understanding of bicycle facility design and bicyclist behavior. The design and construction of a bicycling simulator differs from a driving simulator in many ways. A bicycling simulator requires interfaces for bicycle speed, braking, and steering angle as well as a visual interface. In addition, a representation of a real-world network, including pavement, buildings, the sky and background, and fixed and moving objects, needs to be modeled using a simulator engine. This paper presents the details of the ZouSim bicycling simulator development and the tradeoffs associated with various design decisions, such as the choice of a steering sensor and graphical display. A sample application of a wayfinding and detection markings study illustrates the use of ZouSim. The authors hope that this article will encourage other researchers who conduct research in sustainable cities to explore the use of bicycle simulators for improving bicycle facility design and operations.

1. Introduction and Literature Review

In terms of sustainable cities and sustainable transportation, the United States lags behind many other countries. Over the past decade, the increase in interest in sustainable transportation modes in the United States has led to the development of several new bicycle and pedestrian programs. There are several such examples in the past three transportation legislations. SAFETEA-LU (Pub. L. 109-59 (2005)) funded the nonmotorized transportation pilot program involving Columbia (Missouri), Marin County (California), Minneapolis (Minnesota), and Sheboygan County (Wisconsin). MAP-21 (Pub. L. 112-141 (2012)) made bicycling and walking safety eligible for Section 402, the State and Community Highway Safety Grant Program. And the FAST Act (Pub. L. 114-94 (2015)) added nonmotorized safety to the priorities listed in Section 405, the National Safety Priority Program. With the rise in attention on sustainable modes of transportation, there are greater demands on the traffic engineering community to design bicycle facilities that are safe and efficient. However, unlike traffic control for the vehicular mode, there is relatively less research, knowledge, and standards for the bicycle mode. For example, MUTCD’s [1] content on bicycle signs, markings, and signals is relatively brief. A bicycling simulator can be one instrument for testing and investigating design alternatives for bicycle facilities.

Simulator use in transportation has expanded greatly in the past decade with driving simulators being a popular mode. Van Leeuwen [2] found 2752 papers that included the words “driving simulator” in the title, abstract, or keywords between 2000 and 2013. Undoubtedly, the increase in popularity of driving simulator research is due to the usefulness of the driving simulator for a variety of fields, the affordability of such systems, and improvements in graphical, software, and computing technologies, especially the emerging interactive virtual reality (VR) technology. In contrast, there is a dearth of literature on bicycling simulators.

Some bicycling simulators have focused on the modeling of bicycle dynamics, moment, and haptic feedback. Shin and Lee [3] described a bicycling simulator developed at Korea Advanced Institute of Science (KAIST). The KAIST simulator is focused on accurately producing a rider’s net moment to develop the control forces for a six-degrees-of-freedom motion platform. He et al. [4] discussed bicycling simulator dynamics modeling, including the submodels for stability and vibration. A bicycling simulator developed at the Shanghai Jiao Tong University [5] focused on complex rider-bicycle dynamic modeling (RBDM). Using the inputs of steering angle, rear wheel angular velocity, lean angle of the rider, braking torques, and terrain slope, the RBDM calculates several torques (e.g., pedaling and steering) and various angles of movement. The FIVIS bicycling simulator [6] used a feedback system that moved the bicycle platform and simulates turning and balancing situations. Lee et al. [7] at Delft University based a simulator around a stationary bicycle with a haptic handlebar. The main concern was to investigate the effect of haptic feedback on the handlebars.

Some bicycling simulators were developed for the purpose of improving medical rehabilitation. Jeong et al. [8] designed a bicycling simulator to investigate its use for improving postural balance and equilibrium sense control for patients undergoing rehabilitation. Their simulator was based on a stationary bicycle and used a potentiometer to measure direction (either centered, right, or left) and a cadence sensor to measure cycling speed. They incorporated a spring-based tilt device to allow the rider to pitch and rotate since the bicycle was a stationary bicycle. Kim et al. [9] also used a bicycling simulator based on a stationary exercise bicycle for rehabilitation training of postural balance of elderly patients. In addition to medical uses, some simulators focus on human factors. The bicycle simulator at the University of Iowa has been used to study the ways bicyclists cross two lanes of traffic [10] and the influences of a virtual peer on the crossing behavior of child cyclists [11].

In summary, the existing published bicycling simulator literature can be classified into three general categories. One category involves the exact replication of a rider’s moment, motion generation, and haptic feedback. The second category involves the application of medical rehabilitation. The third category involves the investigation of human factors in bicycling. In addition, there are commercial systems that focus on fitness and training, including the incorporation of real videos of famous races or routes, such as the Tour de France. However, there is scarce literature focused on the development and use of bicycling simulators for traffic engineering and safety purposes.

The ZouSim Bicycling Simulator discussed in this paper contributes to the advancement of bicycle research in several ways. First, the paper documents the details of the bicycling simulator development for traffic engineering purposes. Much of the existing literature is focused on precise modeling of bicycle dynamics, including balancing and the inclusion of full six degrees of motion. Thus, the researchers were from the mechanical engineering and computer science departments. Such detailed physical modeling is unnecessary for most traffic engineering studies in civil engineering. For example, many types of traffic control studies can be conducted on level ground where the details of the terrain and the resulting bicycle-terrain interactions do not need to be replicated exactly. Second, this paper focuses on a simulator suitable for studying facility design, including geometrics, signage, markings, and traffic control. Both rider safety and mobility can be investigated using this type of simulator. Such studies would differ from other applications such as medical rehabilitation or training. Third, existing literature is overwhelming from outside the United States. This is unsurprising since other countries use and rely upon bicycling much more than the U.S. Since the U.S. differs from other countries in terms of standards, regulations, and practice for bicycling, a simulator must be suitable for U.S. conditions. This paper documents the development process and discusses design tradeoffs so as to assist others who seek to use this valuable tool to help improve bicycle facilities.

2. Simulator Development

2.1. Hardware

ZouSim’s physical hardware design is composed of the following components: bicycle, base, measurement interfaces (i.e., speed, braking, and steering), and graphical interface. The main consideration in the selection of a bicycle is the ability to accommodate a wide range of rider demographics. This is because the human participant studies that utilize ZouSim involve a wide range of characteristics, including differing gender, height, riding ability, trip purpose, and age. A small Trek 800 bike with a 13” women’s frame and 26” wheels was chosen in order to accommodate diverse riders. The use of a single bicycle for different-sized riders is not ideal; however, instrumenting and customizing multiple bicycles proved too costly. Using handle bar and seat adjustments, all human participants felt comfortable riding ZouSim bicycle. Since there are fewer bicyclists who use racing bikes, a more common trail bike style was used.

The considerations for the bicycle base design are to allow for wheel rotations, offer realistic resistance, and provide stability. The use of an exercise or fixed bicycle was quickly ruled out since ZouSim’s goal was to simulate street bicycles used on road networks. The final base design involved a bicycle trainer stand to allow for free wheel rotations and to offer a measure of realistic resistance. A trainer stand was attractive because of the availability of a variety of manufacturers and trainer capabilities. Figure 1 shows the bicycle hardware components. As shown, the trainer stand elevates the rear wheel so that it can be rotated. The stand that is currently used has a fixed amount of resistance, although it is adjustable. In the future, variable resistance models, including electronically controlled models, will be investigated for applications involving grade changes. The trainer stand is mounted on top of a 0.61 m × 1.83 m (two feet by six feet) wood base for stability. Even though the aforementioned base design provides many benefits, it does have one main drawback; since only the rear wheel can rotate, the front wheel brakes are not used. In practice, front and rear wheel brakes are usually used together (e.g., in a three to one ratio); thus, the loss of the front brake results in some loss of realism. However, there are many applications of ZouSim that does not involve braking as a main component of the study. Since the front wheel needs to turn to allow the bicycle to change directions, it was difficult to design a trainer stand for the front wheel.

2.2. Speed

Several options were explored for measuring the speed or the longitudinal movement rate, including bicycle computers/speedometers and custom hardware. A bicycle computer uses sensors and/or global positioning system (GPS) to inform a bicycle rider of useful information such as speed, cadence, and distance traveled. Such a computer can have the wireless communication capabilities to interact with smart phones or other Bluetooth-enabled devices. The GPS-based computers are not suitable for use in ZouSim because the bicycle is stationary.

Non-GPS-based computers use magnetic sensors attached to the wheel spoke or crank arm to measure rotations. These magnetic sensors operate on the principle of the Hall effect, which determines that force on electrons is caused by flow through a magnetic field [12]. Thus, the output voltage of a Hall effect sensor is determined by the strength of the magnetic field. When a magnet is placed on a wheel spoke, the speed of the bicycle can be measured directly by detecting the passage of the magnet. In this way, a magnet is placed on the crank arm, the cadence or pedaling rate is measured. A magnet sensor is placed somewhere on the bicycle frame assembly such as the seat stay. Cadence is important for physical fitness applications, whereas ZouSim applications are concerned mainly with bicycle speed.

One minor drawback of bicycle computers is that data must be transmitted digitally to the computer, and this requires the simulation engine to communicate with this additional device. Therefore, software routines will have to poll the bicycle computer for speed data on a regular basis. Because of the desire to integrate the communications to all sensors, a custom circuit was developed for ZouSim instead of adapting commercially available bicycle computers.

The ZouSim speed measurement hardware has three main components: a rotation translator, a voltage conversion circuit, and an analog to digital converter. Figure 2 shows a schematic of these three components. Similar to bicycle computers that measure speed directly, the ZouSim hardware allows a rider to shift gears freely as it measures wheel rotations and not cadence. Instead of counting rotations using a magnetic sensor, a dynamo is used in ZouSim. A dynamo is an electric generator that converts mechanical energy (i.e., wheel rotations) into electrical energy [13]. When a wire coil is moved through a magnetic field, current is induced according to Faraday’s law of magnetic induction [14]. This current will alternate by rising, falling, and reversing as the coil is rotated; thus, an alternate current (AC) is produced. Rectification is the conversion from AC to direct current (DC) [15]. Figure 2 shows the half-wave rectifier used in ZouSim, which is a simple circuit that coverts half of the AC output. Instead of using a rectifier, an alternative design is the use of an optocoupler that operates as a voltage-controlled variable resistor. Optocouplers are also known as optoisolators. The basic components of an optocoupler are a light source (e.g., LED), a light transmission medium, and an optical detector. The voltage from the dynamo changes the intensity of the light, which in turn affects the resistance [16]. The rectifier circuit was used instead of the optocoupler circuit because of issues related to matching optocoupler operating characteristics and biasing the optocoupler integrated circuit.

Communications with the simulator engine can be accomplished wirelessly or with a wire. The Universal Serial Bus [17] or Bluetooth [18] are two common options for communicating with computers. Some common tradeoffs between wireless and wired closed range communications include self versus supplied power, dealing with wires, range, lag, and bandwidth. None of the tradeoffs except for lag were significant for the ZouSim design. Power consumption is minimal with Bluetooth communications. The USB cable can be easily located away from the front wheel and the bicycle rider; the bicycle unit is located only a few meters away from the simulator computer. The amount of data transmitted is also minimal; thus, Bluetooth’s bit rate of 1 Mb/s can be adequate [19]. USB communication was chosen to minimize lag and also because Bluetooth was reserved for communicating with the steering sensor, which will be discussed later. Bluetooth is a short distance wireless communication with one of the most complex protocols (i.e., large number of communications primitives and host controller interface events). Bluetooth network topology also involves a master/slave configuration where each slave only communicates with the master in a point-to-point fashion, thus increasing overhead with increasing number of devices. Also discussed later is the software handling of the speed data, which involves scaling to calibrate speeds to the proper physical quantities.

To translate pedaling, the output of the dynamo is a current value that is proportional to the rate of rotation. This value is translated into a digital value via an analog to digital converter and an USB connection. The change in this value is the acceleration. The acceleration is then rescaled to a value of 0 to 1, 0 being no acceleration and 1 being maximum acceleration. This acceleration is then applied to increase the current bicycle speed.

2.3. Braking

The brake on the ZouSim bicycle functions realistically by clamping down on the rear wheel and stopping the wheel from rotating. Even though the ZouSim speed measurement system already takes into account braking via the slowing/stopping of wheel rotations, it is beneficial to also capture the amount of hand braking. By having two parameters to fine tune, one for speed/acceleration and the other for braking, ZouSim can be better calibrated to reflect realistic bicycle performance. Otherwise, a single parameter could lead to compromising realistic acceleration with realistic stopping.

Braking was measured by translating the length of brake cable shortened via the pressing of the brake lever. Since direct mechanical measurement is simple and cost-effective, other measurement systems were not further investigated. A circuit involving a biasing voltage and a potentiometer was used to directly measure braking. A potentiometer or variable resistor makes a connection between its element ends (i.e., tapping) by connecting to the sliding contact or wiper [20]. The slider on the potentiometer was connected to the brake arm while the body was connected to the frame of the bicycle. Figure 1 shows the single potentiometer measuring the brake cable length on the rear brake. As previously discussed, front brakes were removed since the front wheel did not rotate. Whenever the brake lever was pressed, the shortening of the brake cable led to a proportional movement of the potentiometer wiper.

The rate of change in wheel rotations (acceleration) and braking (deceleration) are opposite inputs affecting bicycle movement. Since braking physically slows the rate of the rear wheel rotation, it also affects acceleration. Thus, braking is taken into account in two ways: the reduction of physical rotation and the amount of braking applied. Once the brake is applied, the acceleration value is set to 0. The slow down ratio is then computed using the current bicycle speed and the amount of braking.

2.4. Steering

The most challenging aspect of ZouSim hardware design is the measurement of bicycle steering angles. With a driving simulator steering wheel, the wheel is rotated about the center, and the motion is only in the horizontal plane of the wheel. In contrast, the bicycle handlebars through the stem move mainly in the horizontal plane of the handlebars, but also slightly in the vertical plane as the handlebar is rotated. If a line is drawn from the stem down through the fork, as shown as a blue line in Figure 1, then this line would contact the floor at a different location from where the front wheel contacts the floor. This means that the steering angle or yaw cannot be measured along the aforementioned linear axis; thus, no yaw sensor can be attached on the bike itself. To overcome this challenge, the front wheel was attached to a rotation base. This base consists of two circular plates connected via wheel bearings. This rotation base was mounted on the simulator wooden base and cannot be moved vertically. Thus, the steering becomes fixed to the single degree of freedom of yaw. Figure 1 shows the yaw sensor, encased by a blue housing, attached to the rotation base and not the bicycle. The inclusion of the rotation base had the added advantage of allowing smoother turning of the front wheel leading to a greater stability of the overall bicycle rig.

The steering measurement design considered four main types of sensor systems. They are video, mechanical, gyroscopic, and optical. A common type of video imaging sensor that has been used in a variety of different applications is the Kinect sensor [21]. The Kinect sensor uses a color camera and an infrared camera and projector pair. Kinect senses in three dimensions by triangulating the projected imaged with the observed image. Since the Kinect sensor was designed for skeletal tracking, it can track a person’s rotation while riding a bicycle. In addition to sensing yaw, the Kinect sensor can recognize facial expressions and voice. Imaging was ruled out for ZouSim due to the complexity of software development, the difficulty of locating the sensor together with the large screen, and the demand on the simulator computer engine. In the future, the potential of using this sensor can be investigated in order to add more capabilities, such as facial recognition, to the ZouSim system.

Mechanical yaw sensing involves the direct translation of the handlebar motion into angles. One design that was tested involved a rack and pinion; a pinion is a circular gear and the rack is a linear gear bar [22]. When the pinion rotates, the motion is translated into linear motion, which is easily measured. In addition to the rack and pinion design, other gear designs were also investigated. The major drawback to this design is that the physical gears were too bulky to be located on and around the handlebars. Thus, this design was not used in the final ZouSim system, despite the precision associated with direct mechanical translation.

A gyroscope is a type of inertial sensor that measures rotational rates [23]. Because a gyroscope spins, it maintains a constant orientation, and any external torques can be measured. Positions are obtained by integrating over time. Thus, gyroscopic sensors are generally not suited for measuring absolute angles as errors are cumulative. However, by using software centering and automated correction, these sensors worked relatively well. Several gyroscopic sensors were tested for ZouSim yaw measurement, but they did not perform as well as lasers.

Optical tracking utilizes a light source to illuminate a target, a high-speed camera to take successive images of the target, and a processing unit which determines the distance between successive images [24]. The illumination source can involve different types such as infrared or laser (e.g., vertical-cavity surface emitting laser). The camera used depends on the illumination source; for example, infrared illumination requires an infrared camera. Depending on the illumination, processing can involve processes such as the cross-correlation of images or laser interferometry (i.e., the interference of the reflected with the generated light and the analysis of the changed light properties). The specific optical tracking system employed was a light emitting diode or laser with a plastic lens low-resolution high-speed camera. The common features of successive frames are analyzed, and the distance is measured via frame cross-correlation. The result of the processing is the determination of the amount of handlebar rotation.

Optical tracking performed the best among all the measurement systems tested. Tracking performance was evaluated by visually verifying the on screen position of the projected steering direction. A formal quantitative test was not devised for testing the different steering measurement systems as there were many design tradeoffs involved in addition to tracking accuracy. Issues such as software interface, drift correction, power consumption, communications interface, and form factor were also considered. Specifically, drift refers to the loss of steering wheel centering as steering input is relative (i.e., a differential) from the previous position. In other words, a physically recentered steering wheel is off slightly due to the accumulation of small amounts of error over multiple steering wheel movements. Ultimately, the goal was only to implement a yaw measuring system that would reliably capture bicycle steering.

The orientation of the bicycle is derived from the optically tracked steering angle as follows. The laser outputs a steering angle reflecting the deviation from the center, or zero degrees. This steering angle is limited to a maximum of 45°, although this value can be changed. The reason there is a limit is because this simulator cannot simulate the leaning of the bicycle during turns, which allows sharper turning. The virtual bicycle is then oriented to this new angle subject to the maximum.

2.5. Graphical Display

There are a variety of graphical interface options available for a bicycling simulator. The graphical displays that were tested for ZouSim include projection screens (e.g., 10 foot by 7.5 foot) with projectors, a virtual reality (VR) goggle, large screen monitors, and stereoscopic 3D monitors. The choice of the type of graphical display and the number of displays for a given project will depend on the purpose of the study and tradeoffs associated with various factors such as experiment validity, visual fidelity, field-of-view, immersion, and simulator sickness. The field-of-view is defined as the “portion of space in which objects are visible at the same moment during steady fixation of gaze in one direction” [25]. For example, a project involving the investigation of bicycle markings used a large central LCD screen. This option presented the highest quality central/near peripheral field-of-view, adequate immersion, and the avoidance of simulator sickness associated with dim projection screens.

For projects where situational awareness is needed for side or even rear directions, multiple screens or a virtual reality headset can be used. If the minimum horizontal field-of-view for driving is used for bicycling, then 120° is required [26]. In spanning multiple monitors/screens, there are issues associated with where and how each monitor is placed with respect to the participant. One rule of thumb for the monitor distance is to maximize visual fidelity, that is,, maintain a realistic visual representation of objects such as size and appearance. Sometimes the midperipheral field-of-view is required which leads to the use of a triple monitor configuration covering 135° with each monitor covering 45° (e.g., [27]). Using multiple monitors also requires for objects to transition smoothly from monitor to monitor. For example, when a rider nears an intersection, the crossing traffic has to appear consistent through multiple monitors for the rider to react properly. Monitor bezels can be accounted via graphics card settings or via simulator software. The VR headset has the ability of covering 360 degrees of horizontal vision, but one of its greatest drawbacks so far is the prevalence of simulator sickness. A lesser issue with VR is the inability for the rider to see the real world such as seeing the handlebar, brakes levers, and pedals.

De Winter et al., De Silva et al., Weigelt and Wiemeyer, and Li et al. [2831] discussed the advantages of stereoscopic three-dimensional (S-3D) simulators as providing a relevant near-distance cue, inducing positive participant reaction, improving data validity and credibility, improving performance and learning, improving depth perception, and creating new possibilities for instructions. But some drawbacks are cost, increased discomfort, greater distraction, and induced performance reduction dues to display artifacts [29, 32]. Typical S-3D hardware includes emitter and glass pairs that are synchronized to the left and right eyes. Some techniques for generating the different left and right perspective include color multiplexing (anaglyph), polarization, time multiplexing, time sequencing, and location multiplexing [33]. To date, there has not been a good fit for the use of S-3D in a ZouSim experiment. The use of S-3D and the fledgling augmented reality glasses will continue to be investigated in the future.

3. Simulator Software Development

3.1. Simulator Engine

Some factors influencing the choice of the simulator software engine and design environment include ease of use, flexibility, cost, and capabilities. The two major options are a general software development environment or a simulator-oriented development environment. There are many software languages with the associated development environment that can be an adequate choice for building a simulator. Examples of languages include Java, C-family languages, Python, and Matlab [34]. Many development environments are available for any of these languages with the ability for testing, debugging code, and linking to various libraries for simplifying programming for graphics, physics, and devices. The alternative to the aforementioned languages is the use of a simulator engine that is geared towards the graphics-intensive tasks that are required of simulator experiments. Examples of 3D simulator engines include Unity, OpenSimulator, Unreal, and CryENGINE. ZouSim used this alternative approach with the Unity engine to simplify software development. Such simulation-specific engines include many benefits such as a realistic physics engine, 3D capabilities, animation tools, and compatibility with popular 3D software such as 3ds Max and Sketchup. An additional advantage of building an environment using a simulator engine is the existence of large user communities that provide sample code, modeled objects, and troubleshooting assistance. For example, ZouSim was able to import a network model of a section of Paris from the community database with minimal development. Another example is the use of predeveloped automobile models of various makes for quickly populating a downtown network. A last example is the assistance from user community for interfacing with new technology such as a VR headset.

3.2. Scene Creation

A scene is a bicycle experiment designed in a simulator. For example, in a bicycle marking study, the scene was a network of streets, intersection, and trails based on Columbia, Missouri. A scene is composed of the background, surfaces, and various static and moving objects. Figure 3 shows an example of the scene development for the Columbia network. The left side shows the graphical elements, while the right side shows the inspector of object properties and the hierarchies of objects and components, such as scripts and audio resource. The sky box is the sky along with other background in a scene and is made up of images that seamlessly connect at the edges. For example, a sky box can be composed of a blue sky along with a scattering of clouds.

Any number of light sources can be placed in a scene, and real-time shadows will result depending on the type of light. A directional light such as the sun is placed infinitely far away and affects everything in a scene. A point light such as a street light shines equally in all directions from a set location. A spot light such as a bicycle headlight shines from a point in one direction and only illuminates objects within a cone.

The model surfaces in a scene can involve roads, sidewalks, trails, and other bicycle facilities. Depending on the needs of a particular experiment, the surface can be flat or replicate an actual terrain. Topographic data can be imported to build a mesh surface model of actual roadways and networks. Sometimes terrain that includes vertical and horizontal curvature is undesirable because it introduces other factors not pertinent to a study. The engine’s terrain tools allow the terrain to be “painted” for texture, color, and foliage. Surfaces can be textured to replicate different types of pavements such as asphalt, concrete, and green bicycle pavement. Different types of Manual on Uniform Traffic Control Devices (MUTCD) [1] striping and markings (e.g., sharrows) and experimental striping and markings can be painted on surfaces. Figure 3 shows an example of an intersection involving MUTCD bicycle signage and markings along with other road striping and markings.

3.3. Scene Objects

Common static objects modeled in scenes include road signs, trees, grass, and buildings. Three-dimensional models of objects are made of meshes, which are a combination of thousands of rectangles (polygons). The simulator engine calculates the location of these polygon faces during rendering. Too many faces loaded into a scene at once will overtax the system and be unusable. Typically, detailed models that are close to the screen all of the time should be fewer than 100,000 faces. Details for objects such as signs should be 1000 faces or fewer.

Objects in a transportation network such as road signs, trees, and buildings are placed into a scene on top of the surface. An object’s properties determine how the object interacts with the rest of the scene. For example, the properties can determine if it casts shadows, if it is affected by gravity, and if other objects can collide with it or simply pass through. If the object has a special function, a custom made script (program) can be applied to it. Depending on the goals of a particular experiment, certain objects in the scene can be built with or without colliders, that is, an object that has a physical body instead of just a visual representation. For example, in a bicycle lane use study, the curb can be modeled with a collider to ensure a realistic lateral positioning as bumping into a curb produces a physical collision. However, objects such as signs and light poles can be modeled without a collider to avoid unnecessary collisions. Figure 4 shows an example of a scene that includes several static objects such as buildings, signage, curb, traffic signals, and street lights.

In addition to fixed objects, there can be moving objects in a scene such as other bicyclists, pedestrians, and vehicles. The way these objects move can be set in scripts as part of object properties. For example, in a bicycle intersection study, crossing vehicular traffic was created for several reasons. One reason was to justify the fact the green light was given to the crossing traffic. Another reason was to force the bicyclist to stop and consider the bicycle detection marking. Populating the scene with moving objects adds realism by making the world appear to be alive.

A virtual camera is a camera placed into the simulator environment that acts like a real camera in capturing a specific field-of-view. In modeling the study subject, one virtual camera is used to replicate a rider’s perspective in terms of height, angle, and field-of-view, the so-called first person perspective. Multiple other virtual cameras can be used to present other perspectives such as a side glance or the view from a bicycle rear view mirror. As discussed in the hardware section, the physical inputs from the wheel rotations or the tightening of the brakes have to be processed by the software and displayed in the scene in a realistic manner. Thus, the software has to properly account for the way in which the wheel rotations translate to motion while accounting for friction. Also, the software needs to properly model braking by considering both the slowing of the wheel rotations and the interaction of the wheel with the pavement.

The simulator engine uses a hierarchical (a parent-child) system. An object located underneath another object as a child object will follow the higher-level (parent) object. For example, bicycle wheels are located under the bicycle object. When the bicycle moves, the wheels move as well. The rider-perspective camera is also located under the bicycle folder. This hierarchy system works just like the folders do on a computer. When a high-level folder is moved, all of lower-level folders move also. In other words, this folder system represents the logical relationships between parent and child objects.

An audio script can be used to augment the noise generated naturally from the physical bicycle on a trainer, such as trainer tire, wheel wind, and pedaling noises. For example, additional tire noise can be generated based on the road surface and the type of tire. Ambient network noise, such as vehicles, pedestrians, and birds, can also be used to increase immersion. Depending on the purpose, audio can be activated by proximity to the noise source or via a script.

3.4. Calibration and Validity

Validity refers to the degree in which a simulator evokes the same behavior as the real world [35]. In other words, the behavior in question cannot be the result of simulator characteristics that are not present in the real-world environment. For example, if the region covered by the peripheral vision is not shown, then the investigation of bicyclist comfort with adjoining vehicular traffic cannot be valid. For some experiments, only relative validity is required as opposed to absolute validity. Relative validity is the ability of a simulator to rank different experiment treatments in the proper order, while absolute validity is the ability of a simulator to produce a size of effect that is comparable to reality. To improve ZouSim’s validity, calibration that is based on the objectives of a particular study is performed. For example, if accurate braking and acceleration are critical to a study, then the acceleration/deceleration profile of an actual bicycle must be replicated. Another example is a study with the focus of examining bicycle markings using field videos recorded from a rider’s field-of-view.

Calibration is the fine tuning of simulator performance using field data. In this case, the field data are videos taken from a bicycle rider’s perspective via a bicycle camera. As previously discussed, the simulation of bicycle movement is grounded in physical parameters such as the rate of wheel rotation, wheel diameter, and amount of braking. One major goal in calibration is to improve the relative validity of the simulator. Thus, calibration values were fine-tuned in order to improve the realism of the simulator by enhancing the visual replication of the network and by correcting the physical performance of the bicycle.

The simulator scene was calibrated so that the appearance of the road, signs, and markings matched the field video assuming an average rider height. Field videos and the simulator were viewed side to side, and dimensions of simulator objects were adjusted to match the field video. Bicycle performance was calibrated by adjusting parameters based on feedback from research assistants riding the simulator. Different bicycles have different braking systems. Riders also brake differently by employing a different ratio between the front and rear brakes and by applying different levels of force to the brake levers. The goal of the performance calibration was to produce simulator performance that would appear realistic to a large number of simulator participants with differing physical characteristics and bicycling habits. The calibration emphasized the elimination of any unrealistic response, either overly or underly sensitive acceleration and braking.

3.5. Other Miscellaneous Abilities and Issues

A useful ability of the simulator engine is the capability to automatically collect rider performance measures and other information related to simulator trials. Bicycle speed, braking, acceleration, location, and relative location to signage can all be downloaded into a separate log file for each participant for postprocessing; the postprocessing can be accomplished with automated scripts to derive various safety and other performance measures depending on the goals of a specific study. For example, in an experiment analyzing the effectiveness of bicycle detector markings, several measures can be automatically captured such as the location of the bicycle at the intersection in relation to the detector marking and the bicycle wait time at the signal (i.e., whether the opposing green was minimum or maximum).

Another useful ability is the dynamic generation of the bicycle network. In other words, the network can change as a bicyclist is approaching a street or intersection. For example, in a bicycle wayfinding study, subjects can potentially ignore a wayfinding symbol and not continue on a bikeway. Building extra roads to reroute such traffic makes the network more complicated and lengthens the duration of human subject trials. A dynamically generated network allows every human subject to ride the same length of the network and to encounter the same number of intersections.

The bicycle simulator community is a diverse community where researchers from various disciplines such as mechanical engineering, electrical engineering, cognitive psychology, and civil engineering, to name a few, take advantage of simulators to conduct experiments. Many applications in civil/transportation engineering are more concerned with the engineering aspects of roads and intersections or with bicyclist decisions than with replicating precise bicycle dynamics. For such applications, an affordable simulator, such as ZouSim, can provide an adequate answer even though there are some limiting factors such as the inability to replicate bicycle leaning for turning or the assumption of a flat grade. To overcome such limitations, it would require come complicated and costly upgrades such as the implementation of an actuated platform with multiple degrees of freedom.

Finally, there are some miscellaneous issues to keep in mind in the building of the simulator and designing specific studies. It is important to ventilate and cool the room because subjects are expending energy while bicycling; high-powered fans and air conditioning work together to increase comfort for human subjects and to minimize exertion-related simulator sickness. For most studies, it is best not to replicate real-world locations exactly. Otherwise, human subjects will introduce memory-related expectations and be disappointed when the field site is not replicated completely. For example, a subject familiar with a particular street will expect the building facades, landscaping, and other unique features of that street to look the same. Software centering of the bicycle can be useful for countering steering drift and related problems. Errors in steering position can accumulate over time with a laser system. The recentering of the bicycle can be accomplished automatically when the bicycle is riding straight or manually by the researcher. A vibration generator can be easily added to simulate motion due to road imperfections and tire and pavement interaction; however, this might not be needed because of the amount of motion that is generated by the pedaling and the rear wheel counter resistance.

4. Sample Application

One example of an application that takes advantage of the ZouSim simulator is a study on bicycle wayfinding and detection markings [36]. The City of Columbia, one of four selected sites of the United States Nonmotorized Motorized Pilot Program, had obtained permission to experiment with new bicycle wayfinding markings and bicycle detection markings that are alternatives to MUTCD markings/signage [37, 38]. A simulator study is well suited for such an experiment because of the many types of markings and bicycle facilities that need to be investigated, including baseline scenarios involving MUTCD markings and signage. The human participant trials involved 37 intersections and bicycle facilities such as shared lanes, bike lanes, shared paths, and bike routes. Three types of wayfinding markings/signage and five types of detection markings/signage were interspersed throughout the network. A single high-resolution and high-contrast 96-inch monitor was used for this investigation as peripheral vision was not required for this study. Thirty human subjects participated in the study representing both genders and a wide age range. Performance measures included the marking/sign recognition time, travel times, and the number of wrong turns. A postsimulator survey was administered to obtain additional stated preferences. The study found that the new wayfinding and detection markings led to better bicyclist comprehension and less delay at intersections. Improvements in facilities design such as signage and markings can help to improve public acceptance of sustainable transportation modes such as bicycling.

5. Conclusions

Research into bicycling can sometimes be difficult to conduct in the field because of potential safety concerns. For example, there could be conflicts between bicyclists and vehicles and bicyclists and pedestrians/wheelchair users. A bicycling simulator can be a useful tool for experimenting with new bicycle facility designs in a safe manner. And a simulator study can be a precursor to a field test and help to refine the scope of a field test. In addition, a simulator offers the ability to control for various factors so that each participant experiences the same bicycle trip. For example, an experiment network can be generated in real-time thus compensating for human participants who make wrong turns. The automated collection of simulator performance measures simplifies the collection of detailed data such as bicycle trajectories. Despite the usefulness of a bicycling simulator, there are relatively few published articles on bicycling simulators.

Of all the interfaces required of a bicycling simulator, the steering is arguably the most challenging. Various technologies, such as gears, gyroscopes, cameras, and lasers, offer different design possibilities. However, due to the limitations in form factor and the need to track steering accurately, some technologies perform better than others. Specifically, the optical tracking device offers a good tradeoff in terms of accuracy, software interface, drift correction, communications, and form factor.

The software development process for the ZouSim bicycling simulator was divided into static and dynamic components. The sky box, pavement, buildings, landscape area, and signs, for example, are static components built into a simulator scene or experiment. Dynamic components include vehicles, pedestrians, and other bicyclists. Calibrating the simulator using field videos helped to improve the visual fidelity of the simulator. With the rising interest in sustainable modes of transportation in the United States, such as bicycling, the use of a bicycling simulator can help to improve design, planning, and standards development.

Conflicts of Interest

The authors declare that they have no conflicts of interest.

Acknowledgments

The authors gratefully acknowledge the helpful comments and contributions from the following individuals: Dr. David Hurwitz from the Oregon State Driving and Bicycling Simulator; Ted Curtis and Sam Budzyna from GetAbout Columbia (Nonmotorized Transportation Pilot Program); Paul Wojciechowski from Alta Planning and Consultants; and Henry Brown, Sandy Zhang, Josh Garton, Michael Schoelz, Ben Shetley, and Eunice Wong from ZouTrans.