parent
1f86a799d0
commit
fe0b6b2dca
1 changed files with 237 additions and 144 deletions
|
|
@ -183,11 +183,28 @@ carries higher hardware costs (sensors, processing power).
|
||||||
FOC provides faster response times and better load disturbance rejection \cite{jomsa-nga_torque_2024}.
|
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
|
\section{Research Gap}
|
||||||
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
|
The literature presented in the previous sections shows that significant work has been carried out on BLDC
|
||||||
that are critical for decentralised, community-operated fleets.
|
motor control strategies, especially for torque ripple reduction, efficiency improvement, and dynamic performance
|
||||||
|
optimisation. Open-source projects such as VESC also provide high-performance and flexible solutions for electric
|
||||||
|
mobility systems.
|
||||||
|
|
||||||
|
However, most existing works mainly focus on control performance and do not consider low-tech constraints such as
|
||||||
|
local manufacturing, hardware repairability, or component accessibility. In many existing controllers, the hardware
|
||||||
|
design remains difficult to reproduce or repair without specialized equipment or advanced electronic knowledge.
|
||||||
|
|
||||||
|
In addition, the integration of wireless communication introduces new security concerns. While BLE connectivity
|
||||||
|
simplifies configuration and monitoring, unauthorized access to controller parameters could create safety risks,
|
||||||
|
especially for electric cargo bikes operating in public spaces.
|
||||||
|
|
||||||
|
To the best of our knowledge, there is currently no open-source motor controller that simultaneously addresses
|
||||||
|
high-performance control, local manufacturability, repairability, and BLE security for decentralized cargo bike
|
||||||
|
applications.
|
||||||
|
|
||||||
|
This project therefore aims to explore a modular and repair-oriented motor controller architecture compatible
|
||||||
|
with VESC while remaining adapted to the constraints of the Manufacture Autonome Décentralisée (MAD).
|
||||||
|
|
||||||
|
|
||||||
\section{Aim and Research Objectives}
|
\section{Aim and Research Objectives}
|
||||||
|
|
@ -228,143 +245,161 @@ assistance based on system dynamics.
|
||||||
\section{STM32-Based Field-Oriented Control Motor Drive}
|
\section{STM32-Based Field-Oriented Control Motor Drive}
|
||||||
\label{sec:foc}
|
\label{sec:foc}
|
||||||
|
|
||||||
This section presents the design and implementation of a high-performance
|
This section presents the design and implementation of a high-performance
|
||||||
motor controller based on Field-Oriented Control (FOC).
|
motor controller based on Field-Oriented Control (FOC).
|
||||||
|
|
||||||
\subsection{Choice of FOC Over Trapezoidal Commutation}
|
\subsection{Choice of FOC Over Trapezoidal Commutation}
|
||||||
|
|
||||||
Table~\ref{tab:foc_vs_trap} summarizes the key differences between the
|
Table~\ref{tab:foc_vs_trap} summarizes the key differences between the
|
||||||
two commutation strategies, based on the literature reviewed in
|
two commutation strategies, based on the literature reviewed in
|
||||||
Section~\ref{sec:relatedwork}.
|
Section~\ref{sec:related}.
|
||||||
|
|
||||||
\begin{table}[htbp]
|
\begin{table}[htbp]
|
||||||
\caption{Comparison between FOC and trapezoidal (six-step) commutation}
|
\caption{Comparison between FOC and trapezoidal (six-step) commutation}
|
||||||
\label{tab:foc_vs_trap}
|
\label{tab:foc_vs_trap}
|
||||||
\centering
|
\centering
|
||||||
\begin{tabular}{lcc}
|
\begin{tabular}{lcc}
|
||||||
\toprule
|
\toprule
|
||||||
\textbf{Criterion} & \textbf{FOC} & \textbf{Six-Step} \\
|
\textbf{Criterion} & \textbf{FOC} & \textbf{Six-Step} \\
|
||||||
\midrule
|
\midrule
|
||||||
Torque ripple (at 500 rpm) & \SI{18.4}{\percent} & \SI{35.7}{\percent} \\
|
Torque ripple (at 500 rpm) & \SI{18.4}{\percent} & \SI{35.7}{\percent} \\
|
||||||
Low-load efficiency & High & Moderate \\
|
Low-load efficiency & High & Moderate \\
|
||||||
High-speed switching loss & Higher & Lower \\
|
High-speed switching loss & Higher & Lower \\
|
||||||
Position sensor requirement & Encoder (high resolution) & Hall sensors \\
|
Position sensor requirement & Encoder (high resolution) & Hall sensors \\
|
||||||
Implementation complexity & High & Low \\
|
Implementation complexity & High & Low \\
|
||||||
Hardware cost & Higher & Lower \\
|
Hardware cost & Higher & Lower \\
|
||||||
Dynamic response & Fast & Standard \\
|
Dynamic response & Fast & Standard \\
|
||||||
\bottomrule
|
\bottomrule
|
||||||
\end{tabular}
|
\end{tabular}
|
||||||
\end{table}
|
\end{table}
|
||||||
|
|
||||||
For our cargo bike application, rider comfort and smooth torque delivery
|
For our cargo bike application, rider comfort and smooth torque delivery
|
||||||
are priorities. FOC was therefore selected for the high-performance
|
are priorities. FOC was therefore selected for the high-performance
|
||||||
controller, while a separate low-tech six-step board (Section~\ref{sec:sixstep})
|
controller, while a separate low-tech six-step board (Section~\ref{sec:sixstep})
|
||||||
was developed for repairability.
|
was developed for repairability.
|
||||||
|
|
||||||
\subsection{Base Design: Cheap FOCer-2 Project}
|
\subsection{Base Design: Cheap FOCer-2 Project}
|
||||||
|
|
||||||
The starting point was the open-source \textit{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
|
which provides a complete KiCad design for a VESC-compatible board based
|
||||||
on an STM32F405 microcontroller. This design includes:
|
on an STM32F405 microcontroller. This design includes:
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\item A three-phase MOSFET full-bridge power stage.
|
\item A three-phase MOSFET full-bridge power stage.
|
||||||
\item Gate drivers with built-in dead-time insertion.
|
\item Gate drivers with built-in dead-time insertion.
|
||||||
\item Shunt resistors for phase current sensing.
|
\item Shunt resistors for phase current sensing.
|
||||||
\item USB and CAN interfaces.
|
\item USB and CAN interfaces.
|
||||||
\item An expansion header for encoder or Hall sensors.
|
\item An expansion header for encoder or Hall sensors.
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
|
|
||||||
The existing KiCad schematic and layout were used as the baseline for
|
The existing KiCad schematic and layout were used as the baseline for
|
||||||
our adaptations.
|
our adaptations.
|
||||||
|
|
||||||
\subsection{Integration of the Rocacher FOC Tile}
|
\subsection{Integration of the Rocacher FOC Tile}
|
||||||
|
|
||||||
Mr. Rocacher provided the Kicad schematic of a ready-to-use FOC tile based on an STM32L476
|
Mr. Rocacher provided the Kicad schematic of a ready-to-use FOC tile based on an STM32L476
|
||||||
microcontroller.
|
microcontroller.
|
||||||
|
|
||||||
The initial idea was to make this tile \textit{pluggable} into our
|
The initial idea was to make this tile \textit{pluggable} into our
|
||||||
carrier board, similar to an Arduino shield. This would allow :
|
carrier board, similar to an Arduino shield. This would allow :
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\item Easy replacement of the computing core without re-soldering.
|
\item Easy replacement of the computing core without re-soldering.
|
||||||
\item Modular upgrades of the microcontroller.
|
\item Modular upgrades of the microcontroller.
|
||||||
\item Simplified repair and maintenance.
|
\item Simplified repair and maintenance.
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
|
|
||||||
However, the Cheap FOCer-2 project was not designed for such modularity.
|
However, the Cheap FOCer-2 project was not designed for such modularity.
|
||||||
Its routing is dense and highly optimized for a single, non-removable
|
Its routing is dense and highly optimized for a single, non-removable
|
||||||
F405 chip. Adapting it to accept an L476 tile while preserving all
|
F405 chip. Adapting it to accept an L476 tile while preserving all
|
||||||
critical functions (PWM, current sensing, USB communication) proved
|
critical functions (PWM, current sensing, USB communication) proved
|
||||||
challenging.
|
challenging.
|
||||||
|
|
||||||
\subsection{Pin Compatibility Verification: L476 vs F405}
|
\subsection{Pin Compatibility Verification: L476 vs F405}
|
||||||
|
|
||||||
Before modifying the PCB, a thorough pin compatibility check was
|
Before starting the PCB modifications, a pin compatibility study was carried out between the STM32L476
|
||||||
performed between the STM32L476 and the STM32F405
|
used on the Rocacher tile and the STM32F405 originally used in the Cheap FOCer-2 design. The objective
|
||||||
(original Cheap FOCer-2 design). The following aspects were examined:
|
was to verify that the main functions required by the VESC firmware could still be used after replacing
|
||||||
\begin{itemize}
|
the original microcontroller.
|
||||||
\item Physical pinout in LQFP64 package.
|
|
||||||
\item Alternate functions for PWM timers.
|
The verification mainly focused on:
|
||||||
\item USB DP/DM pins (PA11/PA12).
|
\begin{itemize}
|
||||||
\item Analog inputs for current sensing.
|
\item Physical pinout compatibility in the LQFP64 package,
|
||||||
\item UART for BLE communication.
|
\item PWM timer for Alternate functions,
|
||||||
\end{itemize}
|
\item USB DP/DM pins (PA11/PA12),
|
||||||
|
\item Analog inputs for current sensing,
|
||||||
Three pin conflicts were identified and resolved as follows.
|
\item UART communication for BLE integration.
|
||||||
|
\end{itemize}
|
||||||
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
|
During this analysis, three main pin conflicts were identified.
|
||||||
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
|
\begin{figure}[!h]
|
||||||
compatible alternate function.
|
|
||||||
|
\centering
|
||||||
Second, the gate driver enable signal (EN\_GATE) was originally assigned
|
\includegraphics[width=\linewidth]{../PCB/CompatibiliteL4F4.pdf}
|
||||||
to PB5 on the F405. This pin is not accessible on the L476
|
\caption{Comparison of F405 and L476 pin configurations}
|
||||||
tile. The signal was therefore moved to PC5, which is available and
|
|
||||||
can be configured as a standard GPIO output.
|
\end{figure}
|
||||||
|
|
||||||
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
|
The first conflict concerned the SPI\_MISO signal on pin PA6. In the original STM32F405 design, this pin is
|
||||||
therefore reassigned to PB3, configured as TIM2\_CH2, which provides
|
used for SPI communication related to current sensing. On the STM32L476 tile, the same pin is associated with
|
||||||
the necessary input capture functionality for Hall signal decoding.
|
a DAC output, creating a functional conflict. To solve this issue, the SPI communication line was remapped
|
||||||
|
to PA5 on the L476, which offers a compatible alternate function.
|
||||||
All other critical functions (PWM timers, complementary PWM, enable
|
|
||||||
signals, encoder inputs, UART, USB, and CAN) remain fully compatible
|
The second issue concerned the EN\_GATE signal. In the original design, this signal was connected to PB5 on
|
||||||
between the two microcontrollers. The ADC channel differences between
|
the STM32F405. However, this pin is not accessible on the L476 tile. The signal was therefore moved to PC5,
|
||||||
the F405 (ADC123/ADC12) and the L476 (ADC3) must still be handled in
|
configured as a standard GPIO output.
|
||||||
firmware, as noted previously.
|
|
||||||
|
Finally, Hall sensor C was originally connected to PC8 (TIM8) on the STM32F405. Since this pin is not available
|
||||||
\subsection{Schematic Design and KiCad Implementation}
|
on the tile connector, the Hall sensor input was reassigned to PB3 using the TIM2\_CH2 alternate function,
|
||||||
|
which preserves the input capture capability required for Hall sensor decoding.
|
||||||
The original Cheap FOCer-2 schematic was modified in KiCad to replace the
|
|
||||||
integrated F405 with connectors for the L476 tile. The main modifications
|
All other important functions remained compatible between the two microcontrollers, including PWM generation,
|
||||||
included:
|
complementary PWM outputs, encoder inputs, UART, USB, and CAN communication. Some differences between the ADC
|
||||||
\begin{itemize}
|
peripherals of the STM32F405 and STM32L476 still remain and will require firmware adaptations in future work.
|
||||||
\item Removal of the F405 and its associated passive components.
|
|
||||||
\item Addition of two 20-pin headers to receive the Rocacher tile.
|
\subsection{Schematic Design and KiCad Implementation}
|
||||||
\item Re-routing of PWM, ADC, and USB signals to the headers.
|
|
||||||
\end{itemize}
|
The original Cheap FOCer-2 schematic was modified in KiCad in order to replace the integrated STM32F405
|
||||||
|
microcontroller with connectors for the Rocacher STM32L476 tile. The objective was to make the control part more
|
||||||
The schematic passed Electrical Rule Check (ERC) with no errors.
|
modular and easier to replace without modifying the power stage of the board.
|
||||||
|
|
||||||
\subsection{Routing Challenges and Current Status}
|
The main modifications performed on the schematic were:
|
||||||
|
\begin{itemize}
|
||||||
The PCB layout was then started. The original Cheap FOCer-2 routing is
|
\item Removal of the STM32F405 and its associated passive components.
|
||||||
very dense. Inserting connectors for the removable tile while maintaining signal integrity proved
|
\item Addition of two 20-pin headers for the L476 tile connection.
|
||||||
difficult.
|
\item Re-routing of PWM, ADC, USB, and communication signals toward the headers.
|
||||||
|
\end{itemize}
|
||||||
The main issues encountered were:
|
|
||||||
\begin{itemize}
|
Special attention was given to the routing of critical control signals, especially the PWM outputs used for
|
||||||
\item Some footprints for the tile connectors did not appear correctly
|
motor commutation and the analog signals used for current sensing.
|
||||||
in the layout after schematic import.
|
|
||||||
\item Routing of high-current paths (battery, motor phases) around the
|
After the modifications, the schematic was verified using the KiCad Electrical Rule Check (ERC). No electrical
|
||||||
connectors required additional vias, increasing resistance.
|
errors were detected during this verification step, which validated the consistency of the schematic before
|
||||||
\item Decoupling capacitors had to be repositioned, raising concerns
|
starting the PCB routing phase.
|
||||||
about switching noise.
|
|
||||||
\end{itemize}
|
\subsection{Routing Challenges and Current Status}
|
||||||
|
|
||||||
Currently, the schematic is validated, and the layout is under
|
After validating the schematic, the PCB routing phase was started in KiCad. The original Cheap FOCer-2 board
|
||||||
development. Once routing is completed, the board will be manufactured
|
uses a very compact layout with dense routing around the STM32F405 microcontroller and the power stage.
|
||||||
and tested with the VESC firmware adapted to the L476 tile.
|
Integrating connectors for a removable STM32L476 tile introduced several additional routing constraints.
|
||||||
|
|
||||||
|
One of the main difficulties was maintaining proper signal routing while keeping enough space for the tile
|
||||||
|
connectors and preserving the integrity of the control signals. Particular attention had to be given to the PWM
|
||||||
|
signals, current sensing traces, and power connections.
|
||||||
|
|
||||||
|
Several issues were encountered during the routing process:
|
||||||
|
\begin{itemize}
|
||||||
|
\item Some connector footprints associated with the tile did not appear correctly after importing the schematic
|
||||||
|
into the PCB layout.
|
||||||
|
\item The routing of high-current paths, especially the battery and motor phase connections, become more complex
|
||||||
|
due to the additional connectors and required extra vias.
|
||||||
|
\item Some Decoupling capacitors had to be repositioned, which could potentially affect switching noise and power
|
||||||
|
supply stability.
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
At the current stage of the project, the schematic has been validated and the PCB layout is still under development.
|
||||||
|
Once the routing is completed, the board will be manufactured and tested using the VESC firmware adapted for the
|
||||||
|
STM32L476 tile.
|
||||||
|
|
||||||
|
|
||||||
% ************************************** SOFTWARE AND CONNECTIVITY *****************************************************
|
% ************************************** SOFTWARE AND CONNECTIVITY *****************************************************
|
||||||
|
|
@ -375,7 +410,7 @@ assistance based on system dynamics.
|
||||||
|
|
||||||
\subsubsection{First Experiment}
|
\subsubsection{First Experiment}
|
||||||
VESC-controllers are not necessarily equipped with Bluetooth-modules by default. Often, it is necessary to add a
|
VESC-controllers are not necessarily equipped with Bluetooth-modules by default. Often, it is necessary to add a
|
||||||
BT-module. A standard HC-05 bluetooth-module compatible with arduino is a great way to send and recieve
|
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.
|
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
|
This could be demonstrated using a ESP8622's standard library with said module, by letting us send characters from one
|
||||||
device to another.
|
device to another.
|
||||||
|
|
@ -626,6 +661,56 @@ where $e_{\text{ref}} = \SI{-0.5}{\meter}$ represents the desired equilibrium of
|
||||||
|
|
||||||
|
|
||||||
\subsection{Control Architecture Exploration}
|
\subsection{Control Architecture Exploration}
|
||||||
|
Beyond the standard PI control structure simulated in the previous sections, this project explores a more sophisticated
|
||||||
|
control law: the Cascaded Loop Architecture. This approach is envisioned as a high-level software enhancement to meet
|
||||||
|
the robustness and safety requirements inherent to electric cargo mobility. This means that our control law includes two
|
||||||
|
feedback loops that use two different physical parameters.
|
||||||
|
|
||||||
|
The selected cascaded structure is a well-established industry standard, particularly in high-performance motion control
|
||||||
|
and robotics. Similar architectures are widely employed in Automated Guided Vehicles (AGVs) and platooning systems,
|
||||||
|
where a “follower” unit must synchronize its dynamics with a “leader” unit through precise feedback loops.
|
||||||
|
|
||||||
|
The proposed approach decomposes the complex task of “cart following” into manageable sub-tasks by nesting control
|
||||||
|
loops:
|
||||||
|
\begin{itemize}
|
||||||
|
\item Outer loop: Position control layer.
|
||||||
|
Using a linear encoder or distance sensor mounted on the trailer’s hitch, the system measures the relative
|
||||||
|
displacement (error) between the bicycle and the cargo cart. This error is processed by a Proportional (P)
|
||||||
|
Controller. The primary goal of this stage is to translate physical distance into a target velocity setpoint. By
|
||||||
|
saturating the output of this loop, we can prevent the cargo cart from ever exceeding the bicycle’s speed, thereby
|
||||||
|
ensuring it never “pushes” the cyclist.
|
||||||
|
|
||||||
|
\item Inner loop: Velocity control layer.
|
||||||
|
The velocity setpoint generated by the outer loop is fed into this internal layer, the inner loop is responsible for
|
||||||
|
commanding the motor torque directly to compensate for immediate mechanical disturbances. Because this loop operates
|
||||||
|
at a higher frequency, it can reject disturbances such as sudden changes in rolling resistance or friction, before
|
||||||
|
they significantly impact the overall position error.
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\begin{figure}[!h]
|
||||||
|
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\linewidth]{./Figures/Schema_Autom_PIR.pdf}
|
||||||
|
\caption{Cascaded control architecture for the bicycle-cargo system.}
|
||||||
|
\label{fig:cascaded-loop}
|
||||||
|
|
||||||
|
\end{figure}
|
||||||
|
|
||||||
|
Fig.~\ref{fig:cascaded-loop} illustrates the cascade architecture for the dynamics of the cargo cart.
|
||||||
|
In this scheme, $x_{\text{ref}}$ denotes the desired position of the bicycle, whereas $x$ represents the measured
|
||||||
|
position of the cargo cart.
|
||||||
|
|
||||||
|
An outer Proportional Controller $K_{p,x}$ converts the position error $e_x = x_{\text{ref}} - x$ into a velocity
|
||||||
|
reference $v_{\text{ref}}$, which serves as the set-point for the inner loop.
|
||||||
|
The inner Proportional Controller $K_{p,v}$ then transforms the velocity error $e_v = v_{\text{ref}} - v$ into a
|
||||||
|
torque reference $\tau_{\text{ref}}$.
|
||||||
|
This command is processed by the motor/actuator block, which delivers the actual torque $\tau$.
|
||||||
|
The model of the plant maps this torque to velocity $v$, and the integrator $1/s$ reconstructs the position $x$.
|
||||||
|
|
||||||
|
The adoption of a cascaded loop architecture offers decisive advantages but comes with disadvantages. This precision
|
||||||
|
introduces increased complexity: the multiplication of tuning parameters and the requirement for high-resolution
|
||||||
|
feedback sensors, such as encoders, raise hardware costs and must come with high-performance software. These technical
|
||||||
|
constraints represent a significant challenge and may raise other issues.
|
||||||
|
|
||||||
|
|
||||||
% ******************************** RESULTS **************************************************************************
|
% ******************************** RESULTS **************************************************************************
|
||||||
|
|
@ -693,7 +778,7 @@ cargo cart. The motor current measured during these experiments is shown in Fig.
|
||||||
|
|
||||||
\begin{figure}[!h]
|
\begin{figure}[!h]
|
||||||
\centering
|
\centering
|
||||||
\includegraphics[width=\linewidth]{./Figures/Motor_currents.png}
|
\includegraphics[width=\linewidth]{./Figures/Motor_currents.pdf}
|
||||||
\caption{Measured motor current under three loading conditions.}
|
\caption{Measured motor current under three loading conditions.}
|
||||||
\label{fig:motor-currents}
|
\label{fig:motor-currents}
|
||||||
\end{figure}
|
\end{figure}
|
||||||
|
|
@ -785,6 +870,14 @@ The VESC-based FOC PCB requires routing completion and prototype
|
||||||
manufacturing. Once fabricated, the board must be tested under real
|
manufacturing. Once fabricated, the board must be tested under real
|
||||||
operating conditions (varying loads, road profiles, and battery voltage).
|
operating conditions (varying loads, road profiles, and battery voltage).
|
||||||
|
|
||||||
|
\subsection{Control Strategy Enhancement}
|
||||||
|
Future work includes the implementation and comparison of the PI controller and the cascaded control structure on the
|
||||||
|
cargo cart, in order to evaluate their performance under different conditions (load variations, road profiles, etc.).
|
||||||
|
|
||||||
|
In addition, the lack of direct velocity measurements limited the ability to fully characterise the system dynamics.
|
||||||
|
Adding a speed measurement or improving state estimation would allow a more complete analysis of the model.
|
||||||
|
|
||||||
|
|
||||||
% ******************************** CONCLUSION **************************************************************************
|
% ******************************** CONCLUSION **************************************************************************
|
||||||
|
|
||||||
\section{Conclusion/Summary}
|
\section{Conclusion/Summary}
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue