taban/PIR_MadMax
2
4
Fork 0
Code Issues 4 Pull requests Projects Releases Packages Wiki Activity Actions

Formater les auteurs + ajout du texte

Browse source
This commit is contained in:
Oskar Orvik 2026-05-11 13:32:19 +02:00
parent b9d74de63d
commit 02045cc7e6
1 changed files with 17 additions and 22 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

39
Sécurité/Template_Latex.tex
View file

@ -23,31 +23,31 @@
\textit{INSA Toulouse}\\
Toulouse, France \\
Abescat@insa-toulouse.fr}
\and
%\and
\IEEEauthorblockN{Karima Attar}
\IEEEauthorblockA{\textit{GEI} \\
\textit{INSA Toulouse}\\
Toulouse, France \\
Attar@insa-toulouse.fr}
%\and
\and
\IEEEauthorblockN{Brage Flønæs Johnsen}
\IEEEauthorblockA{\textit{GEI} \\
\textit{INSA Toulouse}\\
Toulouse, France \\
Johnse@insa-toulouse.fr} \\
Johnse@insa-toulouse.fr}
%\and
\IEEEauthorblockN{Oskar Orvik}
\IEEEauthorblockA{\textit{GEI} \\
\textit{INSA Toulouse}\\
Toulouse, France \\
Orvik@insa-toulouse.fr}
\and
%\and
\IEEEauthorblockN{Julien Pavillon}
\IEEEauthorblockA{\textit{GEI} \\
\textit{INSA Toulouse}\\
Toulouse, France \\
Pavillon@insa-toulouse.fr}
%\and
\and
\IEEEauthorblockN{Nolan Reynier Nomer}
\IEEEauthorblockA{\textit{GEI} \\
\textit{INSA Toulouse}\\
@ -76,6 +76,8 @@ The fast urbanization of global logistics has positioned electric cargo bikes as
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 laMAD, where their responsibility and control begins and ends. Should there be a difference between the firmware loaded on a product from laMAD than what is publicly available?
\section{Litterature review}
\section{Research gap}
@ -84,41 +86,34 @@ Despite this progress, limited research has examined the adaptation of open-sour
\section{The aim of the study}
This report presents the design and implementation of a VESC-based motor controller tailored to the needs of the Manufacture Autonome Décentralisée (MAD), an organisation operating electric cargo bikes and freight tricycles. We aim to focus on adapting the VESC open-source firmware to support both FOC and trapezoidal commutation, integrating positional control, and addressing Bluetooth security, while prioritising local manufacturability at INSA Toulouse.
\section{Bluetooth Low Energy}
\section{Software and Connectivity}
\subsection{BLE compatibility with the VESC}
\subsection{BLE Compatibility With the VESC}
VESC-controllers are not 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 is because the HC-05 is not adapted for BLE as a base. For the future, choosing a bluetooth module supporting BLE will be the easiest solution.
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 is because the HC-05 is not adapted for BLE as a base. Needing 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.
\subsection{BLE vulnerability}
Bluetooth could be a vulnerability to a VESC if the VESC is to be used as a controller in real-time, as the controller could be jammed. It could also be investigated how the connection to the besc controller could be modified using the vesc tool. We will touch more on the accessability of the code within the vesc tool sooner.
\subsection{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. 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{Testing of BLE-modules}
What we have done: Flash VESC on a discovery-card. We connected 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. This is an important limitation to consider when designing a VESC system.
What we have done: Flash VESC on a discovery-card. We connected 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.
\section{Code integrity}
As the project is open source, and the code
\subsection{Abbreviations and Acronyms}\label{AA}
Define abbreviations and acronyms the first time they are used in the text,
even after they have been defined in the abstract. Abbreviations such as
IEEE, SI, MKS, CGS, ac, dc, and rms do not have to be defined. Do not use
abbreviations in the title or heads unless they are unavoidable.
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.
\subsection{VESC compiling}
We have been able to compile the VESC tool and the VESC firmware. This firmware has been put onto an STM32F4xx Discovery card. This poses several problems for our progress on the topic of cybersecurity. We will however 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 eiter. 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 laMAD, as laMAD could propose some models they're interested in.
We have been able to compile the VESC tool and the VESC firmware. This firmware has been put onto an STM32F4xx Discovery card. This poses several obstacles for our progress on the topic of cybersecurity. We will however 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 eiter. 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 laMAD, as laMAD could propose some models they're interested in.
We also found that the information on the VESC is scattered around the net. 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 also found that the information on the VESC is scattered around the net. 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 laMAD associates.
\subsection{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 laMAD 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 laMADs equipment which is in a traffic friendly manner.
When we flashed newer firmware from the project made by Benjamin Veeder\footnote{https://github.com/vedderb/bldc/}, 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 laMAD as well in the context of training for the people working on the motor control part of the e-bike.
\subsection{Discussion}