Improving the Accessibility of 

Micromobility: Intelligent Power Assist 
Team Scoot 

University of Maryland Honors College - GEMSTONE 

Spring 2025 
 

Samantha Krakovsky, Mario Majalca, Owen Mank, Jake Muller, Annie Ni, Tyler 

Rivenbark, Zuzanna Szylow 

 

 
 

 

 

 

 

 

 

 

1 



Abstract 

 Team Scoot innovated micromobility technology with a novel power assist feature to 

enhance mobility for those with physical impairments. Scoot technology aimed to tackle the 

challenges of maneuvering rough terrain and inclines, which are issues prevalent in current 

devices as revealed by stakeholder interviews. These interviews also revealed that users struggle 

with comfort, stability, and durability in existing models, which are areas we were determined to 

improve within the project. Starting with the SuperHandy seated mobility scooter for its 

motorized wheel, we integrated a motor controller for precise movement control. Afterwards, 

Scoot transitioned our technology to a knee scooter, making the device more accessible and 

user-friendly. A knee scooter with integrated power assist benefits the user by reducing the effort 

that needs to be exerted. By utilizing user testimonials as a foundation, Scoot did not merely 

create a device, but redefined mobility for the impaired and tackled one of the largest gaps in 

micromobility research. 

 

 

2 



Acknowledgment 

Team Scoot would like to extend our gratitude to our mentor, Dr. Paley, for guiding us 

through this project, and providing us with invaluable knowledge and resources. Thank you to 

the Maryland Robotics Center and Dr. Ivan Penskiy for the use of our lab space in the E.A. 

Fernandez IDEA Factory on campus. We would also like to thank our discussants, Dr. Jae Kun 

Shim, Dr. Wesley Lawson, Dr. Romel Gomez, and Beth Reinach, our librarian Pam McClanahan, 

and everyone else who contributed their expertise and feedback to our project. We are incredibly 

grateful to the Gemstone Honors Program for providing us with the opportunity to participate in 

undergraduate research, and the Gemstone staff for their continued support throughout the past 

four years.  

 

 

3 



Contents 

Abstract 2 
Acknowledgment 3 
Chapter 1. Introduction 6 

1.1 Statement of Problem and Motivation 6 
1.2 Relation to State of the Art 8 

1.2.1 Disabilities and Their Effects on Mobility 8 
1.2.2 Mobility Devices Considered in this Thesis 10 
1.2.3 Power Assist Technology for Medical Mobility Devices 11 
1.2.4 Kick Assist Technology 14 

1.3 Research Scope and Methodology 14 
1.4 Contributions of Thesis 17 
1.5 Outline of Thesis 18 

Chapter 2. Dynamics and Control of a Motor 19 
2.1 Brushless Electric Motors 19 
2.2 Electric Motor Properties 22 
2.3 Precision Motor Control with ODrive 24 

Chapter 3. Control Design for Power Assist 27 
3.1 Modeling & Feedback Control 27 
3.2 System Integration 33 

3.2.1 Motor Wiring 33 
3.2.2 Motor Parameter Identification 35 
3.2.3 Configuring the ODrives 38 
3.2.4 Communication Diagrams 40 

Chapter 4. Experimental Testing and Results 42 
4.1 Preliminary Testing 42 

4.1.1 Velocity Measurement & Real-Time Filtering 42 
4.2 Control Implementation 45 

4.2.1 Kick Assist 45 
4.2.2 Push Assist 55 

4.3 Knee Scooter Performance Comparison 64 
Chapter 5. Conclusion 68 

5.1 Summary of Contributions 68 
5.2 Suggestions for Future Research 69 
5.3 Equity Impact Report 71 

References 72 
Appendix A: Code Algorithms 76 

A.1 Kick Assist Python Code 76 
A.2 Push Assist Python Code 80 

 

4 



 

Variable Notation: 

 = voltage 𝑉

 = frequency 𝑓

 = velocity 𝑣

= motor velocity constant 𝐾
𝑣

= motor torque constant 𝐾
τ

 = torque τ

 = acceleration α

 = minimum velocity 𝑣
𝑚𝑖𝑛

 = maximum velocity 𝑣
𝑚𝑎𝑥

 = seconds 𝑠

 = time 𝑡

 rotations per minute 𝑟𝑝𝑚 =

 decay rate λ =

 

 

 
 

 

 

 

 

5 



Chapter 1. Introduction 

1.1 Statement of Problem and Motivation 

A variety of devices exist to assist individuals with personal mobility, whether for long-term use 

due to aging or permanent disability, or short-term use during recovery from an injury or surgery. 

While these devices are designed to provide mobility assistance, many have significant 

shortcomings that hinder their effectiveness. A major flaw is the excessive physical effort 

required to operate them, which places an additional burden on individuals already facing 

mobility challenges or those who assist them.  

Electric assistance can be a solution, but integrating motors and batteries into wheeled 

mobility devices presents challenges. Traditional motorized solutions such as throttle-controlled 

electric systems can make devices unstable and unsafe, particularly for users with limited 

mobility or control. Striking a balance between effective assistance and maintaining user control 

is critical. 

Team Scoot’s research focuses on improving micromobility assistance, with the knee 

scooter as a flagship example. Micromobility refers to small, lightweight personal transportation 

devices, like scooters, used for short distance travel. A knee scooter, typically equipped with 

three or four wheels, is commonly used during recovery from lower-leg injuries or surgeries. 

However, incorporating a traditional throttle-controlled motor into a knee scooter poses safety 

risks - users could accelerate too quickly, lose control, and crash, potentially worsening their 

injuries or causing new ones. To address this, Team Scoot developed a system that enhances 

mobility without compromising safety, ensuring users maintain control at all times. 

6 



The novel technology utilizes kick assist, which allows a motorized device to respond to 

inputs other than a throttle, such as a push off the ground. In Team Scoot’s kick assist system, the 

user propels the device manually - just as they would with a conventional knee scooter - and the 

system responds by matching their speed while providing a longer, controlled deceleration. For 

instance, if the user manually accelerates to a velocity of 3 mph, the motor engages to maintain 

that speed before gradually slowing down, extending the rolling distance. This ensures the device 

never exceeds the user's manually generated speed, preventing unsafe acceleration and velocity. 

Further, the user would need to be in-contact with the ground in order to move, necessitating 

stability.  

Beyond knee scooters, this concept has valuable applications for other mobility devices, 

such as wheelchairs. Traditional wheelchairs that require manual pushing can be physically 

demanding, particularly for caregivers or family members assisting a user. While fully electric 

wheelchairs exist, they are often heavy, expensive, and not always intuitive for short-term use. A 

push assist wheelchair could provide a smoother, more natural experience by supplementing, 

rather than replacing, the user's effort. Unlike throttle-controlled motorized systems, which can 

lead to jerky movements and instability, a push assist system would seamlessly amplify the 

pusher’s input, making operation intuitive and reducing fatigue. 

Additionally, since the motor and battery in a push assist system only supplement the 

user’s input rather than fully powering the device, they can be smaller, lighter, and more 

affordable compared to fully motorized alternatives. This makes the system more practical and 

accessible for a wider range of users, striking an ideal balance between assistance, cost, and 

usability. 

 

7 



1.2 Relation to State of the Art 

1.2.1 Disabilities and Their Effects on Mobility 

Many take for granted their ability to move about freely in their daily lives, from travelling to the 

grocery store, to navigating the aisles within it. However, for individuals with mobility 

disabilities, particularly those who must avoid partial or total avoidance of weight bearing on 

their lower limb after a trauma or surgery, movement becomes significantly more challenging. 

Studies show that 200 out of every 100,000 people have such mobility limitations [1].  

 When injury or illness restricts physical movement, individuals are often faced with a 

significant lack of independence. An article by Grimaldi & Goette defined independence as 

having perceived control of one’s life, being psychologically self-reliant, being able to physically 

function, and environmental resources [2]. For those with physical impairments, the perceived 

control of one’s life and psychological self-reliance become especially crucial to maintain. The 

inability to move freely without assistance can erode self-confidence, increase dependency on 

others, and disrupt daily routines, which ultimately diminishes quality of life. 

To assist with mobility during recovery, patients are often provided with arm crutches or, 

in more severe cases, wheelchairs. However, both options present challenges that can 

significantly impact a person's independence. Arm crutches require substantial upper body 

strength, slow movement, and restrict the use of the hands, making routine tasks more difficult 

and reducing self-sufficiency. Wheelchairs, while providing greater stability, can cause physical 

strain and often require assistance from others, further limiting personal autonomy [1]. As such, 

a range of scooters, both manual and motor powered, are becoming popular alternatives. 

Although these too come with limitations, especially in regard to navigating indoor and outdoor 

8 



spaces efficiently, studies have been conducted which show scooters as helping build individual 

independence, ability to maintain friendships and stay connected with their communities, and 

carry out daily tasks with ease [3]. 

These limitations highlight border-systematic issues. Many individuals with mobility 

impairments face structural and technological barriers which prevent full participation in society. 

The lack of innovative bioengineering solutions, underdeveloped assistive technology, and poor 

transportation infrastructure in society contribute to persistent challenges in mobility access [4]. 

While mobility devices can alleviate some physical obstacles, they often fail to address the 

psychological and social dimensions of disability.  

One of the most pressing of these is the stigma and negative perceptions that users of 

mobility devices frequently encounter. The concept of hypervisibility is particularly relevant, as 

it describes how individuals with physical impairments who use wheelchairs, scooters, or other 

assistive devices often become the focus of unwanted attention. They may be stared at, 

commented on, or singled out simply because of their mobility aid, ultimately losing the ability 

to move through society unnoticed or blend in with others [3]. The visibility of mobility devices 

can inadvertently signal frailty or dependency, even when users are otherwise fully capable. 

These perceptions not only affect users’ self-esteem but can also influence how others interact 

with them in public and private spaces. Such attitudes and stigmas create an ableist social 

environment that diminishes the autonomy of device users, regardless of their actual abilities. 

This reinforces the idea that assistive devices, while physically enabling, may simultaneously be 

socially disabling, thus introducing a complex paradox in the lived experience of disability. 

Improving the design and ease of use of mobility devices to be more adaptable and 

user-friendly is just the first step towards addressing mobility challenges. It is also equally 

9 



important to create inclusive environments where assistive device use is normalized and 

respected, rather than stigmatized.  

1.2.2 Mobility Devices Considered in this Thesis 

A relatively recent addition to post-operative mobility devices for those with leg injuries is the 

orthopedic knee scooter. Also referred to as a “knee coaster” or 

“knee walker”, it consists of a wheeled platform, which allows the 

user to rest their affected leg, and handlebars to hold on to and steer 

the device. The user kicks with their unaffected leg to propel 

themselves forward [5]. This device, especially on a flat surface 

and in otherwise healthy volunteers, requires less energy 

expenditure, lower perceived total exertion, and allows for faster 

movement as compared to crutches. A study investigating patient 

preferences between knee scooters and crutches for daily use found a strong preference for the 

knee scooter. Among participants who had experience with both, 96% reported that the knee 

scooter was easier to use. They highlighted its convenience, faster mobility, and superior ability 

to prevent weight-bearing on their injury [6]. It was also highly preferred due to providing a 

stable base, which allows the user to have both hands free when stationary, thus increasing 

independence. 

The primary concern of the knee scooter as a rehabilitation device is the risk of falls, 

which can lead to reinjury or new injuries requiring medical attention [6]. Falls are most likely to 

be sustained by hitting an obstacle, turning too sharply, or moving too fast. However, data from 

Workman et al. indicate that 84% of patients who experienced falls identified as moderately to 

highly active, suggesting they may have exceeded the scooter’s limitations. No correlation was 

10 



found between fall risk and factors such as sex, age, height, weight, and body mass index [6]. 

Similarly, a study by Walsh et al. found that a sedentary lifestyle also increased the risk of injury, 

as less physically active individuals tend to have reduced mobility and stability, making them 

more prone to falls [7]. Overall, the knee scooter is a relatively safe option when used 

responsibly. 

Another personal mobility device for individuals with lower body mobility impairments 

is the electric mobility scooter, such as the SuperHandy Passport Mobility Scooter, as seen to the 

left. It serves as a great alternative to orthopedic 

knee scooters and other mobility aids, as it does 

not require balance or physical strength to 

operate. This makes it especially beneficial for 

older patients or those with limited strength.  

The electric mobility scooter differs from a 

powered wheelchair due to a few factors. First, it 

is operated via a device like a joystick or other 

control trigger, rather than requiring arm strength 

to push the wheels forward. Second, they tend to 

have controllable parameters, such as max speed, acceleration, and deceleration, thus being 

adaptable to the user’s lifestyle and preferences. Finally, depending on the scooter brand, they 

may be easier to get on and off thanks to swiveling chairs and adjustable seating options [9].  

1.2.3 Power Assist Technology for Medical Mobility Devices 

Power assist devices are those that help supplement the manual effort needed to operate a system 

[10]. This concept has been extensively researched as a means to enhance medical mobility 

11 



devices, specifically wheelchairs, to reduce physical strain on users while promoting greater 

independence and minimizing the need for external assistance.  

 Although manual wheelchairs are a common medical assistance device given to patients 

with lower leg and body injuries, they tend to have a very low efficiency. In order for a user to 

propel themselves effectively, they need to possess significant arm strength, and the ability to 

maintain an upright posture. Additionally, prolonged use can cause pain in the wrists, elbows, 

and shoulders, making daily life more challenging and sometimes necessitating assistance, which 

reduces user independence [11]. While alternatives such as electric-powered wheelchairs or 

scooters exist, they may not be suitable for everyone. 

 There are multiple power assist devices for wheelchairs that currently exist, but they all 

generally operate in a similar manner. When a force is applied to the pushrims, sensors detect the 

motion and activate the motor. A microcontroller processes these signals to control the motors, 

ensuring smooth movement, compensating for uneven friction, and enabling coasting. The 

system also includes an automatic braking feature when the user applies reverse force. It is 

powered by a rechargeable battery and can be attached to certain manual wheelchairs with some 

modifications. Essentially, this system reduces the effort required for users to propel themselves 

over the same distance, making movement easier and less physically demanding [11]. 

 These devices also come with the benefit of being easily attached to the rims of most 

wheelchairs, allowing patients to upgrade their current equipment rather than purchasing a new 

one. They have the ability to increase speed, range, and power, which greatly increases mobility 

and independence. This has especially been found to be true for more active wheelchair users 

who like to lead busy lifestyles, and would be hindered by having assistants or not being able to 

get around efficiently on their own [12].  

12 



However, existing mobility solutions do not provide assistance for individuals pushing 

manual wheelchairs. While manual wheelchairs can be heavy and physically demanding for 

caregivers, electric wheelchairs present their own challenges—they are expensive, heavy, and not 

always intuitive for attendants to operate.  

Attendant-controlled wheelchairs, which incorporate a 

throttle-based system, have the potential to reduce strain on 

caregivers by providing powered assistance. One way to reduce the 

effort needed to propel a wheelchair is by attaching powered 

assisting devices, where electric motors provide support based on 

the force applied by an attendant. This assisting force is typically 

calculated using proportional control, meaning it's directly scaled 

from the force measured at the grips using a preset assist gain ratio 

[14].  

However, these systems also introduce safety concerns, as a lapse in attention could cause 

the wheelchair to move uncontrollably or get away from the attendant. Further, if not careful, 

they could lead to a jerky ride for the user. Despite their benefits, ensuring safe and intuitive 

control remains a critical challenge in designing effective attendant-assisted mobility solutions. 

 Another downside of relying on attendant-assisted mobility devices is that the average 

age of the population is increasing, and there is a lack of young people available to care for the 

elderly. Therefore, the spouses of those with mobility impairments are typically the ones caring 

for their loved ones, and they are often elderly themselves [14]. For a standard wheelchair with 

an occupant weighing approximately 65kg, elderly attendants will typically have insufficient 

13 



strength to push that much weight over uneven surfaces or up a slope. Their pushing force is also 

variable, and makes it difficult to adapt a control system that can adapt to individual capabilities.  

1.2.4 Kick Assist Technology 

Technology developed for last-mile transportation can also be adapted to support mobility for 

individuals with physical impairments. A recent study introduced an electric kick assist scooter 

designed specifically for short-distance travel, such as the commute from a train station or bus 

stop to one’s home [15]. The objective was to create a lightweight, compact alternative to a 

bicycle that does not rely on a traditional electric motor, which in many regions requires special 

permits. The solution was a kick assisted scooter. 

Unlike standard electric scooters, this design eliminates the need for a throttle by using 

sensors that detect the user’s kick and amplify each push, effectively extending the distance 

covered with minimal effort. While it mimics the feel of a traditional scooter, it significantly 

reduces physical exertion and fatigue. 

This concept holds meaningful potential when applied to mobility devices for people with 

physical impairments. Because many individuals with limited mobility or strength rely on 

manual devices, integrating kick assist or low-effort propulsion technologies could drastically 

reduce the physical strain of movement. Ultimately, such innovations could enhance 

accessibility, increase independence, and improve overall quality of life.  

 

1.3 Research Scope and Methodology 

Gemstone's Team Scoot was created with the intention of developing accessible electric scooters 

for physically impaired riders. In an effort to more precisely capture that mission, we completed 

14 



various phases of stakeholder interviews, training, and research, each phase of which served an 

instrumental role in specifying our value proposition and subsequent designs for research. 

During the summer of 2022, Team Scoot went through the I-Corps training process, a 

formal program aimed at assisting startups in validating their business concepts by practicing 

empathy and customer discovery. Through this process, Team Scoot researched market demand, 

regulatory compliance, and technological viability. One of the key takeaways from this training 

was that while electric scooters offered benefits to mobility-impaired users, the models that were 

available did not adequately address specific concerns such as stability, comfort, and 

maneuverability. This led us to reconsider the broader implications of assistive mobility devices 

and how we could better serve users with temporary or permanent mobility impairments. 

Following I-Corps training, we undertook an extended research and interview phase 

during Fall 2022 to Spring 2023. During this period, Scoot completed 92 interviews with a 

variety of different stakeholders including physical therapists, rehabilitation practitioners, users 

of mobility devices, and industry specialists. Interviews were carried out through in-person 

interactions, video conferencing, and questionnaires in order to thoroughly understand user needs 

and market gaps. Our main findings at this phase revealed several issues that recurred: 

● Existing mobility aids were not necessarily suited for rough ground and inclines. 

● Most users complained that traditional knee scooters were not applicable for extended 

periods of use. 

● Safety was one of the primary concerns, especially in patients with rehabilitation injury 

requirements. 

● Users wanted a device that would reduce effort without sacrificing maneuverability. 

15 



These findings led us to focus our attention from general electric scooters to a novel knee 

scooter with powered support. 

By analyzing the results of our interviews, we focused our area of research to an 

innovative kick assist knee scooter. Our choice was influenced by the awareness that current 

knee scooters do require a considerable amount of exertion, thus making them incapable of use 

for individuals with weak strength or stamina levels. The new value proposition that arose from 

the process was as follows: Scoot will innovate micromobility technology with a novel and 

intelligent power assist system designed to enable enhanced mobility and reduced effort for 

individuals with physical impairments. Scoot technology will solve key challenges such as 

traveling over bumpy surfaces, navigating up slopes, comfort, stability, and durability—issues 

that were consistently brought up in our stakeholder interviews. 

Our long-term research goal is to develop a modular power assist technology that can be 

applied to various micromobility devices to improve the experience for its users. Eventually, we 

want to answer the question: How might we improve the standard knee scooter and other 

micromobility devices to facilitate greater mobility during the rehabilitation process with 

powered assistance? Through ongoing research and iterative prototyping, we continue refining 

our approach, ensuring that our solution is innovative and practical for real-world consumers. 

 

16 



1.4 Contributions of Thesis 

A wide range of assistive mobility devices exist to support individuals living with physical 

impairments or injuries, including wheelchairs, crutches, leg braces, or mobility scooters. While 

all these devices restore some degree of mobility, they vary significantly in comfort, usability, 

and efficiency. Team Scoot focused our efforts on mobility scooters, specifically the knee 

scooter. Although it is a device designed to facilitate mobility while keeping weight off an 

injured ankle or foot, it still presents numerous challenges. Despite its advantages in daily life, 

facilitating greater independence when compared to other devices, our research indicates that 

knee scooters require significant physical effort to travel distances of at least 1 km, particularly 

over inclines. User interviews further highlight these discomfort and maneuverability issues, 

however, it has the potential to be an incredibly useful tool to improve the quality of life for 

those with mobility impairments. 

To address this gap, Scoot has utilized power assist technology to develop a working 

prototype of the first knee scooter with kick assist. The goal is to dramatically reduce the number 

of times a rider needs to kick, lowering physical exertion and boosting comfort. As the rider 

kicks, the onboard motor controller will measure and hold the peak velocity for several seconds 

before gradually decelerating using feedback control. A user is able to coast for longer before 

reaching a velocity small enough that warrants another kick. With no throttle involved, the 

scooter velocity is determined entirely through user effort. Since the user is never traveling faster 

than the speed they physically input with their kick, our kick assisted knee scooter still remains a 

safe option of transportation for those in physical rehabilitation who may also struggle with 

balance. 

 

17 



1.5 Outline of Thesis 

Chapter two explains brushless electric motor principles and their characteristics. The chapter 

elaborates on precision motor control using ODrive technology and the implementation of these 

principles to enhance mobility aid devices. 

Chapter three outlines Team Scoot’s design process, value proposition refinement, control 

theory modeling, and system integration. The chapter explains how the development of an 

efficient and effective power assist system was developed. 

Chapter four details the testing procedures used to evaluate the effectiveness of Scoot’s 

proposed system. It covers preliminary testing, implementation of control mechanisms 

(deceleration and acceleration), and various test cases for assisted mobility devices. A 

comparative analysis of performance across different devices is provided. 

The fifth and final chapter summarizes the key achievements of the research, 

emphasizing its contribution to mobility assistance. It also discusses potential directions for 

future work, highlighting areas of improvement and potential further development.  

18 



Chapter 2. Dynamics and Control of a Motor 

2.1 Brushless Electric Motors 

Common electric motors have two core components: a rotor, the part that rotates, and a stator, the 

stationary component that drives the rotor. Inrunner and outrunner motors are the main ways 

motors are configured, with inrunner motors having their rotor inside the stator, and outrunner 

motors having their stator inside the rotor. 

 
Fig. 2.1: The configuration of the stator (green) and rotor (blue) of inrunner and outrunner motors 

Source: Adapted From [16] 

Many electric vehicles utilize outrunner motors, as tread can be attached to the rotor to 

directly drive the vehicle without additional mechanisms like a gear system. The SuperHandy 

and knee scooter of Team Scoot are driven by brushless outrunner motors.  

There are two types of DC motors commonly used in engineering applications: brushed 

and brushless. In both brushed and brushless motors, there are methods of changing the polarity 

of the magnetic field generated by the windings so they are always attracting and repelling the 

19 



motor’s permanent magnets in a manner which allows it to continuously rotate. The difference 

between brushed and brushless motors lies in the manner in which the polarity of the magnetic 

field is controlled.  

In a brushed motor this is achieved using two components: brushes and a commutator. 

The commutator is a piece consisting of multiple separated contacts which connect to the coils in 

the rotor. The brushes are stationary and are connected directly to the positive and negative leads 

of the power source. As the rotor rotates, the brushes contact different contacts of the 

commutator, allowing the polarity of the rotor coils to reverse and different coils to be powered. 

As a result, only a subset of the phases in a brushed motor are ever powered at the same time. 

Brushed motors have the advantage of being easy to operate and power, but are not very efficient 

due to the friction from the physical contact between the brushes and the commutator. 

 In a brushless motor the switching of the magnetic fields is done using an external 

electronic controller. The stator is composed of a set number of coils, referred to as the phases of 

the motor. Each phase of the stator is connected to the motor controller, which controls the 

magnitude and direction of the current going through each coil [16].  

 In order for the motor to rotate smoothly and continuously, the resultant vector of the 

magnetic flux going through all of the coils must constantly be rotating so that the permanent 

magnets in the rotor are always catching up to it. ODrive uses Field Oriented Control to 

implement sinusoidal commutation. Field Oriented Control allows the motor controller to 

calculate the precise current needed in each phase so the resultant magnetic flux vector is 

continuously rotating at a constant angular velocity. Sinusoidal commutation means that the 

waveform of the  current being fed through each of the phases of the motor is sinusoidal. The 

20 



direction of current in each coil determines the magnetic polarity it generates, which in turn 

controls whether it attracts or repels the rotor’s permanent magnets. 

 

21 



2.2 Electric Motor Properties 

Counting Pole Pairs 

To better understand the responses of an outrunner motor so it can be programmed, the number 

of permanent magnet pairs lining the rotor (pole pairs) has to be known. When you connect two 

of the phase terminals on a motor together, slightly rotating the motor will be met with brief 

clicks of resistance as you pass each magnetic pole. By marking a starting point on the motor, 

you can then count how many clicks occur during one full rotation. Dividing this number by two 

then gives the number of pole pairs. It is worth noting that if the stator and rotor can be 

separated, then the permanent magnets can be visually counted to find the number of pole pairs. 

[17] 

Estimating The Motor Constant 

When configuring a brushless motor to the ODrive controller, the number of revolutions per volt, 

known as the velocity constant (Kv) is required. To calculate the Kv’s of our two brushless 

motors, we conducted what are colloquially known as “drill tests.”  

We derived our motor’s Kv by connecting an oscilloscope probe to any one of the phase 

terminals and grounding it to another, (the specific phase terminals do not matter, we probed U 

and grounded to V), setting the oscilloscope to measure peak-peak voltage (Vpp) and voltage 

frequency (𝑓V), counting the motors number of pole pairs, and rotating the motor at a constant 

velocity to collect the sinusoidal voltage generated. 

Rotating a brushless motor at a constant velocity generates a sinusoidal voltage. To 

determine the mechanical rpm ( ) from a motor’s voltage output, multiply 𝑓V by 60 𝑟𝑝𝑚
𝑚𝑒𝑐ℎ

seconds and divide by the motor’s number of polar pairs. 

22 



            (2.1) 𝑟𝑝𝑚
𝑚𝑒𝑐ℎ

=
60𝑓

𝑉

# 𝑝𝑜𝑙𝑒 𝑝𝑎𝑖𝑟𝑠

Dividing the Vpp by 2 will yields the motor’s Voltage amplitude ( ). 𝑉
𝐴

          (2.2) 𝑉
𝐴

=
𝑉

𝑝𝑝

2

Once  and   and have been calculated  is simply rpm over voltage [18]. 𝑟𝑝𝑚
𝑚𝑒𝑐ℎ

𝑉
𝐴

𝐾
𝑣

          (2.3) 𝐾
𝑣

=
𝑟𝑝𝑚

𝑚𝑒𝑐ℎ

𝑉
𝐴

 

 

 

 

23 



2.3 Precision Motor Control with ODrive 

To control the Superhandy and Knee Scooter devices, Scoot used ODrive Pro Precision Motor 

Controllers. To use ODrive controllers, they first must be given information about the power 

source, the motor, and the encoder being used.  

The Power Source 

When configuring an ODrive to a battery power source, it needs to be given Voltage and Current 

trip ranges to prevent the ODrive from pulling or adding too much power back into the power 

supply and causing damage. As stated in Cadex Electronics’ battery analyzer manual [19], the 

minimum voltage lithium-ion batteries can supply is 3.0  and the maximum voltage they can 𝑉
𝑐𝑒𝑙𝑙

safely supply is 4.2 . We can then calculate the under and over voltages of a battery pack by 𝑉
𝑐𝑒𝑙𝑙

multiplying the minimum and maximum voltage by the number of cells in the battery pack. 

 Overvoltage        (2.4) = # 𝑜𝑓 𝑐𝑒𝑙𝑙𝑠 *  4. 2 𝑉
𝑐𝑒𝑙𝑙

 Undervoltage        (2.5) =  # 𝑜𝑓 𝑐𝑒𝑙𝑙𝑠 *  3. 0 𝑉
𝑐𝑒𝑙𝑙

The DC max positive current should be set as the battery’s rated maximum discharge 

current and at the recommendation of Solomon from ODrive’s customer support team, the DC 

max negative current should be smaller in magnitude than DC max positive current. 

Motor Parameters 

To calibrate an ODrive to a brushless motor, it needs to be given the motor’s number of pole 

pairs, the motor constant , the current limit, a calibration current, a calibration voltage, and a 𝐾
𝑣

lock-in spin current. The current limit is the maximum current that will be applied through the 

system before it shuts off. The calibration current and voltage are used to drive the motor during 

24 



calibration and are suggested to be set as half the overvoltage and max current’s values. Lastly, 

the lock-in spin current is the current applied to ensure continuous rotation while calibrating the 

encoder, and should be near the maximum continuous current to ensure calibration is accurate. 

The Encoder 

To properly receive data from the motor, the ODrive has to be given the parameters of the 

encoder being used. Most commercial scooter motors are built with hall effect encoders, so the 

encoder mode should be set as hall effect. If finer detail is desired for more control in low speed 

operation, using a robotics wheel with a rotary incremental encoder and setting Odrive to 

incremental encoder mode will achieve this.  

Internal ODrive Control 

ODrive uses a “cascaded style position, velocity and current control loop” as shown below [17]. 

When in any given control loop, the controller disregards any controllers that exist at a higher 

level than the one being implemented. For example, in torque control mode, only the current 

controller is used. 

The control loops used in the ODrive utilize proportional integral (PI) control. This 

control system works by adjusting a control variable based on the error between the setpoint and 

measured process variables, thus enhancing the accuracy and stability of a system’s response to 

disturbances. The proportional component adjusts the output based on the current error, while the 

integral component eliminates steady-state error by accounting for the accumulation of past 

errors within the system. The mathematical formula for this controller is  

         (2.6) 𝑢(𝑡) = 𝐾
𝑝
𝑒(𝑡) +  𝐾

𝐼
∫ 𝑒(𝑡) 𝑑𝑡

25 



where  is the control output and  is the error.  is the proportional gain, and it 𝑢(𝑡) 𝑒(𝑡) 𝐾
𝑝

determines how strongly the system will react to the current error.  is the integral error, and it 𝐾
𝐼

determines how strongly the system will react to the accumulated past errors. The gain terms are 

tuned to cause a stronger correction response and eliminate steady-state error accordingly, so that 

the system reacts in the necessary manner.  

 
Figure 2.2 : ODrive internal Controller 

Soure: Adapted from [17] 
 

 

 

26 



Chapter 3. Control Design for Power Assist 

3.1 Modeling & Feedback Control 

Scoot implemented two different control modes across their devices: push assist and kick assist. 

Push assist is implemented on the SuperHandy and refers to decreasing the amount of force 

required to push a rider sitting in the device. Kick assist is implemented on the knee scooter and 

refers to increasing the amount of time that it takes for the scooter to reach a rest state following 

a kick.  

Each device has two states, ‘idle’ and ‘assist’. In idle, the motor is completely unpowered 

and can freely rotate. In assist, the motor is in closed loop control. Our first task was to 

determine the conditions upon which we enter and exit each control mode. Early on we 

determined that we could only reliably collect velocity data, so all of our switch state cases had 

to be informed by velocity data. In order to maintain ease of use on the knee scooter, assisted 

deceleration only begins directly following a kick. In order to detect a kick, we use velocity and 

time information to continuously calculate acceleration. When acceleration is less than zero, and 

velocity is above some minimum value, we switch to the assist state. The purpose of the 

minimum velocity condition is to ensure that the scooter doesn’t accidentally enter assisted 

deceleration due to small unintentional movements or noise. When acceleration is greater than 

some value ,  or if velocity dips below , we switch back to idle. We chose to use some 𝑎
𝑡𝑜𝑙

𝑣
𝑚𝑖𝑛

value  instead of zero as our acceleration condition due to noise considerations (for more 𝑎
𝑡𝑜𝑙

information, refer to Section 4.1). When we take the derivative of our velocity data to extract 

acceleration, the noise from the velocity data is amplified. Without using , this noise would 𝑎
𝑡𝑜𝑙

cause the system to preemptively switch back to idle before the minimum velocity is reached. 

27 



 
Figure 3.1: State Switch Diagram for Scoot’s Knee Scooter 

Source: Primary 
 

To implement kick assist, we use a time varying velocity command. We investigated two 

different functions to define the velocity command. The first was an exponentially decaying 

reference function represented as 

       (3.1) 𝑣
𝑐𝑜𝑚𝑚𝑎𝑛𝑑

(𝑡) =  𝑣
𝑚𝑎𝑥

𝑒−λ𝑡

where the  is the peak velocity the scooter reaches before slowing down. A few different 𝑣
𝑚𝑎𝑥

values for decay rate  were tested as shown in Figure 3.3. Upon reaching our minimum velocity λ

of 0.1071 m/s, the motor enters the idle state. Upon this condition, we can analytically calculate 

the distance traveled by the scooter from the time the velocity peaks to the time the velocity 

reaches this minimum value.  First, we calculated the time at which the minimum velocity is 

reached as  

      (3.2) 𝑡 = 𝑙𝑛(0. 1071/𝐴)

 

28 



 

  After integrating we get distance tr:  

      (3.3) 𝑑(λ) = (𝑣
𝑚𝑎𝑥

− 0. 1071)/λ

showing that the distance traveled will always be inversely proportional with the decay rate. This 

means that it would be easy to implement a functionality where the user can directly control the 

distance the scooter can travel with a single kick. 

The other function we considered was:  

      (3.4) 𝑣
𝑐𝑜𝑚𝑚𝑎𝑛𝑑

(𝑡) = 𝑣
𝑚𝑎𝑥

𝑒−λ𝑡3

Figure 3.2 shows the comparison of this function with the pure exponential decay. The 

value of this function over the pure exponential decay is that it would hold the peak velocity for 

longer, rather than immediately slowing down. 

 
Figure 3.2: Velocity vs. Time Plot of Various Deceleration Functions 

Source: Primary 
 

Just as with the previous function, we derived the relationship between the decay rate and 

the distance traveled after the kick until minimum velocity is reached. Unlike the previous 

29 



function, this one left us with a non-elementary integral, so we approximated using the first three 

terms of a series expansion. We then had:  

      (3.5) 𝐿 =− 𝑙𝑛(𝑣
𝑚𝑎𝑥

× 0. 1071 )

 This is shown in Fig 3.3, where  is defined as 1.5. 𝑣
𝑚𝑎𝑥

 
Figure 3.3: Distance v Lamba Deceleration Functions 

Source: Primary 
 

The SuperHandy presented a unique challenge as we were not able to directly measure 

torque values, despite being in torque control mode. Through the ODrive, torque is measured 

through current. Unfortunately for Scoot, we had conducted initial current measurement tests in 

the Summer of 2024 and found the data to be extremely noisy, so much so that current 

measurement would be unusable. Considering this, Scoot had to determine a work-around for 

torque measurement. Our team decided on measuring motor velocity as a proxy for torque, as we 

knew from prior experience we could get reliable velocity measurements. Using these 

30 



measurements to compute acceleration at each time step, Scoot identified conditions dependent 

on acceleration that could be used in state switching. 

Scoot determined that if acceleration were positive at any instant, we could assume that a 

push was provided (for a flat ground test). Given slightly noisy acceleration data, however, we 

included a tolerance value of -1.0 in place of 0 so we could conduct state switching that more 

accurately reflected our goals. When the positive acceleration case is true, our system will switch 

from idle to assist mode, and conduct the necessary push assist algorithm. To switch back into 

idle, acceleration must be negative, translating to a decrease in velocity and the assumption that 

the user no longer needs extra torque assistance from the motor. Our state switch model for the 

SuperHandy is represented in Figure 3.4 below. 

 
Figure 3.4: State Switch Diagram for Scoot’s SuperHandy 

Source: Primary 
 

It is important to consider that the torque provided by the user will never be exactly 

constant over time. This was the case in our testing, but is also expected in real-world scenarios. 

Humans are not capable of providing a constant input force down to multiple significant figures, 

and we should expect some variability in the input. Due to this fact, acceleration values will 

31 



never reach exactly 0 m/s2, hence the need for our tolerance values when dealing with state 

switching.  

32 



3.2 System Integration 

3.2.1 Motor Wiring  

Scoot’s electronic schematics are quite similar across our devices, with a few variations. A motor 

is connected to an ODrive motor controller, which is then connected to a Raspberry Pi. The 

ODrive and the Pi are powered from our main battery while the Pi is powered from its own 

portable battery that has an output of 5V. In order to run our code on the Pi, we first upload our 

code to a git repository, then remote access the Pi from a laptop and pull the code onto the Pi. 

After we finish a test, we push the test data from the Pi to the repo, and then pull it onto a laptop. 

The physical implementation of this system is shown in the wiring diagram below.    

 
Figure 3.5: Wiring For Basic Motor Control 

Source: Primary 

33 



 

Wiring the Motor 

Three phase brushless motors have a group of input cables and output cables that are used to 

drive the motor. Thicker in design to withstand higher voltages, the U, V, W Pole wires connect 

to port A, B and C respectively on the ODrive and are what drives the motor when powered. The 

thinner 5V, Ground,  and Hall A, B and C wires output the signals generated by the motor’s 

internal Hall effect sensors. These cables connect to the ODrive’s feedback port, providing it 

with the angular position of the motor over time allowing it to collect, calculate and respond to 

aspects of the motor like current velocity. Since the SuperHandy and Knee Scooter used 3 phase 

brushless motors, both system’s motors could be wired identically. 

Wiring the Raspberry Pi Zero 

While both systems connected to a Pi through USB, the Knee Scooters only input is kicking, so 

the power assist shut off button seen in Figure 3.5 was omitted. This button is used in the 

SuperHandy to allow users to activate and deactivate the power assist as they see fit. 

The Power Supply  

While both systems need to supply the Raspberry Pi with 5V and 2A of power, the SuperHandy’s 

motor requires 48V to operate while the Knee Scooter only needs 36V. To ensure the system 

remained versatile, we utilized 8-58V Input to 5V 2A Output DC/DC converters, so while the 

voltage of the power source may change, the Raspberry Pis’ would continue to receive consistent 

power. These converters were powered directly from a battery, with an emergency power switch 

that allows for powering down the system if needed and a power bus that was used to split 

connect to the ODrive and DC/DC converter.  

34 



Full Electrical System 

With how the electrical system was designed, minimal changes have to happen to adjust the 

controller system to new inputs and motors. When changing to a new motor, as long as its 

voltage is within the DC/DC converter’s input range and the sufficient battery is provided the 

system would work as expected. Furthermore, the system can be easily modified to contain more 

inputs such as a throttle or “start assistance” button as seen in the top right of Figure 3.5. 

3.2.2 Motor Parameter Identification 

Finding the Motor Constants 

As described in Section 2.2, to calculate the motor constant, , a drill test can be conducted to 𝐾
𝑉

find the voltage to RPM relationship of a motor. Since the SuperHandy and Knee Scooter both 

used outrunner motors, the traditional method of connecting the axial rotor to the chuck of the 

drill could not be used. To solve this, Scoot simply pressed the side of the chuck against the tire 

of the SuperHandy and Knee Scooters, maintaining constant pressure while powering the drill so 

the motors could be driven at constant speeds.  

35 



 
Figure 3.6: Friction Spinning a Motor Hub with the Chuck of a Drill 

Source: Primary 
 

Using an oscilloscope that probed Pole U and grounded to Pole V, we collected the peak 

to peak voltages, , and frequencies, , of the sinusoids generated by spinning the 𝑉
𝑝𝑝

𝑓
𝑉

SuperHandy and Knee Scooter motors at 33 different speeds each. These data points were then 

entered into Excel and converted into mechanical RPM and voltage amplitude to be used in 

finding the motors’ .    𝐾
𝑉

Since RPM and voltage share a linear relationship with a slope of  [18], Scoot plotted 𝐾
𝑉

the 33 voltages and their resulting RPM and applied a linear fit to the data. As seen in Figures 

3.6 & 3.7 below, the Knee Scooter and SuperHandy’s linear fits had strong positive correlations 

with respective R2’s of 0.999 and 0.998,  showing  ’s of 21.1 and 5.12  respectively.  𝐾
𝑉

𝑟𝑝𝑚
𝑣

36 



 
Figure 3.7: Linear Fit of the Knee Scooter Motor’s Mechanical RPM at Varying Voltages. 

Source: Primary 
 

 
Figure 3.8: Linear Fit of the SuperHandy Motor’s Mechanical RPM at Varying Voltages 

Source: Primary 

37 



Counting Pole Pairs 

Since the motors used on the SuperHandy and Knee Scooter devices were not easily opened, we 

used the pole counting method of tying together two phase leads described in Section 2.2. Using 

this method, we found that the SuperHandy has 15 pole pairs and the Knee Scooter has 16. 

3.2.3 Configuring the ODrives 

The Power Source 

The SuperHandy is powered by a 48V battery pack with twelve 3.7V lithium-ion cells.  Using 

the overvoltage and undervoltage formulas shown in section 2.3, it has an undervoltage of 36V 

and an overvoltage of 50.4 V. The Knee Scooter was powered with a ten cell, 36V battery, so it 

has an undervoltage of 30V and overvoltage of 42V. While the continuous discharge current of 

the Knee Scooter battery was given as 30A, the SuperHandy company did not provide their 

battery pack’s continuous discharge current. However, by taking apart the battery case, 

 
Figure 3.9: The Individual Lithium-ion Cells that Make up a 48V SuperHandy Battery Pack 

Source: Primary 
 

38 



we were able to conclude that the battery pack was made with DMEGC INR18650-20P 18650 

20P 20A 3.7V batteries with a continuous discharge of 30A [20]. Knowing this we set our DC 

max positive current as 30A for both scooters and set the DC max negative current to -10A, 

suggested by ODrive customer support. 

Motor Parameters 

The SuperHandy was programmed with 15 pole pairs, a  of 5.12 , a current limit of 30A, 𝐾
𝑉

𝑟𝑝𝑚
𝑣

a calibration current of 20A, a calibration voltage of 10V and a lock-in spin current of 20A. 

The Knee Scooter was programmed with 16 pole pairs, a  of 21.1 , a current limit of 30A, 𝐾
𝑉

𝑟𝑝𝑚
𝑣

a calibration current of 20A, a calibration voltage of 10V and a lock-in spin current of 20A. 

The Encoder 

Both motors utilize hall effect coders and therefore the ODrives were set to hall effect encoder 

mode. In future research, utilizing an electric motor with a rotary encoder would be salient due to 

their high precision and better performance at low speeds. Due to how late it was when we 

determined it was the hall effect sensors causing noise in our data and the limited number of 

motors with rotary encoders that would fit our device, we continued with hall effect encoders and 

applied a moving average filter on our data. By using this filter, we significantly reduced the 

noise generated by the hall effect encoder and were able to avoid having to design and mount an 

additional rotary encoder sensor or purchasing an entirely new and costly motor with a built-in 

rotary encoder. 

39 



3.2.4 Communication Diagrams  

Both of our devices’ communication primarily occurred between an ODrive Pro, Raspberry Pi 

Zero, and Brushless DC Motor. With the motors serving as both sensors and actuators, the 

ODrives acting as the motor controllers, and the Raspberry Pi’s acting as our main processors, 

they came together to implement our desired control states. The only differences between the 

communication systems of the SuperHandy and Knee Scooters were the user inputs.  

Knee Scooter - KneeRover 

As mentioned earlier, a knee scooter does not contain a motor or throttle; it is only powered by a 

user’s physical input. Team Scoot purchased a KneeRover knee scooter in the Fall of 2023 for 

experimental testing. With the electronics detailed in Section 3.2.2, we could achieve the 

communication between these components as seen in Figure 3.9. 

 
Figure 3.9: Communication Schematic for Scoot’s Knee Scooter 

Source: Primary 
 

Since ODrive’s can control a motor and read information through its encoder, we were 

able to use our motors as sensors and actuators. Therefore, when someone kicked on the scooter, 

40 



the ODrive would read instantaneous velocity, position and current values which would then be 

provided to the Raspberry Pi. Python scripts can then be uploaded to Pi via Wi-Fi connection, 

and run on an external laptop. Once a script begins running, the Raspberry Pi communicates 

directly with the ODrive to receive the instantaneous values of the motor and runs them through 

a programmed control law, computing new torque and velocity for the ODrive to set the onboard 

motor to.  

Mobility Scooter - SuperHandy 

Most of the communication between our ODrive, Raspberry Pi and motor was the same for the 

SuperHandy with the only changes being the user inputs. While the Knee Scooter reads kicks 

that rotate the motor, the SuperHandy reads pushes rotating the motor. While the Knee Scooter 

was designed to provide continuous assistance, the SuperHandy includes a variable switch wired 

to the Raspberry Pi so the level of assistance desired, if any, can be set by the user. These 

changes can be seen in Figure 3.10.    

 
Figure 3.10: Communication Schematic for Scoot’s SuperHandy 

Source: Primary 

41 



Chapter 4. Experimental Testing and Results 

4.1 Preliminary Testing  

Scoot conducted multiple benchmark tests throughout 2024 to test ODrive capabilities and 

ensure that the base functionalities necessary to implement power assist would be capable of 

running on our test bed platforms, that being our knee scooter and SuperHandy. These 

preliminary functions included but were not limited to: velocity measurement and closed loop 

control, real time application of a data filter, tracking of a time varying command reference 

function, and measurement of user pushing effort. This small scale testing proved to Scoot what 

functions would work best for our end goals, as well as highlighted any key performative issues.  

4.1.1 Velocity Measurement & Real-Time Filtering 

One of the first things Scoot looked to test was how accurately we could track the velocity of a 

motor using the ODrive. With a simple program that read motor velocity at every time interval, 

we collected velocity data over the span of one kick of the knee scooter. The plot generated from 

this test can be seen in Figure 4.1. 

42 



 
Figure 4.1: Plot of Velocity vs. Time of a Single Kick - knee scooter 

Souce: Primary 
 

The noisy data presented a concern that the velocity-based switch state cases could not be 

reliably detected. To determine how the velocity signal would change in closed-loop control, we 

conducted a test by sending a constant velocity command to the motor while asynchronously 

reading the velocity, as shown in Figure 4.2. 

 
Figure 4.2: Plot of Velocity vs. Time of a Constant Velocity Command 

Source: Primary 

43 



 
The issue of noise seemed to be even worse in closed loop control. To remedy this, we 

implemented a real-time moving average filter.  

 
Figure 4.3: Plot of Velocity vs. Time of a Single Kick with an Implemented Moving Average Filter 

Source: Primary 
 

 The moving average filter reduced the signal noise enough that Scoot was confident we 

could accurately detect state-switch cases moving forward. 

 We would later go on to learn that our noisy data was due to the fact that we were using a 

hall effect encoder. Hall effect encoders detect magnetic fields and are therefore limited by the 

number of magnetic poles in the device. While hall effect encoders are fine at higher speeds, they 

are noisy at the speed our devices operate [21]. Using a robotics motor with a built-in rotary 

encoder in future designs could reduce this noise, as while more expensive, the optical rotary 

encoders they use have significantly higher precision and could reduce noise in measurements.   

 

44 



4.2 Control Implementation 

The preliminary tests had validated that we were capable of implementing all the functionality 

necessary to develop kick assist and power assist on our devices. Taking what we learned, we 

wrote and tested fully functional programs designed to provide the necessary power assistance 

on our devices. This section will focus on the implementation of our control laws, and provide an 

overview of our results. The following two sections cover the different test cases for our devices, 

and a more in-depth look at our results, respectively. 

4.2.1 Kick Assist 

In order to evaluate the candidate reference functions presented in Section 3.1, it was important 

to investigate the natural behavior of the scooter decelerating from some arbitrary velocity. A 

simple program was written to autonomously accelerate the knee scooter (with no rider onboard) 

to a velocity of 1 m/s, before transitioning into idle and letting friction decelerate the device to 

rest. The results of this test can be seen below, in Figure 4.4.   

45 



 
Figure 4.4: Plot of Velocity vs. Time of a Riderless Knee Scooter Depicting Frictional Deceleration 

Source: Primary 
 

 From the plot, it takes 2.29 seconds for friction to decelerate the knee scooter to rest. 

As discussed in Section 3.1, two different time varying reference functions were considered for 

kick assist.  

     (4.1) 𝑣
𝑐𝑜𝑚𝑚𝑎𝑛𝑑

(𝑡) = 𝑣
𝑝𝑒𝑎𝑘

𝑒−0.01𝑡3

and 

      (4.2) 𝑣
𝑐𝑜𝑚𝑚𝑎𝑛𝑑

(𝑡) = 𝑣
𝑝𝑒𝑎𝑘

𝑒−λ𝑡

Where  is the decay constant, and is the peak velocity reached during a kick. λ 𝑣
𝑝𝑒𝑎𝑘

The two equations correspond to two different approaches to kick assist. As demonstrated in 

Figure 4.4, the relationship between velocity and time most closely follows a pure exponential 

decay, meaning that Equation 4.2 would most closely mimic the natural deceleration a rider 

46 



would experience. Equation 4.1 suggests a different approach to kick assist, in which the goal is 

to maintain >50% of the peak velocity for as long as possible. 

In order to test Equation 4.1 we conducted a modified version of the test shown in Figure 

4.4, in which the deceleration was now controlled and the reference command was defined by 

Equation 4.1. The results are shown in Figure 4.5.  

 
Figure 4.5:  Plot of Velocity vs. Time of a Riderless Knee Scooter Depicting Frictional Deceleration 

Source: Primary 
 

 This test proved that Equation 4.1 successfully increased the time it took for the scooter 

to come to a complete stop and also significantly increased the time that the velocity stayed 

above 50% of the peak speed. From the plot above, it took the knee scooter 6.1 seconds to 

decelerate to rest from 1 m/s, a 266% increase in deceleration time. Furthermore, it took 4.05 

seconds to reach 50% of max speed, fulfilling another requirement for our decay function.  

47 



 The next step was to implement our full state-switch model described in Figure 3.1. 

Doing so requires calculating acceleration in real time in order to detect when acceleration drops 

below zero. This is calculated using the equation below. 

      (4.2) 𝑎 =  
𝑣

𝑖
 − 𝑣

𝑖−1

∆𝑡

with  representing the current time step and  referring to the interval at which velocity data is 𝑖 ∆𝑡

collected.  

 Figure 4.6 shows a test of the state switch from idle to assist. In the test, a rider weighing 

150 lb provided an impulsive kick, carrying the device to a max velocity of 1.67 m/s. 

 
Figure 4.6: Plot of Velocity vs. Time of a Full Controlled Deceleration Test Cycle 

Source: Primary 

 From the plot, the scooter took 8 seconds to decelerate to rest. Over the course of the full 

single-kick test, the knee scooter traveled a total distance of 6.54 meters across a smooth, flat 

surface. To ensure repeatability, we repeated the test but had the rider provide multiple kicks, 

each from rest. The purpose was to demonstrate if the results above could be repeatable for an 

48 



indefinite amount of time, similar to a real-world application of our technology. Figure 4.7 below 

highlights these results. 

 
Figure 4.7: Plot of Velocity vs. Time of a Full Controlled Deceleration Test Cycle 

Source: Primary 
 

 The next step was to ensure that the state switch from assist to idle was functioning 

correctly. This state switch is important because it ensures that the rider can initiate a kick at any 

time during the deceleration phase. To test this, a 150 lb rider provided multiple kicks at various 

points in the deceleration phase. The results are shown below in Figure 4.8. 

49 



 
Figure 4.8: Plot of Velocity vs. Time for a Multi-Kick Controlled Deceleration Test 

Source: Primary 
 

As shown above, state switching continued to remain functional in a real-world test case. 

At no point along the deceleration phase did the state switch model break down, nor were there 

any major errors in computing peak velocity generated from each kick. Although the measured 

data remained noisy, the implementation of Scoot’s real time filter alleviated a significant 

amount of uncertainty in our data, allowing us to continue obtaining accurate readings for peak 

velocity. This measurement of peak velocity is further highlighted in Figure 4.9 below, where a 

rider provided three kicks on quick succession. 

50 



 
Figure 4.9: Velocity vs. Time of Multiple Kicks in Quick Succession 

Source: Primary 
 

As shown above, readings for peak velocity remained accurate even when kicks were 

provided instantaneously. Furthermore, rider experience itself remained fluid, with no sudden 

resistance or jolts in speed generated from the motor.  

The only concern was that the system seemed to have difficulty tracking the reference 

function right after the kick was detected. After a kick, the error between the command and 

actual velocity is fairly large, with the velocity seeming to stay constant until the command 

velocity is low enough. To remedy this, we tried tuning the proportional and integral gains for  

velocity control of ODrive, as well as testing the other reference function. Below are velocity vs. 

time plots tests with a rider providing a single kick with varying proportional and integral gains. 

Next to each are plots of the error between the command and smoothed velocity, computed only 

after entering the assist state. 

51 



 
     Figure 4.10: Velocity vs. Time with          Figure 4.11: Error vs. Time with  𝐾

𝑃
= 8,  𝐾

𝐼
= 8 𝐾

𝑃
= 8,  𝐾

𝐼
= 8

                                   Source: Primary             Source: Primary 

 
Figure 4.12: Velocity vs. Time with             Figure 4.13: Error vs. Time with  𝐾

𝑃
= 10,  𝐾

𝐼
= 20 𝐾

𝑃
= 10,  𝐾

𝐼
= 20

                                  Source: Primary                            Source: Primary 
 

 
  Figure 4.14: Velocity vs. Time with           Figure 4.15: Error vs. Time with      𝐾

𝑃
= 15,  𝐾

𝐼
= 30 𝐾

𝑃
= 15,  𝐾

𝐼
= 30

Source: Primary                                     Source: Primary  
 

52 



As demonstrated with these tests, increasing both the proportional and integrator gains in 

our control laws significantly decreased the amount of error present between the command and 

actual velocities. Below is a table detailing the maximum error present with various proportional 

and integrator gains.  

 

 𝐾
𝑝

 𝐾
𝐼

Error (m/s) 

8 8 0.3688 

10 20 0.2210 

15 20 0.1945 

15 30 0.1605 
Figure 4.16 Maximum Error for Various  𝐾

𝑃
,  𝐾

𝐼
Source: Primary 

 
While tuning our PI control gains significantly decreased the error present, we wanted to 

see if the system would be better able to track a reference function which more closely resembled 

the natural deceleration of the scooter. Just as before we conducted tests with a rider proving a 

single kick, but used Equation (4.2) as our reference with varying values for decay rate . λ

 

 
Figure 4.17 Velocity vs. Time,            Figure 4.18 Error  vs. Time,   𝑣

𝑐𝑜𝑚𝑚𝑎𝑛𝑑
(𝑡) = 𝑣

𝑚𝑎𝑥
𝑒−𝑡 𝑣

𝑐𝑜𝑚𝑚𝑎𝑛𝑑
(𝑡) = 𝑣

𝑚𝑎𝑥
𝑒−𝑡

   Source: Primary     Source: Primary 

53 



 

 
  Figure 4.19 Velocity vs. Time,        Figure 4.20 Error vs. Time,  𝑣

𝑐𝑜𝑚𝑚𝑎𝑛𝑑
(𝑡) = 𝑣

𝑚𝑎𝑥
𝑒−0.5𝑡

   𝑣
𝑐𝑜𝑚𝑚𝑎𝑛𝑑

(𝑡) = 𝑣
𝑚𝑎𝑥

𝑒−0.5𝑡

       Source: Primary         Source: Primary 

 

 
     Fig 4.21: Velocity vs. Time,          Fig 4.22: Error vs. Time  𝑣

𝑐𝑜𝑚𝑚𝑎𝑛𝑑
(𝑡) = 𝑣

𝑚𝑎𝑥
𝑒−0.25𝑡 𝑣

𝑐𝑜𝑚𝑚𝑎𝑛𝑑
(𝑡) = 𝑣

𝑚𝑎𝑥
𝑒−0.25𝑡

        Source: Primary     Source: Primary 

 
While the max error stayed close to that for Equation 4.1, the error tapered off much 

more quickly. Visually, it is easy to see that the velocity follows the command much closer than 

for Equation 4.2. Still, we did not choose a preferred reference function. While Equation 4.2 

resulted in higher errors, the experience of riding the scooter still felt fluid and natural, and it 

held a higher velocity for longer.  

54 



4.2.2 Push Assist  

Team Scoot’s mission with the SuperHandy was to implement a form of power assist that would 

allow a user to push heavy loads with greater ease. Scoot planned on accomplishing this mission 

through utilization of torque control. Velocity values would be read as a proxy for torque (refer 

to Section 3.1), and acceleration would be computed for each time step. Using this, a function 

would be used to amplify the measured velocity and set this value to the motor. Scoot had 

previously proven they could read acceleration data, so for implementation of our push assist 

function, we first had to determine the scaling of our torque magnification factor. 

There existed three separate cases for when a user provides torque through a push, each 

which requires their own range of magnification factor. The first case is when a user provides a 

high torque and device acceleration is low, implying a large need for assistance. A user would 

benefit from a large increase in torque here. The second case is when a user provides a lot of 

torque and device acceleration is high, implying a light load and minimal need for assistance. A 

scaling factor for this case would be low, near a value of 0. Note that an exact value of 0 reflects 

an idle state where no extra assistance is provided to the user. The final case is when a user is 

providing torque and acceleration is roughly 0 m/s2, implying they are pushing at a constant 

speed. For this case, the magnification factor would also remain constant, as the user is not 

sending a signal that they require either more or less assistance. 

         With the cases for Scoot’s torque magnification factor set, we then determined a function 

that would meet the requirements set. Scoot settled on a damped exponential function, depicted 

as 

                            (4.3) 𝑀 = 5𝑎𝑒−𝑎

with  representing acceleration. A plot of this function can be seen in Figure 4.10. 𝑎

55 



 
Figure 4.10: Plot of Scoot’s Chosen Damped Exponential Function for Torque Control 

Source: Primary 
 

         In Scoot’s case, the x-axis represents the acceleration read from the motor, while the 

y-axis represents the value for the magnification factor. We can note that when acceleration 

approaches both 0 and ∞, the magnification factor approaches 0. Meanwhile, in a range of low 

accelerations (around 1 m/s2), the magnification factor is the highest. 

         With Scoot having determined our torque magnification function, we proceeded to refine 

the underlying logic of our push assist functionality. Scoot’s control algorithm would begin in 

idle, with the ODrive set to torque control. Velocity measurements are made continuously at a 

, which are used to compute acceleration of the SuperHandy (refer to Equation 4.1). If ∆𝑡 = 0. 1𝑠

acceleration is positive, the system can conclude that an external force was applied, and therefore 

assistance should be given to magnify said force. Due to somewhat noisy velocity measurements, 

56 



we modified this condition so that acceleration had to be greater than a tolerance value of 1 m/s2 

for the magnification process to begin. The magnification factor is computed using the current 

acceleration, which is then multiplied by the velocity read from the motor. This assistive torque 

value, although still a velocity, is used as a proxy for torque due to ODrive limitations when 

measuring current. The assistive torque is then set to the motor through torque control. 

Assuming a user is pushing at steady state (i.e: acceleration ≃ 0 m/s2 but ), the 𝑣 > 𝑣
𝑚𝑖𝑛

value of assistive torque sent to the motor is the same as in the previous time step. This ensures 

that a constant assistive torque is provided to aid the user, allowing for a smoother, more 

comfortable user experience. This constant torque is then determined in the acceleration phase 

that precedes steady state pushing. If acceleration is negative at any point in the process, our 

control state switches back into idle and no longer provides any extra assistance to the user.  

         Scoot conducted various tests to prove the state-switching capabilities of our push assist 

algorithm. Firstly, we were interested in visualizing how our model will react if a user provides a 

constant amount of input torque. For this test, no rider was seated in the SuperHandy, and the 

device was operated on a smooth, flat surface. The results of this test are displayed in Figure 11, 

with velocity data updates occurring 10 times a second. 

57 



 
Figure 4.11: Plot of both Torque (Nm) and Velocity (m/s) vs. Time for a Single Push - No Rider 

Source: Primary 
 

Although Scoot got a good look at how the system operated under steady conditions, we 

wanted to further analyze the ramp-up process (i.e. when a user begins pushing). To simulate 

this, we had a subject push with greater effort over time, increasing the torque input to the 

system. This test gave Scoot a more detailed view on how our magnification factor reacted to the 

initial ramp-up process, where acceleration changes dramatically. Results of this test can be seen 

below in Figure 4.12. 

58 



 
Figure 4.12: Plot of both Torque (Nm) and Velocity (m/s) for a Single Push of Growing Magnitude - No Rider 

Source: Primary 
 

         Although there still exist slight noise errors when accelerating, Scoot found success in 

being able to provide different magnitudes of force in a continuous push. A rider had initially 

provided an initial acceleration to switch into assist mode, and from there continued pushing at a 

constant effort. At roughly 4 seconds into the test, the user provided an additional surge of force, 

increasing the acceleration above the required tolerance value, and setting a new value for 

assistive torque as a result. The user pushed for an extra two seconds before hitting the brakes, 

triggering the switch into idle mode and allowing the SuperHandy to decelerate to rest. 

With results showcasing the variations in magnification factor along with how well our 

system switches into assist mode, Scoot next had to finalize state switch tests. Scoot had yet to 

analyze how our system behaved when transitioning back and forth between idle and assist 

modes over an indefinite amount of time. To test this feature, members of Scoot conducted a test 

59 



where a subject provided multiple pushes of various power and length to the SuperHandy. Each 

push began from rest, and SuperHandy weight nor terrain varied between pushes. A plot was 

generated which showcases the torque vs. time of the system caused by the various pushes, 

shown in Figure 4.13. 

 
Figure 4.13: Plot of both Torque (Nm) and Velocity (m/s) for Multiple Pushes of Varying Magnitude - No Rider 

Source: Primary 
 

 For the test highlighted in Figure 4.13, a user had provided different pushes of various 

power, which in turn resulted in different acceleration rates for each case. Due to this, as well as 

the steady-state velocity reached while pushing, the applied torque varies. Drops in torque as 

shown in the figure above represent where the system switches from assist to idle mode. Scoot 

conducted this test several times with the intent of identifying every scenario where the system 

switches into idle mode. A reduction in input torque corresponds to negative acceleration, and 

implies either the user is providing less force, or no force entirely. 

60 



The test itself remained smooth, but there is some concern for the lack of fluidity in state 

switching. As apparent by the 3rd push that occurred at 15 seconds, small errors in measurement 

reading prevented a stable torque to be applied, and thus the system remained in idle until 

another bout of user-generated acceleration occurred at 17 seconds. Moving forward, Scoot will 

need to consider applying their real time filter used on their power assisted knee scooter (see 

section 4.1.1) to the SuperHandy.   

         When understanding human experience when pushing heavy loads, it is best to realize 

that input torque will fluctuate greatly with respect to time, whether it be a change in slope, 

weight, or user fatigue. On top of this, it is generally assumed that many applications that would 

utilize push assist, such as a mobility scooter, would have a user applying a nonzero force for 

long durations. To more effectively simulate a real-world scenario, Scoot conducted a test where 

a user applied varying levels of torque over a time span of 10 seconds, only reaching rest at the 

end. Our system will remain in assist mode throughout the test, returning to idle when the user 

brakes after 10 seconds. A plot of both torque and velocity vs. time was generated from this test, 

and is displayed below in Figure 4.14. 

61 



 
Figure 4.14: Plot of both Torque (Nm) and Velocity (m/s) for a Single Time-Varying Push - No Rider 

Source: Primary 
  

         Figure 4.14 represents some successes and also failures that Scoot will need to address 

moving forward. Although our system can measure a large increase in acceleration mid-push, 

raising the level of torque assistance, there are measurement errors that impact how our system 

decelerates while still in assist mode. Let us refer to the time period from 4 to 6 seconds in our 

test. In this test, a user continued to push the SuperHandy forwards, but at a much lower force. 

This caused the system to identify an acceleration value that falls below our tolerance value, 

triggering the condition to return our system to idle. Once the user then accelerated the 

SuperHandy with an additional push at 6 seconds, the system switched into assist mode and once 

again applied an assistive torque. 

62 



 Although there were no major, noticeable pushing difficulties when the SuperHandy was 

manually decelerated from 4 to 6 seconds, the lack of power assist during this phase could prove 

to cause issues when working with heavier loads. 

 

 

  

 

63 



4.3 Knee Scooter Performance Comparison 

Scoot’s primary goal with the knee scooter was to ensure a rider would need to exert far less 

effort when riding in comparison to existing models that lack power assist. Scoot interpreted this 

goal as a success if rider kicking frequency is at most 50% of the unassisted model, while 

covering the same distance. To prove Scoot’s goal, we compared the performance of our power 

assist knee scooter vs. the same scooter with control modes shut off when covering a length of 20 

meters. Figure 4.15 highlights the position vs time plot of an unpowered knee scooter, with a 150 

lb rider providing a kick when the device reaches a rest state. Kicks provided by the user were of 

roughly equal force magnitude.  

 
Figure 4.15: 20m Test for Position vs. Time of an Unpowered Knee Scooter 

Source: Primary 
 

 Examining the plot above, we can conclude that it took a 150 lb rider seven kicks to reach 

a distance of 20 meters. To cover this distance, it took the rider 27.5 seconds. A kick is 

represented on the plot as a sudden increase in position. With this data in mind, let us now 

64 



consider the same test, but with Scoot’s power assisted knee scooter. The results of the power 

assisted test are in Figure 4.16 below. 

 
Figure 4.16: 20m Test for Position vs. Time of Scoot’s Power Assisted Knee Scooter 

Source: Primary 
 

         As demonstrated by the plot above, Scoot’s power assisted knee scooter reached 20 

meters after only 21 seconds, while the unassisted device reached the same distance after 27.5 

seconds. Furthermore, only three kicks were required on the power assisted knee scooter, 

compared to the seven kicks on the unpowered model. With a 57.1% reduction in user kick 

frequency thanks to Scoot’s power assisted model, we concluded that we successfully 

accomplished our primary goal. 

          To further break these numbers down, we can analyze the distance traveled by both knee 

scooter models when a rider provides a single impulsive kick. As like the previous test above, a 

150 lb rider provided a kick of roughly equal force magnitude for both models. The position vs. 

time plot of the unpowered model is displayed in Figure 4.17, while the power assist model is 

plotted just below, in Figure 4.18. 

65 



 
Figure 4.17: Single Kick Position vs. Time Analysis of an Unpowered Knee Scooter 

Source: Primary 
 

 
Figure 4.18: Single Kick Position vs. Time Analysis of Scoot’s Power Assisted Knee Scooter 

Source: Primary 
 

         As highlighted above, Scoot’s power assisted knee scooter travels 300% farther on a 

single kick than the unassisted model. Additionally, a single kick on the power assisted design 

will propel a rider for 77% longer than the unassisted device. As a result, Scoot’s power assisted 

66 



technology saves riders over twice the effort to travel any range of distances, allowing riders to 

more comfortably ride longer and further. Please note that these tests only apply to flat ground 

cases, and further research will need to be conducted to determine performance on different 

grade slopes. 

 

67 



Chapter 5. Conclusion 

5.1 Summary of Contributions 

Team Scoot set out to address the limitations of existing micromobility devices by developing a 

solution that could enhance their usability for a wide range of users. Our work focused on two 

key objectives. First, we aimed to create a powered knee scooter featuring an integrated kick 

assist system. This system included a motor, wheel, motor control system, and custom software 

to improve mobility and ease of use. Second, we sought to develop a modular push assist 

software that could be adapted for use in other motorized devices. To validate its versatility, we 

successfully implemented and tested this software on an electric mobility scooter. By 

accomplishing both objectives, Team Scoot demonstrated the effectiveness of our approach in 

improving micromobility solutions. 

 

 

 

68 



5.2 Suggestions for Future Research 

Our research has demonstrated the potential benefit of taking intelligent power assist into 

practical and usable products, such as knee scooters, to enhance user experience. As operating a 

power assisted device is a more natural and efficient motion for the human body, Scoot’s 

intelligent power assist is a great way forward for developing mobility solutions. However, 

further research is required before moving forward to mass production. 

Further research must be carried out to develop the kick assist mechanism before it can 

be commercialized. As Scoot only completed testing on flat ground in an idealized environment, 

it’s important to analyze the effectiveness of Scoot’s devices for a variety of test cases. Testing 

with a number of riders, each at a different bodyweight, is important towards further 

understanding Scoot’s usability amongst a general population. This would also provide Scoot 

with a number of user testimonials that will be helpful towards implementing improvements in 

the design of our intelligent power assist. For the same benefits, sufficient testing will also need 

to be completed on a variety of different grades and terrains. Results from these tests may 

highlight current gaps in Scoot technology that will need to be addressed before becoming 

generally available to the public. 

Additional areas of research that require future attention are the optimization of our 

system’s efficiency, long-term durability, and usability in the real world for different populations. 

Only after these aspects have been thoroughly investigated and confirmed should the technology 

proceed in the direction of production. 

The primary beneficiaries of further development in kick assist technology would be: 

● Individuals with mobility problems who require an alternative to traditional knee 

scooters. 

69 



● Elderly users who need a low-stress and simple-to-use mobility device. 

● Medical practitioners seeking improved rehabilitation devices for patients recovering 

from lower-limb injuries. 

● Commuters who want an effective and ergonomic mode of transport. 

Additionally, there are some important areas that need to be investigated to make kick assist 

technology successful and viable: 

Cost Reduction: Efforts need to be directed towards cost reduction without compromising on 

quality and durability. Low-cost manufacturing techniques and substitute materials need to be 

investigated. 

Medical Validation: Additional medical studies need to be conducted to confirm the safety and 

effectiveness of kick assist for users with different physical conditions. Until that approval is 

obtained, this technology is not to be launched into the market. 

Usability Studies: There needs to be thorough user testing to complete ergonomics and ensure 

ease of adoption by diverse user groups. 

By addressing these areas through continued research and development, Scoot’s 

intelligent power assist technology can become a viable, medically acceptable, and affordable 

mobility aid in the future. 

 

70 



5.3 Equity Impact Report 

Individuals with mobility impairments who rely on devices such as crutches, wheelchairs, or 

scooters often face significant societal challenges that hinder their independence and quality of 

life. From inadequate infrastructure and inaccessible public spaces to societal biases and 

everyday inconveniences, they must constantly adapt to environments not designed with their 

needs in mind. These challenges not only restrict mobility but also contribute to feelings of 

exclusion and dependency. 

Additionally, many medical devices are not designed with user comfort, ease of use, and 

adaptability in mind. They often have limited functionality, lack customizable options, and are 

bulky and inconvenient to carry around. As such, they are often more of a hindrance than a help, 

and individuals with mobility impairments may struggle with tasks that others take for granted, 

thus further exacerbating disparities in access and autonomy. 

Team Scoot embarked on this project with commitment to create a more equitable, 

accessible, and user-friendly design. By enhancing the quality, functionality, and effectiveness of 

medical devices, the goal is to empower individuals to navigate their lives with greater ease and 

confidence. This project is not just about improving mobility - it is about restoring independence, 

dignity, and full participation in society. Everyone deserves the ability to move through the world 

without unnecessary obstacles, and Team Scoot aims to contribute to a future where mobility 

devices are not just functional but truly liberating. 

 

 

 

71 



References 

[1] H. Clas et al., “Quality of life and patient satisfaction after the provision of an orthopedic 

knee scooter,” Deutsches Ärzteblatt International, Jul. 2024, doi: 

10.3238/arztebl.m2024.0121 

[2] C. Grimaldi and T. Goette, “The Internet and the independence of individuals with 

disabilities,” Internet Research, vol. 9, no. 4, pp. 272–280, Oct. 1999, doi: 

10.1108/10662249910286743. 

[3]A. Battalova, L. Hurd, S. Hobson, R. L. Kirby, R. Emery, and W. B. Mortenson, “‘Dirty 

looks’: A critical phenomenology of motorized mobility scooter use,” Social Science & 

Medicine, vol. 297, p. 114810, Feb. 2022, doi: 10.1016/j.socscimed.2022.114810.  

[4] L. D. Park, “Barriers to normality for the handicapped adult in the United States.,” PubMed, 

vol. 36, no. 4, pp. 108–11, Apr. 1975, [Online]. Available: 

https://pubmed.ncbi.nlm.nih.gov/123351  

[5] R. Rahman, B. A. Shannon, and J. R. Ficke, “Knee Scooter–Related injuries: A survey of 

foot and ankle orthopedic surgeons,” Foot & Ankle Orthopaedics, vol. 5, no. 1, Jan. 2020, 

doi: 10.1177/2473011420914561. 

[6] M. I. Workman, H. Ettehadi, N. P. Saragas, and P. N. Ferrao, “Knee scooter related injuries 

and satisfaction in patients following foot and ankle surgery,” Foot and Ankle Surgery, 

vol. 28, no. 7, pp. 887–890, Dec. 2021, doi: 10.1016/j.fas.2021.12.003. 

72 

https://pubmed.ncbi.nlm.nih.gov/123351


[7] J. P. Walsh, M. S. Hsiao, L. Rosevear, R. McDermott, S. Gupta, and T. S. Watson, 

“Orthopaedic knee scooter-related injury: prevalence and patient safety perception in a 

prospective cohort with exploratory risk factor analysis,” Journal of Orthopaedic Surgery  

and Research, vol. 18, no. 1, Sep. 2023, doi: 10.1186/s13018-023-04124-6. 

[8] “Passport Mobility Scooter - 48V 2Ah Battery, Lightweight (35 lbs), Foldable + Extra 

Battery,” SuperHandy - Outdoor Tools & Mobility, 2025. 

https://superhandyus.com/products/superhandy-mobility-scooter-gut112-fba (accessed 

Mar. 29, 2025). 

[9] W. B. Mortenson and J. Kim, “Scoping review of mobility scooter-related research studies,” 

The Journal of Rehabilitation Research and Development, vol. 53, no. 5, pp. 531–540, 

Jan. 2016, doi: 10.1682/jrrd.2015.05.0084. 

[10] “Dictionary.com | Meanings & Definitions of English Words,” Dictionary.com. Nov. 18, 

2021. [Online]. Available: https://www.dictionary.com/browse/power assist#  

[11]R. A. Cooper et al., “Evaluation of a pushrim-activated, power assisted wheelchair,” 

Archives of Physical Medicine and Rehabilitation, vol. 82, no. 5, pp. 702–708, May 2001, 

doi: 10.1053/apmr.2001.20836. 

[12] M. Fan, “A low cost power assist for active wheelchair users,” Department of Mechanical 

Engineering, Massachusets Institute of Technology, June 2023. Available: 

https://dspace.mit.edu/bitstream/handle/1721.1/152112/fan-maxfan-bs-meche-2023-thesis

.pdf?sequence=1&isAllowed=y 

73 

https://superhandyus.com/products/superhandy-mobility-scooter-gut112-fba
https://www.dictionary.com/browse/power-assist#
https://dspace.mit.edu/bitstream/handle/1721.1/152112/fan-maxfan-bs-meche-2023-thesis.pdf?sequence=1&isAllowed=y
https://dspace.mit.edu/bitstream/handle/1721.1/152112/fan-maxfan-bs-meche-2023-thesis.pdf?sequence=1&isAllowed=y


[13] “Foldable Attendant Controlled Portable Electric Power Wheelchair,” DiscoverMyMobility, 

2025.https://www.discovermymobility.com/store/powerwheelchairs/green-transporter/ate

ndant-controlled/index.html (accessed Mar. 29, 2025). 

[14] T. Suzuki, H. Uchiyama, C. Holloway, and N. Tyler, “Assisting control for attendant 

propelled wheelchair based on force velocity relationship,” Annual International 

Conference of the IEEE Engineering in Medicine and Biology Society, pp. 3073–3076, 

Aug. 2012, doi: 10.1109/embc.2012.6346613. 

[15] M. Corno, F. Busnelli, and S. M. Savaresi, “Design and control of an electrically assisted 

kick scooter,” 2022 American Control Conference (ACC), pp. 5290–5295, Jul. 2016, doi: 

10.1109/acc.2016.7526498. 

[17] ODrive, “Controller — ODrive Documentation 0.6.10 documentation.” ODrive, 

https://docs.odriverobotics.com/v/latest/manual/control.html 

[18] Tyto Robotics, "How to calculate motor Kv and motor poles," Tyto Robotics, Mar. 27, 2023. 

[Online]. Available: 

https://www.tytorobotics.com/blogs/articles/how-to-calculate-motor-poles-and-brushless-

motor-kv.  [Accessed: Feb. 1, 2025]. 

[19] Cadex Electronics Inc., C7000 Series Battery Analyzer User’s Manual, Rev. 11, November 

2005, pp. 52-54. [Online]. Available: 

https://shop.cadex.com/_files/243/c7x00_user_manual-rev11.pdf. [Accessed: Mar. 27, 

2025 

74 

https://www.discovermymobility.com/store/powerwheelchairs/green-transporter/atendant-controlled/index.html
https://www.discovermymobility.com/store/powerwheelchairs/green-transporter/atendant-controlled/index.html
https://www.tytorobotics.com/blogs/articles/how-to-calculate-motor-poles-and-brushless-motor-kv
https://www.tytorobotics.com/blogs/articles/how-to-calculate-motor-poles-and-brushless-motor-kv
https://shop.cadex.com/_files/243/c7x00_user_manual-rev11.pdf


[20] Queen Battery, "DMEGC INR18650-20P 18650 20P 20A 3.7V battery cell," QueenBattery. 

[Online]. Available: 

https://queenbattery.com.cn/our-products/1288-dmegc-inr18650-20p-18650-20p-20a-37v

-battery-cell.html. [Accessed: Mar. 27, 2025]. 

[21] Progressive Automations, "Comparing technologies: Optical encoders vs. Hall effect 

sensors," Progressive Automations, Jan. 18, 2022. [Online]. Available: 

https://www.progressiveautomations.com/blogs/news/comparing-technologies-optical-en

coders-vs-hall-effect-sensors. [Accessed: Mar. 12, 2025] 

 

 

75 

https://queenbattery.com.cn/our-products/1288-dmegc-inr18650-20p-18650-20p-20a-37v-battery-cell.html
https://queenbattery.com.cn/our-products/1288-dmegc-inr18650-20p-18650-20p-20a-37v-battery-cell.html
https://queenbattery.com.cn/our-products/1288-dmegc-inr18650-20p-18650-20p-20a-37v-battery-cell.html
https://www.progressiveautomations.com/blogs/news/comparing-technologies-optical-encoders-vs-hall-effect-sensors
https://www.progressiveautomations.com/blogs/news/comparing-technologies-optical-encoders-vs-hall-effect-sensors
https://www.progressiveautomations.com/blogs/news/comparing-technologies-optical-encoders-vs-hall-effect-sensors


Appendix A: Code Algorithms 

A.1 Kick Assist Python Code 
 
import asyncio 
import odrive 
from odrive.enums import * 
import time 
import math 
import matplotlib.pyplot as plt 
#import h5py 
 
# Find the connected ODrive 
print("Finding an ODrive...") 
odrv0 = odrive.find_any() 
odrv0.axis0.requested_state = AXIS_STATE_IDLE 
odrv0.axis0.controller.config.control_mode = ControlMode.VELOCITY_CONTROL 
print("ODrive found!") 
 
# Set gains 
odrv0.axis0.controller.config.vel_gain = 8  # Set proportional gain 
odrv0.axis0.controller.config.vel_integrator_gain = 8  # Set integral gain 
vel_conv = 0.714   # meters/counts 
 
# Generate unique filenames for velocity data and plots 
timestamp = time.strftime('%m%d-%H%M') 
data_filename = f"test_data/controlled_decel_{timestamp}.txt" 
graph_filename = f"graphs/controlled_decel_{timestamp}.png" 
 
# Open the file to write velocity data 
file = open(data_filename, "w") 
 
# Variables to store data for plotting 
velocities = [] 
timestamps = [] 
commands = [] 
command_time = [] 
 
# Start time for recording 

76 



start_time = time.time() 
 
async def velocity_monitor_and_decay(interval = 0.2): 
 
    # Initialize variables 
    max_vel = float('-inf') 
    min_vel = 0.15 # m/s 
    prev_velocity = 0   # assume function starting from rest 
    command = 0        # starting in IDLE, no command should be set on begin 
    decay = False      # boolean that's only set to true when decay begins 
 
    # Runs indefinitely, like in a real-world case 
    while True: 
        # Get current velocity from ODrive 
        velocity = odrv0.axis0.vel_estimate * vel_conv 
        current_time = time.time() - start_time 
        print(f"Current velocity: {velocity:.2f} m/s at Time: {current_time:.2f}") 
 
        # Log data to file and store for plotting 
        file.write(f"{current_time},{velocity}\n") 
        velocities.append(velocity) 
        timestamps.append(current_time) 
 
        # Update max velocity 
        if velocity > max_vel: 
            max_vel = velocity 
            command = max_vel 
 
        # If velocity lower than tolerance, go to IDLE 
        if velocity <= min_vel: 
            odrv0.axis0.requested_state = AXIS_STATE_IDLE 
            command = 0 
 
        # Calculate acceleration 
        acceleration = (velocity - prev_velocity) / interval 
        print(f"Acceleration: {acceleration:.2f} counts/s²") 
 
        # Check if acceleration is positive and above threshold velocity 
        if acceleration > 1.0 and velocity > min_vel:             # accel. has to be greater than some 
tolerance to help with noisy data 

77 



            decay = False 
 
        # Check if acceleration turns negative and above threshold velocity 
        if acceleration < 0 and velocity > min_vel and decay == False: 
            print("Acceleration turned negative!") 
            peak_vel = prev_velocity      # since for a < 0, velocity have already decreased past peak 
at this current step 
            decay = True 
            decay_start = time.time() - start_time 
            odrv0.axis0.requested_state = AXIS_STATE_CLOSED_LOOP_CONTROL    # Set to 
CONTROL mode 
 
        # Check if decay is true to run the exp. decay function 
        if decay == True: 
            time_since_decel = current_time - decay_start 
            print(f"Time since decel: {time_since_decel:.2f}") 
            command = max(peak_vel*math.exp(-0.01 * time_since_decel**3), 0)       # y = 
peak_vel*exp(-0.01t^3) 
            odrv0.axis0.controller.input_vel = command / vel_conv    # send data as counts/s 
             
             
        # Update previous velocity and wait for the next check 
        prev_velocity = velocity 
 
        # Log command data 
        commands.append(command) 
        command_time.append(current_time)   
 
        await asyncio.sleep(interval)  # Sleep for the specified interval 
 
     
# Main function to run the monitoring task 
async def main(): 
    # Start the monitoring task 
    monitor_task = asyncio.create_task(velocity_monitor_and_decay(interval=0.2)) 
 
    # Wait for the task to complete 
    await asyncio.gather(monitor_task) 
 
# Run the event loop 

78 



if __name__ == "__main__": 
    try: 
        asyncio.run(main()) 
    except KeyboardInterrupt: 
        print("Program interrupted and stopped.") 
    finally: 
        odrv0.axis0.controller.input_vel = 0 
        odrv0.axis0.requested_state = AXIS_STATE_IDLE 
        # Close the data file 
        file.close() 
 
        # Display summary statistics 
        num_points = len(velocities) 
        total_time = timestamps[-1] if timestamps else 0 
        frequency = num_points / total_time if total_time > 0 else 0 
 
        print(f"Collected {num_points} data points over {total_time:.2f} seconds.") 
        print(f"Average frequency: {frequency:.2f} Hz") 
 
        # Save or discard data based on user input 
        save_data = input("Do you want to save the velocity data to a file? (y/n): ").strip().lower() 
        if save_data == 'y': 
            print(f"Data saved to '{data_filename}'") 
        else: 
            print("Data not saved.") 
 
        # Plot and save graph based on user input 
        save_plot = input("Do you want to save the velocity vs time plot? (y/n): ").strip().lower() 
        if save_plot == 'y': 
            plt.figure() 
            plt.scatter(timestamps, velocities, s=10, color='blue', label='Actual Velocity') 
            plt.plot(command_time, commands, color='green', label='Reference Function') 
            plt.xlabel('Time (s)') 
            plt.ylabel('Velocity (m/s)') 
            plt.title('Velocity vs Time - Rider Knee Scooter - Controlled Decel.') 
            plt.legend() 
            plt.tight_layout() 
            plt.grid() 
 
            # Save as .fig (MATLAB compatible format) 

79 



            #with h5py.File(graph_filename.replace('.png', '.fig'), 'w') as f: 
                # Save the figure as RGBA image data (or other attributes you want) 
                #f.create_dataset('data', data=plt.gcf().canvas.buffer_rgba()) 
                #f.attrs['fig_type'] = 'matplotlib' 
                 
            plt.savefig(graph_filename) 
            print(f"Graph saved as '{graph_filename}'") 
            plt.show() 
        else: 
            print("Graph not saved.") 
 
A.2 Push Assist Python Code 

import asyncio 
import odrive 
from odrive.enums import * 
import time 
import math 
import matplotlib.pyplot as plt 
 
# Finding an ODrive device 
print("Finding an ODrive...") 
odrv0 = odrive.find_any() 
odrv0.axis0.requested_state = AXIS_STATE_CLOSED_LOOP_CONTROL 
odrv0.axis0.controller.config.control_mode = ControlMode.TORQUE_CONTROL 
 
# Generate unique filenames for data and plots 
timestamp = time.strftime('%m%d-%H%M') 
data_filename = f"test_data/push_assist_v1{timestamp}.txt" 
graph_filename = f"graphs/push_assist_v1_{timestamp}.png" 
 
# Open the file to write torque and RPM data 
file = open(data_filename, "w") 
 
# Variables to store data for plotting 
velocities = [] 
torques = [] 
timestamps = [] 
 
# Start time for recording 

80 



start_time = time.time() 
 
# The Big Enchilada 
async def push_assist(interval=0.15): 
 
    # Set constants 
    prev_velocity = 0   # assume function starting from rest 
    prev_torque = 0     # assume starting from rest 
    max_torque = 5.0    # Nm 
    v_min = 1.0         # m/s  - must surpass this velocity to reach steady state 
    vel_conv = 0.714    # m/counts 
 
    # runs indefinitely 
    while True: 
        # Get current velocity from ODrive 
        velocity = odrv0.axis0.vel_estimate * vel_conv    #  m/s 
        current_time = time.time() - start_time 
        print(f"Current velocity: {velocity:.2f} counts/s at Time: {current_time:.2f}") 
 
        # Log data to file and store for plotting 
        file.write(f"{current_time},{velocity}\n") 
        velocities.append(velocity) 
        timestamps.append(current_time) 
 
        # Calculate acceleration 
        acceleration = (velocity - prev_velocity) / interval 
        print(f"Acceleration: {acceleration:.2f} counts/s²") 
 
        # Compute amplification factor (using damped exponential function) and tolerate noisy data 
        if acceleration >= 1.0:    # accelerating (push) 
            amp_factor = 5 * acceleration * math.exp(-acceleration)        # the 10 is just a constant 
that may need changing! 
            assistive_torque = velocity * amp_factor  
        elif acceleration <= -1.0:  # decelerating (no more push) 
            assistive_torque = 0 
        elif acceleration > -1.0 and acceleration < 1.0 and velocity > v_min:    # steady state push 
            assistive_torque = prev_torque        # directly set assistive torque as constant in this state 
        else:    # at rest 
            assistive_torque = 0 
 

81 



        # Safety check to see if it exceeds max torque 
        if assistive_torque > max_torque: 
            assistive_torque = max_torque 
             
         # Log data to file and store for plotting 
        torques.append(assistive_torque) 
 
        # Set motor torque (the push assist part) 
        odrv0.axis0.controller.input_torque = assistive_torque 
     
        print(f"Velocity: {velocity:.3f} rev/s, Torque Command: {assistive_torque:.3f} Nm, Time: 
{current_time:.2f} s") 
 
        # Update previous velocity 
        prev_velocity = velocity 
        prev_torque = assistive_torque 
        await asyncio.sleep(interval) 
 
# Main function to run the monitoring task 
async def main(): 
    # Start the monitoring task 
    monitor_task = asyncio.create_task(push_assist(interval=0.15)) 
 
    # Wait for the task to complete 
    await asyncio.gather(monitor_task) 
 
# Run the event loop 
if __name__ == "__main__": 
    try: 
        asyncio.run(main()) 
    except KeyboardInterrupt: 
        print("Program interrupted and stopped.") 
    finally: 
        odrv0.axis0.controller.input_torque = 0 
        odrv0.axis0.requested_state = AXIS_STATE_IDLE 
        # Close the data file 
        file.close() 
 
        # Display summary statistics 
        num_points = len(torques) 

82 



        total_time = timestamps[-1] if timestamps else 0 
        frequency = num_points / total_time if total_time > 0 else 0 
 
        print(f"Collected {num_points} data points over {total_time:.2f} seconds.") 
        print(f"Average frequency: {frequency:.2f} Hz") 
 
        # Save or discard data based on user input 
        save_data = input("Do you want to save the data to a file? (y/n): ").strip().lower() 
        if save_data == 'y': 
            print(f"Data