758 lines
38 KiB
TeX
758 lines
38 KiB
TeX
\documentclass[conference]{IEEEtran}
|
|
\IEEEoverridecommandlockouts
|
|
% The preceding line is only needed to identify funding in the first footnote. If that is unneeded, please comment it out.
|
|
\usepackage{cite}
|
|
\usepackage{amsmath,amssymb,amsfonts}
|
|
\usepackage{algorithmic}
|
|
\usepackage{url}
|
|
\usepackage[hidelinks]{hyperref}
|
|
\usepackage{placeins}
|
|
\usepackage{booktabs}
|
|
\usepackage{siunitx}
|
|
\usepackage{graphicx}
|
|
\usepackage{textcomp}
|
|
\usepackage{xcolor}
|
|
|
|
|
|
\def\BibTeX{{\rm B\kern-.05em{\sc i\kern-.025em b}\kern-.08em
|
|
T\kern-.1667em\lower.7ex\hbox{E}\kern-.125emX}}
|
|
\begin{document}
|
|
|
|
\title{
|
|
Design and Implementation of a High-Power Motor Controller for Bicycles
|
|
}
|
|
|
|
|
|
\author{\IEEEauthorblockN{Hugo Abescat}
|
|
\IEEEauthorblockA{\textit{GEI Department} \\
|
|
\textit{INSA Toulouse}\\
|
|
Toulouse, France \\
|
|
abescat@insa-toulouse.fr}
|
|
\and
|
|
\IEEEauthorblockN{Karima Attar}
|
|
\IEEEauthorblockA{\textit{GEI Department} \\
|
|
\textit{INSA Toulouse}\\
|
|
Toulouse, France \\
|
|
karima.attar@insa-toulouse.fr}
|
|
\and
|
|
\IEEEauthorblockN{Brage Flønæs Johnsen}
|
|
\IEEEauthorblockA{\textit{GEI Department} \\
|
|
\textit{INSA Toulouse}\\
|
|
Toulouse, France \\
|
|
johnse@insa-toulouse.fr}
|
|
\and
|
|
\IEEEauthorblockN{Oskar Orvik}
|
|
\IEEEauthorblockA{\textit{GEI Department} \\
|
|
\textit{INSA Toulouse}\\
|
|
Toulouse, France \\
|
|
orvik@insa-toulouse.fr}
|
|
\and
|
|
\IEEEauthorblockN{Julien Pavillon}
|
|
\IEEEauthorblockA{\textit{GEI Department} \\
|
|
\textit{INSA Toulouse}\\
|
|
Toulouse, France \\
|
|
pavillon@insa-toulouse.fr}
|
|
\and
|
|
\IEEEauthorblockN{Nolan Reynier Nomer}
|
|
\IEEEauthorblockA{\textit{GEI Department} \\
|
|
\textit{INSA Toulouse}\\
|
|
Toulouse, France \\
|
|
reynier-nome@insa-toulouse.fr}
|
|
\and
|
|
\IEEEauthorblockN{Aleksander Taban}
|
|
\IEEEauthorblockA{\textit{GEI Department} \\
|
|
\textit{INSA Toulouse}\\
|
|
Toulouse, France \\
|
|
taban@insa-toulouse.fr}
|
|
}
|
|
|
|
\maketitle
|
|
|
|
\begin{abstract}
|
|
Electric bikes are becoming an increasingly attractive solution for transporting goods between short distances,
|
|
especially in city-wide infrastructures. However, most commercially available controllers rely on complex integrated
|
|
circuits making repair and local manufacturing difficult, particularly for organisations operating in
|
|
resource-constrained or low-tech environments. The Manufacture Autonome Décentralisée (MAD) is developing products
|
|
and solutions, particularly e-bikes, which are more repairable and sustainable. Previous studies have predominantly
|
|
focused on performance optimisation of Field Oriented Control (FOC) and trapezoidal commutation strategies, with limited
|
|
attention to repairability, component sourcing, and community-centred sustainability criteria. This project aims to
|
|
design, assemble, and develop a functional, low-tech and open-source motor controller for electric cargo bikes. The
|
|
current model uses an open-source motor control called VESC (Vedder Electronic Speed Controller) that allows precise
|
|
control of electric motors. The controller needs to be compatible with a VESC controller and easily locally repairable
|
|
by the MAD. By exploring the inner workings of the VESC project, modelling of the physical systems and the Printed
|
|
Circuit Board (PCB) we investigated the ways we could do it in another way. We acquired a VESC controller to compare our
|
|
system and a commercial product. Preliminary results demonstrate that the adapted VESC-based controller successfully
|
|
drives the target motor under both commutation strategies, and that positional control is achievable with the current
|
|
hardware configuration. Security vulnerabilities related to open Bluetooth access were identified. These findings
|
|
suggest that open-source, locally fabricated motor controllers can meet the functional requirements of electric cargo
|
|
bikes while significantly improving repairability.
|
|
\end{abstract}
|
|
|
|
\thanks{laMAD}
|
|
|
|
\begin{IEEEkeywords}
|
|
VESC, Brushless DC motor, Field Oriented Control, Trapezoidal commutation, Low-Tech, PID-Control.
|
|
\end{IEEEkeywords}
|
|
|
|
\section{Introduction}
|
|
The fast urbanization of global logistics has positioned electric cargo bikes as a primary solution. At the heart of
|
|
these vehicles is the motor controller. Current research and industry standards primarily focus on two methods of
|
|
commutation for the controller: Trapezoidal commutation and Field Oriented Control (FOC).
|
|
|
|
As motor controllers become smarter, they increasingly incorporate wireless connectivity for tuning and diagnostics.
|
|
Current research highlights that while Bluetooth Low Energy (BLE) and mobile app integration improve user experience,
|
|
they often introduce vulnerabilities. Open-source projects, in particular, must balance ease of access for community
|
|
developers with the need to secure the vehicle.
|
|
|
|
We also argue the need for general public's safety when it comes to these bikes, as it could be a danger to the traffic.
|
|
This is especially true when it comes to vehicules carrying a substantial load. This needs to be considered by the MAD,
|
|
where their responsibility and control begins and ends. Should there be a difference between the firmware loaded on a
|
|
product from the MAD than what is publicly available?
|
|
|
|
|
|
% ********************************************* RELATED WORK ***********************************************************
|
|
|
|
\section{Related Work}
|
|
\label{sec:relatedwork}
|
|
|
|
\subsection{Modeling of BLDC Motor}
|
|
The electromechanical model of a BLDC (Brushless DC) motor is foundational for understanding its behavior under different control
|
|
schemes. BLDC motors are categorized by their back-electromotive force (back-EMF) waveform: trapezoidal or sinusoidal.
|
|
This distinction is crucial, as the trapezoidal shape inherently leads to torque ripple when the supplied phase currents
|
|
are not perfectly aligned, directly influencing the choice and effectiveness of the control strategy
|
|
\cite{patil_analysis_2025}. For a BLDC motor with trapezoidal back-EMF, the electromagnetic torque is given by:
|
|
\[
|
|
T_e = \frac{e_a i_a + e_b i_b + e_c i_c}{\omega_m}
|
|
\]
|
|
where \( e_x \) is the back-EMF and \( i_x \) is the phase current \cite{li_quantitative_2019}. The classical d-q
|
|
reference frame model, ideal for sinusoidal machines, is less suitable for trapezoidal BLDC motors because it assumes
|
|
sinusoidal flux distribution. Phase-variable modeling in the natural (abc) frame is therefore more appropriate, as it
|
|
directly accounts for the non-sinusoidal, trapezoidal nature of the back-EMF and the associated harmonics
|
|
\cite{mohammd_taher_new_2021}.
|
|
|
|
\subsection{Trapezoidal Commutation (Six-Step Control) for BLDC Motors}
|
|
% Trapezoidal commutation, or six-step control, uses Hall-effect sensors to synchronize phase current switching every
|
|
% 120 electrical degrees.
|
|
Trapezoidal commutation, or Six-Step control, uses bipolar conduction, with two motor phases conducting at any time and
|
|
current commutation occurring every 120 electrical degrees \cite{gieras_modern_2023}. As commutation depends on rotor
|
|
position, Six-Step control requires either position sensors (e.g. Hall sensors, encoders, or resolvers) or sensorless
|
|
estimation based on back-EMF detection or observers \cite{gieras_modern_2023, gasc_conception_2004}. This method is
|
|
renowned for its simplicity of implementation and low hardware cost \cite{bhatiya_bldc_2024}. It enables effective
|
|
torque control but introduces significant torque ripple during commutation events, especially under high load
|
|
\cite{jomsa-nga_torque_2024}. This ripple generates noise, increases mechanical stress, and reduces overall efficiency
|
|
\cite{mohammd_taher_new_2021}. Although PWM techniques can mitigate this ripple, they do not completely eliminate it
|
|
\cite{li_quantitative_2019}.
|
|
|
|
\subsection{Field-Oriented Control (FOC) for BLDC Motors}
|
|
FOC is a vector control strategy that decouples the stator flux and torque components. It transforms three-phase
|
|
currents into orthogonal \( I_d \) and \( I_q \) components, enabling precise torque control and significant ripple
|
|
reduction \cite{jomsa-nga_torque_2024}. FOC is particularly effective for BLDC motors with sinusoidal back-EMF but can
|
|
also be applied to trapezoidal back-EMF motors, albeit with less impressive ripple suppression results
|
|
\cite{li_quantitative_2019}. It requires greater computational power and more precise position sensors (e.g. encoders).
|
|
Comparative analysis shows that FOC yields a more stable stator current profile and significantly reduces torque
|
|
variations compared to trapezoidal control \cite{patil_analysis_2025}.
|
|
|
|
\subsection{Comparative Analysis: FOC vs. Trapezoidal for Light Electric Vehicles}
|
|
|
|
\subsubsection{Torque Ripple and User Comfort}
|
|
Firstly, torque ripple can be reduced for both control methods by selecting appropriate motor parameters, such as the
|
|
number of stator slots and rotor poles \cite{gasc_conception_2004}.
|
|
FOC substantially reduces torque ripple compared to Six-Step control, directly enhancing ride comfort and minimizing
|
|
vibrations. Experimental results show a torque ripple of \SI{18.38}{\percent} for FOC versus \SI{35.67}{\percent} for
|
|
Six-Step control at 500~rpm \cite{jomsa-nga_torque_2024}.
|
|
Commutation torque ripple (CTR), prominent in Six-Step control, can be specifically targeted and mitigated using
|
|
advanced control techniques like Model Predictive Control (MPC) while retaining the fundamental simplicity of
|
|
trapezoidal commutation \cite{mohammd_taher_new_2021}.
|
|
|
|
\subsubsection{Energy Efficiency}
|
|
FOC optimizes torque per ampere (MTPA), improving efficiency at low loads. Six-Step control exhibits lower switching
|
|
losses at high speeds \cite{li_quantitative_2019}.
|
|
|
|
\subsubsection{Complexity, Cost, and Low-Tech Suitability}
|
|
|
|
Six-Step control is inherently simpler, cheaper, and more robust, making it a prime candidate for low-tech applications.
|
|
Research focused on reducing propulsion system costs proposes simplified hardware topologies, such as 4-switch inverters
|
|
(instead of 6) coupled with direct current control strategies, maintaining acceptable performance while significantly
|
|
lowering hardware costs \cite{lee_advanced_2001}. FOC, while superior in performance, is more complex to implement and
|
|
carries higher hardware costs (sensors, processing power).
|
|
|
|
\subsubsection{Dynamic Response}
|
|
|
|
FOC provides faster response times and better load disturbance rejection \cite{jomsa-nga_torque_2024}.
|
|
|
|
|
|
\section{Research gap}
|
|
Despite this progress, limited research has examined the adaptation of open-source motor controllers to LowTech and
|
|
repairability constraints. To date, researchers have not addressed the challenge of designing a controller that can
|
|
be locally fabricated, repaired with standard components, and secured against unauthorised wireless access requirements
|
|
that are critical for decentralised, community-operated fleets.
|
|
|
|
|
|
\section{Aim and Research Objectives}
|
|
This work presents the design and implementation of a motor control system for electric bicycles and cargo transport
|
|
applications developed within the context of the Manufacture Autonome Décentralisée (MAD) initiative at INSA Toulouse.
|
|
The main objective is to develop a modular, open-source, and locally manufacturable control architecture adapted to
|
|
low-cost electric mobility systems.
|
|
|
|
To achieve this, the project is structured into four main technical contributions.
|
|
|
|
First, a low-cost motor controller is designed based on a six-step (trapezoidal) commutation strategy. The objective is
|
|
to eliminate the need for a microcontroller by relying exclusively on discrete MOSFETs and standard electronic
|
|
components, thereby improving repairability, accessibility, and ease of local manufacturing.
|
|
|
|
Second, a high-performance controller based on Field-Oriented Control (FOC) is developed using an STM32 microcontroller
|
|
platform. This implementation leverages and adapts the open-source VESC firmware to ensure compatibility with the
|
|
selected hardware while enabling advanced motor control capabilities.
|
|
|
|
Third, the security of the wireless communication interface is investigated, with a focus on Bluetooth Low Energy (BLE)
|
|
vulnerabilities. A Flipper Zero device is used as a diagnostic tool to evaluate potential attack surfaces and identify
|
|
weaknesses in the communication layer.
|
|
|
|
Finally, a dynamic model of the bicycle-cargo system is developed to improve rider experience.
|
|
The objective is to minimize the perceived additional effort when towing a cargo cart. This is achieved through a
|
|
PID-based (Proportional-Integral-Derivative) control strategy combined with distance sensing, allowing adaptive
|
|
assistance based on system dynamics.
|
|
|
|
|
|
% ************************************** LOW TECH SIX STEP CONTROL *****************************************************
|
|
|
|
|
|
\section{Hardware-Based Six-Step Commutation Controller}
|
|
\label{sec:sixstep}
|
|
|
|
|
|
% ************************************** FIELD ORIENTED CONTROL *****************************************************
|
|
|
|
\section{STM32-Based Field-Oriented Control Motor Drive}
|
|
\label{sec:foc}
|
|
|
|
This section presents the design and implementation of a high-performance
|
|
motor controller based on Field-Oriented Control (FOC).
|
|
|
|
\subsection{Choice of FOC Over Trapezoidal Commutation}
|
|
|
|
Table~\ref{tab:foc_vs_trap} summarizes the key differences between the
|
|
two commutation strategies, based on the literature reviewed in
|
|
Section~\ref{sec:relatedwork}.
|
|
|
|
\begin{table}[htbp]
|
|
\caption{Comparison between FOC and trapezoidal (six-step) commutation}
|
|
\label{tab:foc_vs_trap}
|
|
\centering
|
|
\begin{tabular}{lcc}
|
|
\toprule
|
|
\textbf{Criterion} & \textbf{FOC} & \textbf{Six-Step} \\
|
|
\midrule
|
|
Torque ripple (at 500 rpm) & \SI{18.4}{\percent} & \SI{35.7}{\percent} \\
|
|
Low-load efficiency & High & Moderate \\
|
|
High-speed switching loss & Higher & Lower \\
|
|
Position sensor requirement & Encoder (high resolution) & Hall sensors \\
|
|
Implementation complexity & High & Low \\
|
|
Hardware cost & Higher & Lower \\
|
|
Dynamic response & Fast & Standard \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
For our cargo bike application, rider comfort and smooth torque delivery
|
|
are priorities. FOC was therefore selected for the high-performance
|
|
controller, while a separate low-tech six-step board (Section~\ref{sec:sixstep})
|
|
was developed for repairability.
|
|
|
|
\subsection{Base Design: Cheap FOCer-2 Project}
|
|
|
|
The starting point was the open-source \textit{Cheap FOCer-2} project,
|
|
which provides a complete KiCad design for a VESC-compatible board based
|
|
on an STM32F405 microcontroller. This design includes:
|
|
\begin{itemize}
|
|
\item A three-phase MOSFET full-bridge power stage.
|
|
\item Gate drivers with built-in dead-time insertion.
|
|
\item Shunt resistors for phase current sensing.
|
|
\item USB and CAN interfaces.
|
|
\item An expansion header for encoder or Hall sensors.
|
|
\end{itemize}
|
|
|
|
The existing KiCad schematic and layout were used as the baseline for
|
|
our adaptations.
|
|
|
|
\subsection{Integration of the Rocacher FOC Tile}
|
|
|
|
Mr. Rocacher provided the Kicad schematic of a ready-to-use FOC tile based on an STM32L476
|
|
microcontroller.
|
|
|
|
The initial idea was to make this tile \textit{pluggable} into our
|
|
carrier board, similar to an Arduino shield. This would allow :
|
|
\begin{itemize}
|
|
\item Easy replacement of the computing core without re-soldering.
|
|
\item Modular upgrades of the microcontroller.
|
|
\item Simplified repair and maintenance.
|
|
\end{itemize}
|
|
|
|
However, the Cheap FOCer-2 project was not designed for such modularity.
|
|
Its routing is dense and highly optimized for a single, non-removable
|
|
F405 chip. Adapting it to accept an L476 tile while preserving all
|
|
critical functions (PWM, current sensing, USB communication) proved
|
|
challenging.
|
|
|
|
\subsection{Pin Compatibility Verification: L476 vs F405}
|
|
|
|
Before modifying the PCB, a thorough pin compatibility check was
|
|
performed between the STM32L476 and the STM32F405
|
|
(original Cheap FOCer-2 design). The following aspects were examined:
|
|
\begin{itemize}
|
|
\item Physical pinout in LQFP64 package.
|
|
\item Alternate functions for PWM timers.
|
|
\item USB DP/DM pins (PA11/PA12).
|
|
\item Analog inputs for current sensing.
|
|
\item UART for BLE communication.
|
|
\end{itemize}
|
|
|
|
Three pin conflicts were identified and resolved as follows.
|
|
|
|
First, the SPI\_MISO function on PA6 for the STM32F405 conflicts with a
|
|
DAC output on the same pin for the STM32L476 tile. Since this pin is
|
|
used for current sensing via SPI in the original Cheap FOCer-2 design,
|
|
the SPI communication was remapped to PA5 on the L476, which provides a
|
|
compatible alternate function.
|
|
|
|
Second, the gate driver enable signal (EN\_GATE) was originally assigned
|
|
to PB5 on the F405. This pin is not accessible on the L476
|
|
tile. The signal was therefore moved to PC5, which is available and
|
|
can be configured as a standard GPIO output.
|
|
|
|
Third, Hall sensor C was originally connected to PC8 (TIM8) on the F405.
|
|
This pin is not available on the L476 tile. The Hall sensor input was
|
|
therefore reassigned to PB3, configured as TIM2\_CH2, which provides
|
|
the necessary input capture functionality for Hall signal decoding.
|
|
|
|
All other critical functions (PWM timers, complementary PWM, enable
|
|
signals, encoder inputs, UART, USB, and CAN) remain fully compatible
|
|
between the two microcontrollers. The ADC channel differences between
|
|
the F405 (ADC123/ADC12) and the L476 (ADC3) must still be handled in
|
|
firmware, as noted previously.
|
|
|
|
\subsection{Schematic Design and KiCad Implementation}
|
|
|
|
The original Cheap FOCer-2 schematic was modified in KiCad to replace the
|
|
integrated F405 with connectors for the L476 tile. The main modifications
|
|
included:
|
|
\begin{itemize}
|
|
\item Removal of the F405 and its associated passive components.
|
|
\item Addition of two 20-pin headers to receive the Rocacher tile.
|
|
\item Re-routing of PWM, ADC, and USB signals to the headers.
|
|
\end{itemize}
|
|
|
|
The schematic passed Electrical Rule Check (ERC) with no errors.
|
|
|
|
\subsection{Routing Challenges and Current Status}
|
|
|
|
The PCB layout was then started. The original Cheap FOCer-2 routing is
|
|
very dense. Inserting connectors for the removable tile while maintaining signal integrity proved
|
|
difficult.
|
|
|
|
The main issues encountered were:
|
|
\begin{itemize}
|
|
\item Some footprints for the tile connectors did not appear correctly
|
|
in the layout after schematic import.
|
|
\item Routing of high-current paths (battery, motor phases) around the
|
|
connectors required additional vias, increasing resistance.
|
|
\item Decoupling capacitors had to be repositioned, raising concerns
|
|
about switching noise.
|
|
\end{itemize}
|
|
|
|
Currently, the schematic is validated, and the layout is under
|
|
development. Once routing is completed, the board will be manufactured
|
|
and tested with the VESC firmware adapted to the L476 tile.
|
|
|
|
|
|
% ************************************** SOFTWARE AND CONNECTIVITY *****************************************************
|
|
|
|
\section{Software and Connectivity}
|
|
|
|
\subsection{BLE Compatibility With the VESC}
|
|
|
|
\subsubsection{First Experiment}
|
|
VESC-controllers are not necessarily equipped with Bluetooth-modules by default. Often, it is necessary to add a
|
|
BLE-module. A standard HC-05 bluetooth-module compatible with arduino is a great way to send and recieve
|
|
bluetooth-packets from a host, e.g. a mobile phone, via a bridge translating the bluetooth packets to the UART protocol.
|
|
This could be demonstrated using a ESP8622's standard library with said module, by letting us send characters from one
|
|
device to another.
|
|
|
|
\subsubsection{HC-05 and the VESC}
|
|
By flashing the VESC firmware on a discovery-card and connecting the HC-05 module to the PB10 and PB11-pins, which are
|
|
the Rx and Tx-pins for the STM32F4xx chip, we discovered that the setup for the bluetooth module was not available in
|
|
the VESC tool. The inherent BLE capabilities is an important limitation to consider when designing a VESC system.
|
|
We learned therefore that the HC-05 is not originally adapted for BLE. The need for a bridge also adds on complexity
|
|
and cost, in the form of extra components and another device to maintain the code of. For the future, choosing a
|
|
bluetooth module supporting BLE will be the easiest solution. Preferably a module fitting the communication connector on
|
|
the cheap FOCer project\cite{b1} could facilitate the relevancy of the PCB project with a microcontroller.
|
|
|
|
\subsubsection{BLE Vulnerability}
|
|
Bluetooth could be a vulnerability to a VESC if it is to be used as a controller in real-time, as the controller could
|
|
be jammed. Our test with the Flipper Zero shows the disfunctionnality of Bluetooth with different use cases.
|
|
We experienced with the jamming of a bluetooth speaker that the music completely stopped. It could also be investigated
|
|
how the connection to the VESC could be modified using the vesc tool. We will touch more on the accessability of the
|
|
code within the vesc tool sooner.
|
|
|
|
\subsection{Code integrity}
|
|
\subsubsection{Context}
|
|
As the project is open source, and the code is freely accessible, there should be no reason to hide the code. It could
|
|
however be reasonable to protect the code from changes which could hurt other people. Changing following parameters
|
|
should at least come with a disclaimer and clearly state the dangers possible by proceeding with said changes. We
|
|
have in mind the maximum speed permitted and the power available to the motors.
|
|
|
|
\subsubsection{LispBM extraction}
|
|
We caugth word that the lisp code for the VESC used by Maillon mobility was easy to extract. By building an older
|
|
firmware with the Maillon mobility software, we observed this by going to the lispBM tab and clicking read. It's up to
|
|
the MAD if they would like to reinforce this mechanism. A modification on a parameter and then clicking upload allowed
|
|
us to easily change the speed limit. This could bring up a public danger. This raises questions on the use of the MAD's
|
|
equipment which is in a traffic friendly manner.
|
|
|
|
\subsubsection{LispBM Code}
|
|
When we flashed newer firmware from the project made by Benjamin Vedder\cite{b1}, we also observed some difficulties in
|
|
uploading the lispBM script taken from the one on firmware version 6.06. This could indicate that there needs to be
|
|
further maintenance of the code in order to get the software up to speed. This needs to be documented better for someone
|
|
to continue the project. This could be a good investment for the MAD as well in the context of training for the people
|
|
working on the motor control part of the e-bike.
|
|
|
|
This documentation could be as simple as referencing the relevant parts of the lispBM documentation \cite{b2}
|
|
|
|
\subsubsection{Proposed Solution}
|
|
This risk could be patched by developing a VESC application for the VESC controller or using a binary. This is a
|
|
solution which is less open source, but which is make unlawful use of the material harder. The application could be
|
|
created using C and use an algorithm known by the MAD in order to securise the access to someone to change the parameters
|
|
only if they are the MAD certified personnel. This encryption would preferably be reduced to the most essential settings
|
|
in order to align with what our impression of the philosophy of the MAD would be.
|
|
|
|
|
|
|
|
\subsection{VESC Compiling}
|
|
As mentionned, we have been able to compile the VESC tool and the VESC firmware. This firmware has been put onto an
|
|
STM32F4xx Discovery card. This card uses the same chip as the aforementioned ``Cheap FOCer'' project. The thought was
|
|
that using something with the same chip would facilitate the switch from the discovery card to a PCB with the same target.
|
|
|
|
However, this choice posed several obstacles for our progress on the topic of cybersecurity. We will nonetheless
|
|
summarise what we have learned for you and propose some additional work for the future. The challenges we encountered
|
|
were the following: The lack of bluetooth capabilities. We did not have a module with BLE either. We had access to a
|
|
HC-05 module, but that only allows for a normal bluetooth protocol and would require further work on a bridge to UART
|
|
by using an esp8622 that we had as well. We propose that the next group has access to a VESC controller from the
|
|
beginning, as well as a motor we could control. This could be in cooperation with the MAD, as the MAD could propose
|
|
some models they're interested in.
|
|
|
|
We also found that the information on the VESC is scattered around the internet. The ressources is also sometimes
|
|
based on a debian-based linux system which adds more work for someone using another distribution of linux. This could
|
|
hinder the implementation facility for new users. We struggeled particularly with the Qt packages for positioning and
|
|
gamepad. We would therefore recommend the use of a debian-based linux system for the computer working with the VESC
|
|
for the the MAD associates.
|
|
|
|
|
|
% ************************************ DYNAMIC MODELLING ***************************************************************
|
|
|
|
\section{Dynamic Modelling and Control of the Bicycle-Cargo System}
|
|
|
|
\subsection{Dynamic System Modelling}
|
|
|
|
The studied system consists of a bicycle towing a cargo cart through a rigid mechanical linkage. This link is only used
|
|
for steering guidance and does not contribute to the traction force. The main objective is to ensure that the rider
|
|
perceives minimal additional effort, such that the overall behaviour remains similar to riding a standard bicycle.
|
|
|
|
From a control perspective, the rider provides a reference motion in terms of speed and position, while the cargo cart
|
|
is expected to follow this reference with minimal delay. The position error between the bicycle and the cargo cart is
|
|
computed using a distance sensor, which provides feedback relative to an equilibrium state.
|
|
|
|
The cargo cart is modelled as the plant of the system. Its rotational dynamics are described using the fundamental
|
|
equation of rotational motion:
|
|
|
|
\begin{equation*}
|
|
\sum \tau = J_{\Delta} \times \dot{\omega}
|
|
\end{equation*}
|
|
where $\tau$ is the total torque applied to the system, $J_{\Delta}$ is the equivalent moment of inertia, and $\omega$
|
|
is the angular velocity.
|
|
|
|
The total torque is composed of the motor torque $\tau_m$ and a friction torque modelled as:
|
|
|
|
\begin{equation*}
|
|
\tau_f = -f \times \omega
|
|
\end{equation*}
|
|
where $f$ is the viscous friction coefficient.
|
|
|
|
The resulting dynamic equation becomes:
|
|
|
|
\begin{equation*}
|
|
J_{\Delta} \dot{\omega} = \tau_m - f \omega
|
|
\end{equation*}
|
|
|
|
In the Laplace domain, this leads to:
|
|
\begin{equation*}
|
|
\omega(s) = \frac{\tau_m(s)}{J_{\Delta} s + f}
|
|
\end{equation*}
|
|
|
|
Since the linear velocity is related to angular velocity by the wheel radius $R$, we obtain:
|
|
|
|
\begin{equation*}
|
|
v(s) = R \times \omega(s)
|
|
\end{equation*}
|
|
|
|
Thus, the transfer function between motor torque and linear velocity is:
|
|
\begin{equation*}
|
|
\frac{v(s)}{\tau_m(s)} = \frac{R}{J_{\Delta} s + f}
|
|
\end{equation*}
|
|
|
|
|
|
\subsection{PI-Based Control Strategy}
|
|
\label{subsec:Simulink_model}
|
|
Based on this model, a Simulink representation of the system was developed. The controlled system includes a feedback
|
|
loop using a PI (Proportional-Integral) controller in order to regulate the position error between the bicycle and the cargo cart.
|
|
|
|
Since the reference input is a ramp signal (representing the bicycle position over time), an integral action is required
|
|
to ensure zero steady-state error and accurate tracking of the reference trajectory.
|
|
|
|
The closed-loop Simulink model of the system is shown in Fig.~\ref{fig:simulink-closedloop}.
|
|
|
|
The control error is defined as the difference between a desired relative position and the measured displacement between
|
|
the bicycle and the cargo cart:
|
|
\begin{equation*}
|
|
e(t) = e_{\text{ref}} - (x_{\text{bike}} - x_{\text{cart}})
|
|
\end{equation*}
|
|
where $e_{\text{ref}} = \SI{-0.5}{\meter}$ represents the desired equilibrium offset between both systems.
|
|
|
|
\begin{figure}[!h]
|
|
|
|
\centering
|
|
\includegraphics[width=\linewidth]{./Figures/sys_dyn_matlab.png}
|
|
\caption{Closed-loop model of the bicycle-cargo system with PI control.}
|
|
\label{fig:simulink-closedloop}
|
|
|
|
\end{figure}
|
|
|
|
|
|
\subsection{Control Architecture Exploration}
|
|
|
|
|
|
% ******************************** RESULTS **************************************************************************
|
|
|
|
|
|
\section{Results}
|
|
|
|
\subsection{FOC Controller Validation}
|
|
|
|
\subsubsection{Current Status Summary}
|
|
|
|
Table~\ref{tab:foc_status} summarizes the current status of the FOC
|
|
controller development.
|
|
|
|
\begin{table}[htbp]
|
|
\caption{FOC controller development status}
|
|
\label{tab:foc_status}
|
|
\centering
|
|
\begin{tabular}{l c}
|
|
\toprule
|
|
\textbf{Task} & \textbf{Status} \\
|
|
\midrule
|
|
VESC firmware compilation & Completed \\
|
|
Pin compatibility (F405 / L476) & Completed \\
|
|
Schematic design (KiCad) & Completed \\
|
|
ERC validation & Completed \\
|
|
PCB routing & In progress \\
|
|
Tile footprint correction & In progress \\
|
|
Board manufacturing & Planned \\
|
|
Hardware testing & Planned \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
\subsection{Bicycle-Cargo System Control Results}
|
|
|
|
\subsubsection{Simulation Results}
|
|
The closed-loop Simulink model presented in the subsection~\ref{subsec:Simulink_model} was used to evaluate the
|
|
performance of the proposed PI-based (Proportional-Integral) control strategy.
|
|
|
|
Figure~\ref{fig:tracking-error} shows the evolution of the tracking error between the bicycle and the cargo cart during
|
|
simulation. The response exhibits an initial transient phase followed by a progressive convergence toward the desired
|
|
equilibrium position, demonstrating stable closed-loop behaviour and satisfactory tracking performance.
|
|
\begin{figure}[!h]
|
|
\centering
|
|
\includegraphics[width=\linewidth]{./Figures/error_fig.png}
|
|
\caption{Position tracking error between bicycle and cargo cart.}
|
|
\label{fig:tracking-error}
|
|
\end{figure}
|
|
|
|
\subsubsection{Experimental Load Characterization}
|
|
Experimental tests were conducted on flat terrain in order to evaluate the influence of mechanical load on the motor
|
|
current consumption of the cargo cart system. The system was powered using a \SI{48}{\volt} battery pack.
|
|
|
|
Current measurements were acquired using an Analog Discovery 2 connected to a computer running the WaveForms software
|
|
environment. A current clamp probe was used to measure the motor current, and the signals were sampled at
|
|
\SI{1}{\kilo\hertz}.
|
|
|
|
During each test, the throttle command was set to its maximum value in order to produce the highest possible
|
|
acceleration. Once the maximum speed was reached, the motor current naturally decreased and stabilised as the motor
|
|
only compensated for rolling resistance and friction effects.
|
|
|
|
Three loading conditions were investigated corresponding approximately to one, two, and three passengers inside the
|
|
cargo cart. The motor current measured during these experiments is shown in Fig.~\ref{fig:motor-currents}.
|
|
|
|
\begin{figure}[!h]
|
|
\centering
|
|
\includegraphics[width=\linewidth]{./Figures/Motor_currents.png}
|
|
\caption{Measured motor current under three loading conditions.}
|
|
\label{fig:motor-currents}
|
|
\end{figure}
|
|
|
|
The results show a significant current peak during the acceleration phase, reaching the controller limit of
|
|
approximately \SI{25}{\ampere}. After this transient phase, the current decreases and converges toward a lower
|
|
steady-state value corresponding mainly to friction and resistive force compensation.
|
|
|
|
As expected, higher loading conditions resulted in higher steady-state current consumption, indicating an increase in
|
|
the required motor torque. In addition, the duration during which the current remained close to the maximum controller
|
|
limit also increased with heavier loads, reflecting the longer acceleration time required to reach steady-state
|
|
operation.
|
|
These variations are mainly attributed to terrain irregularities, throttle response fluctuations, and limitations
|
|
associated with the measurement setup and current probe acquisition chain.
|
|
|
|
However, due to the absence of direct velocity measurements during the experiments, only qualitative observations could
|
|
be extracted from these tests. Consequently, a precise estimation of dynamic friction parameters and energy efficiency
|
|
could not be achieved.
|
|
|
|
\subsection{FOC Controller Validation}
|
|
|
|
\subsubsection{Current Status Summary}
|
|
|
|
Table~\ref{tab:foc_status} summarizes the current status of the FOC
|
|
controller development.
|
|
|
|
\begin{table}[htbp]
|
|
\caption{FOC controller development status}
|
|
\label{tab:foc_status}
|
|
\centering
|
|
\begin{tabular}{l c}
|
|
\toprule
|
|
\textbf{Task} & \textbf{Status} \\
|
|
\midrule
|
|
VESC firmware compilation & Completed \\
|
|
Pin compatibility (F405 / L476) & Completed \\
|
|
Schematic design (KiCad) & Completed \\
|
|
ERC validation & Completed \\
|
|
PCB routing & In progress \\
|
|
Tile footprint correction & In progress \\
|
|
Board manufacturing & Planned \\
|
|
Hardware testing & Planned \\
|
|
\bottomrule
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
|
|
% ******************************** DISCUSSION **************************************************************************
|
|
|
|
|
|
\section{Discussion}
|
|
This project could be seen as an introduction to the VESC project for someone who don't know about it from beforehand,
|
|
the challenges the new users face during setup, as well as a demand for clear expectations concerning documentation
|
|
on the subject. The project the MAD is leading should probably not be a fork of the project, as the project is still
|
|
in development.
|
|
|
|
As a final note, this proved to be a project which could easily be developed into several different projects in
|
|
different fields. Some projects could be continued later on as a different PIR subject, other could be proposed to
|
|
later years in different spesialisations like TLS SEC, ESPE. Our thoughts on the following projects that could be
|
|
explored are the following.
|
|
|
|
The fabrication line for electronics is globalised. This is okay in a stable world, but it could be a problem in a world
|
|
full of instability, be it war, blockages, or tarifs. The idea of opening a spesialisation in cooperation with AIME came
|
|
up as an idea.
|
|
|
|
For TLS SEC the subject could be the design for a fitting mechanism to restrict certain priveligies to certified
|
|
personnel that could be used in the C programming language. Later down the line we could also see the possibility to
|
|
analyse the Bluetooth frames in order to manipulate them in order to change important parameters.
|
|
|
|
The continuation on the PCB could be a subject fitting an ESPE spesialisation.
|
|
|
|
The proposition of and supply of a vesc system to play with and troubleshoot could be a good rule of thumb, which
|
|
allows for a quicker start and gives among other things an idea of the budget and the supply line used by a entity
|
|
in the sector. Proposing a visit could also be one way to familiarise students with the association.
|
|
|
|
What should be a clear conclusion from our test with the jammer is that a controlles based on Bluetooth alone should be
|
|
avoided when possible and practical. Examples where this could be relevant include electric skateboards, as cables could
|
|
impose a tripping hazard. There, an encapsulation of an encrypted control frame could be an thought.
|
|
|
|
% ******************************** Perspectives and Future Work ************************************************************
|
|
|
|
\section{Perspectives and Future Work}
|
|
|
|
Based on the results obtained and the limitations identified during this
|
|
project, several directions for future work are proposed.
|
|
|
|
\subsection{Hardware Completion and Testing}
|
|
The VESC-based FOC PCB requires routing completion and prototype
|
|
manufacturing. Once fabricated, the board must be tested under real
|
|
operating conditions (varying loads, road profiles, and battery voltage).
|
|
|
|
% ******************************** CONCLUSION **************************************************************************
|
|
|
|
\section{Conclusion/Summary}
|
|
|
|
%\begin{figure}[htbp]
|
|
%%\centerline{\includegraphics{fig1.png}}
|
|
%caption{Example of a figure caption.}
|
|
%\label{fig}
|
|
%\end{figure}
|
|
|
|
%Figure Labels: Use 8 point Times New Roman for Figure labels. Use words
|
|
%rather than symbols or abbreviations when writing Figure axis labels to
|
|
%avoid confusing the reader. As an example, write the quantity
|
|
%``Magnetization'', or ``Magnetization, M'', not just ``M''. If including
|
|
%units in the label, present them within parentheses. Do not label axes only
|
|
%with units. In the example, write ``Magnetization (A/m)'' or ``Magnetization
|
|
%\{A[m(1)]\}'', not just ``A/m''. Do not label axes with a ratio of
|
|
%quantities and units. For example, write ``Temperature (K)'', not
|
|
%``Temperature/K''.
|
|
|
|
|
|
% ******************************** REMERCIEMENTS **************************************************************************
|
|
|
|
\section*{Acknowledgment}
|
|
|
|
The authors would like to thank Pascal Acco and Thierry Rocacher for their
|
|
continuous technical guidance and support throughout this project. Their
|
|
expertise in power electronics, embedded systems, and PCB design was
|
|
invaluable.
|
|
|
|
We also thank La Manufacture Autonome Décentralisée (LaMAD) for providing
|
|
the use case, the technical requirements, and the cargo bike platform used
|
|
for validation.
|
|
|
|
Finally, we acknowledge the INSA Toulouse GEI department for providing
|
|
access to laboratory facilities, measurement equipment, and the necessary
|
|
components for prototyping.
|
|
|
|
This work was carried out as part of the 4th-year research project (PIR)
|
|
at INSA Toulouse.
|
|
|
|
% ******************************** IA **************************************************************************
|
|
\section*{Statement on AI Usage}
|
|
|
|
The authors acknowledge the use of generative AI tools during this project, both for the development work and for
|
|
writing this paper.
|
|
|
|
AI was used as a helper in several parts of the project. This includes support for understanding and structuring
|
|
technical ideas, and giving suggestions during the development of different subsystems. It was also used to help with
|
|
writing, rephrasing, and improving clarity in the report.
|
|
|
|
However, all final decisions, implementations, and validations were done by the authors. The AI outputs were always
|
|
checked, corrected when needed, and adapted based on reliable technical sources and our own experiments and
|
|
understanding of the system.
|
|
|
|
We consider AI as a useful tool to speed up thinking and writing, but not as a source of final technical truth.
|
|
Everything related to design choices, analysis, and results was verified and fully controlled by the authors.
|
|
|
|
The use of AI tools in this work follows the IEEE guidelines for generative AI usage in publications.
|
|
|
|
%Please number citations consecutively within brackets \cite{b1}. The
|
|
%sentence punctuation follows the bracket \cite{b2}. Refer simply to the reference
|
|
%number, as in \cite{b3}---do not use ``Ref. \cite{b3}'' or ``reference \cite{b3}'' except at
|
|
%the beginning of a sentence: ``Reference \cite{b3} was the first $\ldots$''
|
|
|
|
\bibliographystyle{IEEEtran}
|
|
\bibliography{PIR_MadMax3}
|
|
|
|
|
|
\end{document}
|