Draisine 200.0

Hint: We provide ready-to-use material for the press.

In June 1817, so about 200 years ago, German inventor Karl von Drais conceived the “Laufmaschine”, a wooden replacement for the horseback. This earliest predecessor of what is today known as a “bicycle” had no pedals, which is why the driver propelled it by pushing with her feet. In honour of Karl von Drais’ groundbreaking invention, we have echoed the original design by creating a demonstrator of POWVER technology out of wood, with the exception of a few 21st century enhancements:

The Draisine racing team (left to right): Gereon Fox (motor control), Gilles Nies (verification), Felix Freiberger (verification), Holger Hermanns, Sebastian Biewer (motor control), Florian Schießl(motor control and electronics) and Dries Callebaut (below, constructor)

Our “Draisine” is propelled by a 200W electric motor, and controlled by a Raspberry Pi. The main challenge was, given that the Draisine has no pedals, to sense the user’s pushes and to amplify them.

We presented an earlier prototype at CeBIT 2017:

(source: Gereon Fox, Saarland Informatics Campus)

Description & Goals

The goal of this project was to get a grasp of what it means to control an electric bike in software and to create a first working prototype with code that is simple enough to try and start verifying interesting properties.

In the long run, and in line with the ERC funded POWVER project, we envision a software (and hardware) framework for piecing together custom electrified bikes: At present, manufacturers try to sell all-in-one solutions that combine motor, battery, display device, and charging infrastructure. From a business perspective, it makes sense for the major market players to provide integrated systems that are incompatible among each other, so that the customer is locked into the need to acquire a complete bike, instead of simply remixing components according to individual needs and budget.

From the early days however, bike constructors and customers are used to the possibility of freely combining components from different manufacturers. Fully interoperable components give them the freedom of design and opportunities for saving money. Now that computing technology, battery chemistry and motor physics come into play, manufacturers have a good point in not letting vendors or even customers exchange parts or tweak the software: This would not only be complicated and error-prone, but might also lead to serious dangers since electric motors can exert strong forces and each battery is a potential firebomb.

So in order to make components interoperable and exchangeable, one would have to make sure that there is a common (software) interface between them, ensuring that every component behaves properly, and that altogether an electric bike results that can be proven to function correctly and safely.

From a computer science perspective this means that we not only have to think about software protocols enabling communication across and interoperation of components, which is (with exceptions) what for instance the automotive sector does routinely these days. We reach further. We are working towards a software tool (to be made publicly available via the POWVER web page) to which you, as a bike customer, can upload a customized component selection, together with tuning tweaks and maybe even lines of code that are to change. We envision this tool to then compute a mathematical proof of your bike having certain properties. Properties of interest might include

“The battery never overheats”,
“The motor does not support above 25km/h” (which is a legal requirement for basic e-bikes in Germany and elsewhere), or
“The battery will charge equally quickly with any interoperable charger, regardless of mismatching brand of charger and battery” (the violation of which would be an instance of software doping).

In this work, we are harvesting our longstanding and fruitful cooperation with our EnergyBus partners with whom we are developing a standard for connecting electric components of light electric vehicles. Members of EnergyBus already have access to a first interoperability validation and testing tool developed by us.

Technical details

The motor sits in the rear wheel

The frame of the bike, except for the wheel bearings and the various screws is made of Okoumé wood, which looks somewhat rose, has fine nerves (which means that it is easy to mill) and seems to have excellent weather resistance.

The wheels are made of this wood as well, except of course for the tires. Seat and handle bar are covered with leather. Some small parts (like the sensor mounts) were 3D-printed.

In order to control the bike, we need up-to-date information about its current state, which is collected by two sensors: Most importantly, an MPU-6050 measures (among other things that we ignore) the acceleration in forwards direction.

In addition, a hall sensor at the rear wheel sends a signal whenever it detects one of the four magnets we mounted to the wheel passing by.

The Hall sensor tells us how fast we are

The sensor data is fed into a Raspberry Pi running a sophisticated Python script. The script periodically reads the sensors (around 150 times per second), smoothes the signals and processes it: The acceleration signal is our indicator for whether or not the user is pushing. Essentially we scale, translate and crop the signal so as to compute a duty signal for the motor (i.e. how much power the motor should apply). In addition we limit the slope of the duty signal and modulate it depending on the current speed of the signal (which we compute from the frequency of hall sensor events): At speeds close to 0 the duty is 0 as well. If we come close 25km/h, we draw duty to 0 again. Important parameters proved to be the maximum acceleration we expect from the user (which roughly translates into sensitivity to pushes) and the limit on the negative slope of the duty signal (which makes this signal depend not only on time, but also on its previous values, in order to prolong motor support after a push). Slight changes to these parameters have a considerable impact on the driving experience.

The rat’s nest: Raspberry Pi with power bank attached (white), battery (black), acceleration sensor (chip on the left)

The duty signal is then sent to the motor in the rear wheel.

The footbrake

Currently, the Draisine will not react to the first user push, because the speed at that moment is usually too low for that. But the second push already receives a great deal of motor support, so that one easily reaches up to 20km/h on flat terrain. At higher speeds it becomes harder to push, though. We reached speeds of close to 30km/h on a mild downhill track.

In order to slow down again, our Draisine has a simple foot brake on the side.

For testing and calibration purposes an action camera records visually the feet of the rider while in action. To analyse telemetry data the software collected during test rides, we have built a small Kivy application that displays the video alongside the signal data. Occasionally broken frames written by the camera made us think that time would not progress linearly in the video, which is why we built a small binary LED clock to be filmed by the camera. This allows us to sync audio and video automatically (if the sun does not outshine our LED’s).

Git

The Draisine is open source. The source code lives in a chair-internal Gitlab instance. Feel free to get the source code here:

https://liebe.cs.uni-saarland.de/gitlab/powver/draisine

If you have any questions about the code, feel free to contact us.

Logs

While doing test rides on the Draisine, we’ve collected very much data. You can get it here:

https://www.powver.org/publications/draisine/logs/

Press material

All the images embedded above are made available for free reuse (click to obtain full resolution), as well as the materials we provide here:

Video

Hint: Clicking the video links will stream the videos to you. If you want to save them on your hard disk, right-click and choose “Save target as…”.

Logo of the POWVER project
The CeBIT presentation video (MP4, 1920×1080, 93MB, without background music, for legal reasons)
The raw camera stream we used for the CeBIT presentation:raw camera MOV, 700MB
The same stream again, but blended with observer shots, data overlayed:MP4, 412MB
Test rides with the previous prototype: ride 1 (raw MOV from the camera, 868MB), ride 2 (MP4, 86MB), ride 3 (139MB)
A test ride with the binary clock attached to a conventional bike: raw camera MOV, 1.9GB
A test ride with the camera mounted to study the Hall sensor:raw camera MOV, 1.0GB