• MCU/ESC: STM32G431B-ESC1

• Motor: 2807 KV1300

• Encoder: AS5047P

I am a beginner. I have successfully controlled the motor in Open Loop, and it spins fine. Now, I am trying to add the AS5047P encoder for closed-loop control.

I connected the pins as follows:

• ESC Back (Hall Interface): GND / 5V / H3 / H2 / H1

• Encoder Pins: GND / 5V / I / A / B

Issue: I get zero readings/no angle change in the serial monitor when rotating the motor.

#include <SimpleFOC.h>

// Encoder definition: A-PA0, B-PA1, 4000 CPR, Index-PA2
Encoder encoder = Encoder(PA0, PA1, 4000, PA2);

void doA(){encoder.handleA();}
void doB(){encoder.handleB();}
void doIndex(){encoder.handleIndex();}

void setup() {
Serial.begin(115200);

// Initialize interrupts
encoder.enableInterrupts(doA, doB, doIndex);
encoder.init();
Serial.println(“Encoder ready”);
}

void loop() {
encoder.update();
Serial.println(encoder.getAngle());
}

4. Question: SPI Pin Locations
   Since ABI mode on the Hall pins is not working, I want to try SPI mode for better precision and absolute position. However, I cannot find the physical locations of the PA5, PA6, and PA7 (SPI1) pins on this specific board.

Could someone please help with:

Where are the SCK, MISO, MOSI, and CS pads/pins located on the B-G431B-ESC1 board?

I decided to retain v5.7 as a separate project and create a new one for v5.8. The v5.7 URL is gooser4_copy, which always annoyed me

• Increased the width of the tileable area by 1mm because Infineon mosfets were really crammed together (fine for hand assembly, but probably too tight for a machine)
• Changed mosfets to BSZ0500 (BSZ0901 runs much cooler than JMSL0302, but is NRND and this looks to be Infineon’s replacement for it)
• Changed the aux pin header to a proper communication connector
• Added more GPIO and reworked pins to give more SPI and UART options
• Added an LED controlled by PA12
• Changed HV buck to use the same IC and inductor as LV buck, reducing cost and board size
• Removed LV buck on single-motor version, and moved HV buck so it doesn’t increase board width
• Reverted to the smaller 3V regulator, except on the single-motor version
• Renamed VDRV and LVin to 11V and 5V
• Renamed the phase A,B,C order because the old way was confusing
• Shuffled the encoder pins to work nicely with STM32HWEncoder
• No more large exposed areas for copper bars. Just pads for SMD electrolytics, and alternative pads for soldering through-hole type electrolytics sticking off the side of the board (easier than SMD).
• Single-motor no longer has power input holes. Instead I’ve modified the bottom layer copper areas so the left half is HV_IN, allowing wires to be soldered to the board at the bottom edge like a typical ESC.

A few months ago I succumbed to peer pressure and made a version with CAN transceiver. It was a terrible struggle to squeeze it in, and even after achieving victory, I found that I wasn’t happy. What it really needed was more GPIO, and the CAN pins can’t be used for anything else. Besides, CAN is not much benefit for a design like Gooser where all the drivers are located near the battery, so I repurposed its two pins and added one more to the programming connector as well. I could have added two, but that would make the programming and communication connectors look identical, which opens up the possibility to accidentally plug a cable into the wrong one and fry something with the 11V and 5V pins.

When I tried using two SPI encoders on my CNC, it was confusing getting them both connected to the shared SPI pins among the two encoder connectors. Now there are two alternatives: One encoder utilizing both encoder connectors and the other on the programming connector, or both on the programming connector (which would still involve making a splitter cable, but a less confusing one than before). You do have to configure SWDIO and/or SWCLK as GPIO, and thus use the reset touchpad for programming, but that’s not such a big deal.

Having a second UART interface on the communication connector means you can still configure and debug it while the programming connector is in use by encoders.

I am new to the forums but have been experimenting with SimpleFOC for a few months now. Thanks for an amazing library! To give a bit of background, I am trying to make a camera gimbal for a drone. I have designed a custom PCB that uses an STM32G4 to control an iPower BLDC gimbal motor with a DRV8313 motor driver. I have added an AS5048A encoder for closed loop control and I am using a BMI323 IMU for the stabilisation. I have one PCB per axis for a 2 axis gimbal that work independently.

I have managed to implement closed loop velocity control and am now working on closed loop angle control as it is more intuitive to me but in my flight testing I have encountered an issue. When the gimbal meets a lot of resistance eg. wind, the FOC loop requests higher and higher voltages until it reaches the supply voltage limit. I have found that the FOC loop is exiting (I can tell as I lose all Serial Printing) resulting in the motor just holding position and no longer stabilising even when the external resistance is removed. Has anyone ever encountered this before and know a fix for it? I don’t mind if the gimbal lags slightly due to being under powered, I just need the FOC loop to continue pulling the max voltage if required until the disturbance is removed. ie. once the wind dies down I want the gimbal to still be stabilising and not have quit the main loop resulting in the motor just holding position.

I have already tried the following:

• increasing the motor.voltage_limit and driver.voltage_limit equal to driver.voltage_power_supply
• the voltage power supply cannot be increase any further due to restrictions on the platform (it is currently 13.6V)
• I am in the process of upgrading to a size bigger motors but expect to still have this issue from time to time

My one suspicion is that I have swapped the 100uF electrolytic capacitor for the DRV8313 for the same size but tantalum capacitor (20TQC100MD2) due to height restrictions on my board. Could this be causing these issues or is it more likely to be a software issue?

Thank you in advance for any help that anyone can offer!

• MCU/ESC: STM32G431B-ESC1

• Motor: 2807 KV1300

• Encoder: AS5047P

2. Status & Problem I am a beginner. I have successfully controlled the motor in Open Loop, and it spins fine. Now, I am trying to add the AS5047P encoder for closed-loop control.

I connected the pins as follows:

• ESC Back (Hall Interface): GND / 5V / H3 / H2 / H1

• Encoder Pins: GND / 5V / I / A / B

Issue: I get zero readings/no angle change in the serial monitor when rotating the motor.

#include <SimpleFOC.h>

// Encoder definition: A-PA0, B-PA1, 4000 CPR, Index-PA2
Encoder encoder = Encoder(PA0, PA1, 4000, PA2);

void doA(){encoder.handleA();}
void doB(){encoder.handleB();}
void doIndex(){encoder.handleIndex();}

void setup() {
Serial.begin(115200);

// Initialize interrupts
encoder.enableInterrupts(doA, doB, doIndex);
encoder.init();
Serial.println(“Encoder ready”);
}

void loop() {
encoder.update();
Serial.println(encoder.getAngle());
}

4. Question: SPI Pin Locations
   Since ABI mode on the Hall pins is not working, I want to try SPI mode for better precision and absolute position. However, I cannot find the physical locations of the PA5, PA6, and PA7 (SPI1) pins on this specific board.

Could someone please help with:

Where are the SCK, MISO, MOSI, and CS pads/pins located on the B-G431B-ESC1 board?

I’m working on a custom FOC motor controller using the DRV8316CRQRGFRQ1, and I have some questions regarding how to properly implement current sensing with the SimpleFOC library.

The DRV8316 uses low-side current sensing with integrated current sense amplifiers, and outputs an analog voltage of the form:

SOx = Vref/2 ± Gain × Iout

So from what I understand, I need to:

• Read the SOx signals using ADC

• Subtract the offset (Vref/2)

• Divide by gain (and shunt resistor?) to get current in amps

However, I’m a bit unsure about how this maps into SimpleFOC:

1. Should I use LowsideCurrentSense or GenericCurrentSense?
   Since the DRV8316 already includes current sense amplifiers, I’m wondering if GenericCurrentSense is more appropriate, where I manually convert ADC readings to current.

2. What should I use as the shunt resistance in LowsideCurrentSense?
   The driver doesn’t include internal shunt resistors (as far as I understand), so this depends on my external hardware. But since the output is already amplified, I’m unsure how to correctly set the parameters (gain vs shunt value).

3. Timing / synchronization:
   For low-side sensing, I assume ADC sampling needs to be synchronized with PWM (when low-side MOSFETs are on).
   Does SimpleFOC handle this internally when using LowsideCurrentSense, or do I need to manage ADC triggering manually?

If anyone has experience using DRV83xx drivers (especially DRV8316) with SimpleFOC, I’d really appreciate some guidance or example setups.

Thanks!

void loop() {
  //Shunt is 0.01R and gain is 50. 1A=0.01V=>0.5V/A
  //3.3V/50=0.066=6.6A=> +-3.3A
  //0A average is 1910, offset=137
  Serial.print(map(analogRead(34)+137,0,4095,-3300,3300));
  Serial.print("\t");
  Serial.print(map(analogRead(35)+137,0,4095,-3300,3300));
  Serial.print("\t");
  Serial.print(map(analogRead(36)+137,0,4095,-3300,3300));
  Serial.print("\t");
  Serial.println(map(analogRead(39)+137,0,4095,-3300,3300));
  delay(250);
}

Perfect measurements on all 4 channels.

I’ve also taken note of suggestions 2 and 3 from Runger’s comment;

Everything works separately, driver, encoder, current sense…

I’m getting inconsistent Pole Pair checks
Inconsistent current sense alignments (switch phases, invert them, all currents same magnitude…)
When in the webcontroller i set the target to zero in all motion and torque modes.
When setting the KV and induction parameters to 0 for the phase resistance testing the motor starts spinning with full current and horrendous noise. Setting PID’s to zero does nothing to stop the motor.

I’m really starting to run out of ideas and motivation.

#include <SimpleFOC.h>

#define PowerSupplyVoltage 12;
#define DriVolLim 2;
#define MotVolSenAli 1;
#define MotVolLim 12;
#define MotCurLim 1;
#define Skip_current_align false;
char motor0_id = 'L';
char motor1_id = 'R';
  
BLDCMotor motor0 = BLDCMotor(7, 0.182, 750, 0.03, 0.03);
BLDCMotor motor1 = BLDCMotor(7, 0.182, 750, 0.03, 0.03);

BLDCDriver3PWM driver0 = BLDCDriver3PWM(32, 33, 25);
BLDCDriver3PWM driver1 = BLDCDriver3PWM(26, 27, 14);

MagneticSensorI2C sensor0 = MagneticSensorI2C(AS5600_I2C);
MagneticSensorI2C sensor1 = MagneticSensorI2C(AS5600_I2C);

InlineCurrentSense current_sense0  = InlineCurrentSense(0.01f, 50.0f, 39, 36, _NC);
InlineCurrentSense current_sense1  = InlineCurrentSense(0.01f, 50.0f, 35, 34, _NC);

Commander command0 = Commander(Serial);
  
void doMotor0(char* cmd){command0.motor(&motor0, cmd);}
void doMotor1(char* cmd){command0.motor(&motor1, cmd);}
  
void setup() {
  Serial.begin(115200);
  delay(2000);
  Serial.println();
  Serial.println("Start!");
  Serial.println("Starting Serial");
  SimpleFOCDebug::enable(&Serial);

  Wire.setClock(400000);
  Wire.begin(19, 18, (uint32_t)400000);
  Wire1.setClock(400000);
  Wire1.begin(23, 5, (uint32_t)400000);
  
  sensor0.init(&Wire);
  sensor1.init(&Wire1);

  motor0.linkSensor(&sensor0);
  motor1.linkSensor(&sensor1);

  driver0.pwm_frequency = 15000;
  driver0.voltage_power_supply = PowerSupplyVoltage;
  driver0.voltage_limit = DriVolLim;
  driver1.pwm_frequency = 15000;
  driver1.voltage_power_supply = PowerSupplyVoltage;
  driver1.voltage_limit = DriVolLim;

  driver0.init();
  driver1.init();

  motor0.linkDriver(&driver0);
  motor1.linkDriver(&driver1);

  current_sense0.linkDriver(&driver0);
  current_sense1.linkDriver(&driver1);
  
  motor0.torque_controller = TorqueControlType::estimated_current;
  motor0.foc_modulation = FOCModulationType::SpaceVectorPWM;
  motor0.voltage_sensor_align = MotVolSenAli;
  motor0.voltage_limit = MotVolLim;
  motor0.current_limit = MotCurLim;
  motor0.useMonitoring(Serial);
  motor0.monitor_variables = _MON_TARGET | _MON_VEL | _MON_ANGLE | _MON_TARGET | _MON_VOLT_Q | _MON_VEL | _MON_ANGLE;
  motor0.monitor_downsample = 10;
  motor0.monitor_start_char = motor0_id;
  motor0.monitor_end_char = motor0_id;
  
  motor1.torque_controller = TorqueControlType::estimated_current;
  motor1.foc_modulation = FOCModulationType::SpaceVectorPWM;
  motor1.voltage_sensor_align = MotVolSenAli;
  motor1.voltage_limit = MotVolLim;
  motor1.current_limit = MotCurLim;
  motor1.useMonitoring(Serial);
  motor1.monitor_variables = _MON_TARGET | _MON_VEL | _MON_ANGLE | _MON_TARGET | _MON_VOLT_Q | _MON_VEL | _MON_ANGLE;
  motor1.monitor_downsample = 10;
  motor1.monitor_start_char = motor1_id;
  motor1.monitor_end_char = motor1_id;
  
  command0.verbose = VerboseMode::machine_readable;
  
  motor0.init();
  motor1.init();
  
  current_sense0.init();
  current_sense1.init();

  motor0.linkCurrentSense(&current_sense0);
  motor1.linkCurrentSense(&current_sense1);

  current_sense0.gain_a *=-1;
  current_sense0.gain_b *=-1;
  current_sense1.gain_a *=-1;
  current_sense1.gain_b *=-1;
  
  current_sense0.skip_align = Skip_current_align;
  motor0.initFOC();
  
  current_sense1.skip_align = Skip_current_align;
  motor1.initFOC();
  
  command0.add(motor0_id,doMotor0,"motor 0");
  command0.add(motor1_id,doMotor0,"motor 1");
  
  motor0.loopFOC();
  motor0.move(0);
  motor0.monitor();
  motor0.disable();
  
  motor1.loopFOC();
  motor1.move(0);
  motor1.monitor();
  motor1.disable();

  Serial.println("Starting main loop");
}

void loop() {
  motor0.loopFOC();
  motor0.move();
  motor0.monitor();

  motor1.loopFOC();
  motor1.move();
  motor1.monitor();

  command0.run();
}

Start!
Starting Serial
ESP32-DRV: Configuring 3PWM in group: 0 on timer: 0
ESP32-DRV: Configuring 2 operators.
ESP32-DRV: Configuring 3 comparators.
ESP32-DRV: Configuring 3 generators.
ESP32-DRV: Configuring center-aligned pwm.
ESP32-DRV: Enabling timer: 0
ESP32-DRV: MCPWM configured!
ESP32-DRV: Configuring 3PWM in group: 1 on timer: 0
ESP32-DRV: Configuring 2 operators.
ESP32-DRV: Configuring 3 comparators.
ESP32-DRV: Configuring 3 generators.
ESP32-DRV: Configuring center-aligned pwm.
ESP32-DRV: Enabling timer: 0
ESP32-DRV: MCPWM configured!
MOT:Monitor enabled!
MOT:Monitor enabled!
MOT:Init
MOT:Enable driver.
MOT:Init
MOT:Enable driver.
ESP32-CS: Configuring ADC1 channel 3
ESP32-CS: Configuring fast ADCs
ESP32-CS: Configuring ADC1 channel 0
ESP32-CS: Configuring fast ADCs
ESP32-CS: Configuring ADC1 channel 7
ESP32-CS: Configuring fast ADCs
ESP32-CS: Configuring ADC1 channel 6
ESP32-CS: Configuring fast ADCs
MOT:Align sensor.
MOT:sensor dir: CW
MOT:PP check: OK!
Skip dir calib.
MOT:Zero elec. angle: 2.14
MOT:Align current sense.
CS: Switch B-(C)NC
CS: Inv C
MOT:Success: 4
MOT:Ready.
MOT:Align sensor.
MOT:sensor dir: CCW
MOT:PP check: OK!
Skip dir calib.
MOT:Zero elec. angle: 2.18
MOT:Align current sense.
CS: Switch A-(C)NC
CS: Err B - all currents same magnitude!
ERR-MOT:Align error!
ERR-MOT:Init FOC fail
Starting main loop
L0.0000	0.0000	0.0000	1.5355L
R0.0000	0.0000	0.0024	-4.8044R
L0.0000	0.0000	0.0000	1.5355L
R0.0000	0.0000	-0.0858	-4.8060R

I’m going nowhere with the PID tunning and went back to the basics.

I’ve noticed that the velocity value when idle is not zero, it jumps around slowly to some random value. This is not an issue when testing the sensors separately with simplefoc’s AS5600 sensor test

I’ve also seen the current is not what is measured either, graph shows 1A but power supply is around 30ma:

10mOhm shunt with INA240A2 (gain of 50V/V), simplefoc’s inline test also shows odd results..
InlineCurrentSense current_sense0 = InlineCurrentSense(0.01f, 50.0f, 39, 36, _NC);

Any input on how to tackle these issues would be appreciated, thanks!

For other components, the Mosquito buck converter is called LMR14006YDDCR (LCSC part number C477919), and it needs a bunch of passives (open that MosquiNo board I linked before in EasyEDA and copy/paste). It’s good for space-limited designs because it switches at higher frequency than most bucks, so it can use a tiny inductor.

If you plan to actually use the robot arm for anything, I’d recommend at least 14-bit encoders. With 12-bit you can always feel a jitter in the motor when holding position, which will wear out bearings over time, in addition to hurting its accuracy. AS5047P is good, and $3.20/pc for 10+. But for 40 cents more, MT6835 is fabulous with 21-bit precision. The difference in jitter is nearly imperceptible to my hands, but visible on the DRO of my milling machine (the axis with MT6835 has a stable micrometer position, whereas AS5047P has a few micrometers of noise).

Thanks for the response. I’ve only done some basic PCB design in the past for much simpler projects. Any chance you could recommend a CAN chip?

Narrowing down the components list:

MCU: STM32G431 (probably the 5x5mm package)

Driver: DRV8313 (for simplicity) or MAX22213 (for current sensing)

Encoder: MT6701

CAN board: ?

Passives/other components: ?

Also wondering about the programming side, will there be a need to customize the firmware for this component stack? Specifically with regard to the CAN integration?

• INA181A1 current sense amplifier bandwidth => 350 kHz
• loop time 0.0006 s = 1666 Hz => Nyquist frequency = 833 Hz
• digital LPF time constant = 0.01 s => cutoff frequency = 14.6 Hz

So when the signal gets sampled, it should not have any frequencies above 833 Hz to avoid aliasing. But the bandwidth of the current sense amplifier is much higher, and the Nyquist theorem is hurt.

The slow digital low-pass filter can’t heal the situation in my opinion: at the time the signal gets sampled by the ADC the frequencies over the Nyquist frequency get folded back in the low-frequency area, and the signal is corrupted.

Any meanings/help?

Thx

A new way (available from v2.4.0+) would be to implement a custom control mode.
The output of the custom motion control callback is exactly what goes into the motor.current_sp.

So your custom motion control (with position cascade mode - see source) could look something like this:

// custom motion control function
float custom_motion_control(FOCMotor& motor) {
  // target shaft angle
  float shaft_angle_sp = motor->target;
  // calculate velocity set point
  float shaft_velocity_sp = feed_forward_velocity + P_angle( shaft_angle_sp - LPF_angle(motor->shaft_angle) );
  shaft_velocity_sp = _constrain(shaft_velocity_sp, -motor->velocity_limit, motor->velocity_limit);
  // calculate the torque command 
  float target_torque = PID_velocity(shaft_velocity_sp - motor->shaft_velocity); 

  // now clamp it
  target_torque = max(target_torque, MIN_CURRENT_A);
  return target_torque;
}

void setup(){
...
// link the mode to the motor
motor.linkCustomMotionControl(custom_motion_control);
// set custom mode to be used
motor.controller = MotionControlType::custom;
...
}

This solution is not perfect though. The velocity PID still considers that the limits are [-motor.current_limit, motor.current_limit] and not [MIN_CURRENT_A, motor.current_limit] and you might have some issues due to integrator windup.

I’m sorry in advance if this is a stupid question but it is exceeding my current programming skills.

I am currently bulding a cable driven robot for my final project and running out of time. Motors: Hoverboard Motors, ESP32 S3, Driver: Self built (working as intended), Encoder: AS5600 (I know it’s not recommended but working fine for now, will upgrade).

In short:

I am calculating the target angle and torque of the Motors in ROS and sending them to the 4 ESP32.

The motors need to be controlled in position control, to make sure the ropes reach their desired length BUT the motors must NEVER apply less than a minimum torque, to keep the cables tensioned.

So even if the target angle is in the clockwise direction, the Motor must always pull counter clockwise with a minimum torque. The motor can never actively unwind itself, otherwise the cable loses tension and falls off the pulleys. The Motor will reach it’s desired angle, becaus all the other ropes can pull stronger and unwind it while keeping all ropes tensioned.

I tried implementing this in the feedforward torque/current, but the PID Controller can “overrule” the feedforward current e.g. if the minimum torque is 1Nm and the PID controllers output is -2Nm, the Motor will apply -1Nm and unwind the cable.

I tried solving it with claude and it said to “clamp” the motor current setpoint to a minimum with this function after the motor.loopFOC() and motor.move(target_angle):
motor.current_sp = max(motor.current_sp, MIN_CURRENT_A)
This describes exactly what I want and makes perfect sense in my opinion.

However I can’t find motor.current_sp in any example program or variables. Where do i implement this function?

Thanks for every answer
Felix

Background to my question:

I’ve built a balancing bot, which generally already works, but I’ve noticed some optimization potential regarding the standstill capabilities.

So I want to start with the inner torque control loop and analyze and optimize its behavior in terms of control theory.

I wanted to check the bandwidth of the current controller, the digital low-pass filter, and maybe optimize the FOC loop time, which gives me the sample time of the system and defines the Nyquist frequency. In the next step I want to check the cutoff frequency of an analog low-pass filter in front of the current-sensing ADCs to avoid anti-aliasing (aliasing could results in folding back high frequencies into the low-frequency area and the controller wants to compensate for something that isn’t present, which could be the problem of my standstill performance).

But my driver board - and also 4 others I’ve checked - doesn’t have any anti-aliasing filters for current measurement.

So my question is, do I miss something regarding ADs and anti-aliasing fitlers, or are there badly designed driver boards on the market? I think the first assumption is true, but how do the boards avoid aliasing?

I’ve also read about sigma-delta ADCs. They work with oversampling and decimation, which results in a possibly simpler anti-aliasing filter.

But also with the sigma delta ADs, they are needed.

Thanks BEdyn

The STM32G031 is a little slow for SimpleFOC, though it would probably be fine for the low RPM of a robot arm. G431 is luxury, but the smallest package is 5x5mm instead of 4x4, and a little more expensive.

For the driver, MAX22213 is excellent for small size with current sense, but LCSC doesn’t carry it so you’ll probably have to do the assembly yourself. I use it on my stepstick. And if you’re assembling it yourself, then there’s a better chance you’ll be able to fit a CAN transceiver since you can do full double-sided rather than just the encoder on the back.

Step/dir can be problematic with long wire runs due to the possibility of electrical noise causing false steps, which never get corrected since it’s a purely relative protocol. I2C could work for sending absolute positions without taking up any board space, though it is of course more vulnerable to noise than CAN. But probably fine for a mini-arm.

I’m searching for a tiny form factor driver board that is compatible with SimpleFOC for a very small robot arm project. Ideally, the board size is 20x20 or smaller so that it can fit within the footprint of 220X Gimbal motors or smaller. Very low current draw requirements. I think I need current sensing for it to work well in the robot arm application, where the loads are constantly changing. It could be multiple stacked boards if needed.

I haven’t really found any boards that meet these requirements. I have seen the Mosquito board, that has a 20x20mm footprint, but it seems that some of the source files have been taken down? Also, the board did not include current sensing. I would be willing to spend the time (or resources) to develop a miniature board, but I don’t really know where to start. I think my requirements aren’t really out of the ordinary for SimpleFOC applications, so I’m surprised that nothing exists yet.

List of desired features of the tiny driver board:

• 20x20mm footprint or smaller. Can be 20mm diameter for a bit extra board space. At least 2 mounting holes required.
• 1-2A current
• 12-24V operating voltage
• On-board SPI encoder (AS5047 or similar)
• Current sensing
• Integrated MCU
• CAN communication and step/dir input

Can anyone point me in the right direction as far as current best practices for component selection and board design? I’m not sure which MCU and driver chip to use to ensure best compatibility and design simplicity.

Thanks in advance.

La placa utiliza un microcontrolador GD32F103RCT6 (compatible STM32F103) que controla dos motores BLDC de hoverboard.

El firmware original del hoverboard fue reemplazado por firmware modificado basado en el proyecto hoverboard firmware hack.

Actualmente el sistema compila y puede flashearse mediante ST-Link y STM32CubeIDE, pero se requiere modificar el firmware para implementar control remoto RC.

Objetivo del firmware

El objetivo es convertir el controlador del hoverboard en un controlador para vehículo RC con dirección usando uno de los motores de la hoverboard como si fuese un servo motor

El sistema debe controlar dos motores BLDC independientes.

Funciones requeridas

1. Control remoto RC

Entrada desde receptor RC de 4 canales PWM / PPM.

Canales utilizados:

•	CH1 → Dirección

•	CH2 → Aceleración / reversa

•	CH3 → Habilitar sistema (modo RC / modo manual

Failsafe por pérdida de señal

Si se pierde señal del receptor RC durante cierto tiempo (ej. 300 ms):

El firmware debe:

1\. cortar aceleración

2\. aplicar freno digital usando el motor

3\. detener el vehículo inmediatamente

Recuperación automática

Cuando la señal RC vuelve:

El sistema debe volver a habilitar el control sin reiniciar la placa.

5. Modo manual

Usando el canal 3 del control RC:

•	CH3 ON → modo RC

•	CH3 OFF → modo manual

En modo manual el vehículo puede ser controlado mediante un acelerador externo

Y llevando el motor de la dirección a 0 para que permita el movimiento libre de la misma

Limitación de velocidad

Debido a que el vehículo será usado por niños, el firmware debe permitir limitar:

•	velocidad máxima

•	aceleración

Hardware utilizado

Controlador principal:

GD32F103RCT6

Motores:

2 × BLDC hoverboard motors

Programador:

ST-Link

Entorno de compilación:

STM32CubeIDE

Firmware base:

Hoverboard firmware hack (STM32)

Lo que necesito

desarrollar

1\. modificar el firmware existente

2\. implementar la lógica RC

3\. implementar failsafe

4\. habilitar ambos motores correctamente

5\. entregar firmware compilable

Archivos requeridos:

•	código fuente

•	proyecto STM32CubeIDE

•	archivo .hex o .bin

Por favor si alguno de la comunidad me pudiera ayudar a hacer esto una realidad con el programa me sería de mucha ayuda, gracias por el tiempo que te tomaste para llegar hasta aquí y si me puedes ayudar con el programa te lo agradezco

Here is his youtube showing his creations:
https://m.youtube.com/@jazzboy/shorts

I use the following motor. low pole count, but cog free.

I tried higher pole gimbals, but found similar issues with cogging.

It is hard to get such a smooth velocity from a direct drive system, would it be possible to add a reduction of some kind. Some belt drive reduction of 5-10? That would bring you right to spec and should not take too much space.

Something else to try

At the beginning of SimpleFOC I’ve actually been working with someone who wanted to create an extra smooth camera gimbal for wedding photography and needed very very low speeds, under 10rpm. And the smoothness was the key.

We were able to get some very good initial results, we did not finish the project though. However, the results were apparently much better than the ones he was able to get with an odrive (I have not really tried to do so myself though). Odrive was not designed for gimbal motors (at least not at the time 7 years ago).

The first release of the library even had the velocity_ultra_slow motion control mode. Here is the link if you wanna take a look in the docs.

Basically the idea was that instead controlling the velocity we control the position. The velocity measurement is noisy and instead of deriving the position sensor angle into the velocity we integrate the target velocity into the target angle. This ideally makes for a bit more stable system as we can remove one noise source.

The code was very simple too, you could try it if you have time. For example by using the custom control mode

// helper variable for storing last target position value
float target_angle = 0;
// position based velocity control
float custom_motion_control(FOCMotor& motor) {

  // measure the time from the last call
  uint32_t timestamp_now = micros();
  dt = (timestamp_now - timestamp_prev) * 1e-6f;
  // quick fix for strange cases (micros overflow)
  if(dt <= 0 || dt > 0.5f) dt = 1e-3f;
  timestamp_prev = timestamp_now;
  
  // calculate the target angle
  float angle = motor->shaft_angle; 
  // angle_tar = angle_cur + velocity_tar * dt
  target_angle = target_angle + dt*motor->target; 

  // calculate the target voltage
  float target_voltage = P_angle(target_angle - motor->shaft_angle);

  // return the target voltage
  return target_voltage; 
}

Then you can enable it by linking this function to the motor and enabling custom control mode.

void setup(){
...
// set the control loop type to be used
motor.controller = MotionControlType::custom;
// use voltage control for more smoothness
motor.torque_controller = TorqueControlType::voltage; 
...
motor.linkCustomMotionControl(custom_motion_control);
...
}

Make sure to tune your angle PID well though.

Basically the current going through the driver will be:

current = voltage/resistance so at 10V of voltage limit you’d be putting 10/0.1 = 100Amps through the motor. Which is not possible neither for the motor or the driver of the power-supply probably.

What you should aim for is around 1-2 Amps. So try setting your voltage_limit to 0.3-0.5Volts for the open-loop tests. Or, use the estimated-current mode if you update to v2.4.0.

Also make sure to add motor.loopFOC to your loop function. That might be the reason why the motor is not turning also. If you have v2.4.0 version of the library.

As for me, i burnt 2 these boards when i tried to reach more then 4A

• Motor: 42BLS40-24-01 from StepperOnline, 24V 3-phase BLDC with 3 channel hall sensor, has a 1.8A rated current

• Driver: MKS Dual FOC v3.2

• Power Supply: 2 12V LIPO batteries wired in series

Here is the code for the open loop control:

#include <SimpleFOC.h>

BLDCMotor motor = BLDCMotor(4);

BLDCDriver3PWM driver = BLDCDriver3PWM(26, 25, 33, 27);

float target_velocity = 5.0; 

Commander command = Commander(Serial);
void doTarget(char* cmd) { command.scalar(&target_velocity, cmd); }

void setup() {
  Serial.begin(115200);

  driver.voltage_power_supply = 24;
  driver.init();
  motor.linkDriver(&driver);

  motor.controller = MotionControlType::velocity_openloop;

  motor.voltage_limit = 10.0;
  motor.velocity_limit = 100.0; 
  
  // Init motor
  motor.init();

  command.add('T', doTarget, "target velocity");

  Serial.println("Motor ready. Target velocity: 5 rad/s");
  _delay(1000);
}

void loop() {
  motor.move(target_velocity);
  
  command.run();
}

Thank you in advance for all the help!

We’re currently in a design phase, and as a couple of newbies, we’ve tried to make way of all the information available online, and stumbled upon SimpleFOC.

Our current design considerations are:

RP2350 for MCU

DRV8323 or similar for gate-drivers

some low RDS(on) MOSFETs - not decided on part yet

Propdrive 28-26s 1100 KV motors BLDC motors.

I’m wondering whether simpleFOC is applicable to this project, and if you have any advice getting started with 3-phase motors and motor control?

Thanks in advance

In my pursuit of similarly smooth motion, I have found limiting the inertial mismatch to be critical to smooth motion

I want to run SimpleFOC on the B-G431B-ESC1 with the following requirements:

• Encoder: AS5047P via SPI.

• Telemetry: Real-time (position, velocity or torque) setpoints and telemetry over CAN

• Control: High bandwidth current/torque control loops using simpleFOC

Is this even possible and if so what is the most effective pinout to use both SPI and CAN bus functionality? If this is not possible what is the next best option to achieve my requirements?

Thanks in advance!

Could I get a bit of explanation what is going on with this sensor calibration and why exactly could this improve motion control? I didn’t find where this topic is covered by documentation.

Did you try calibrated sensor from the drivers folder. It can be that at such a low speed the magnet misalignment is causing the oscillations.

Use exclusively voltage control from now on, if the current is noisy that’s gonna influence the results a lot.

Furthermore on the current thing, my device have very poor chances of actually performing current sense calibration succesfully. It succeds maybe half of tries, other times it tells me that some phases are inverted or missing (despite I don’t actually change anything physically), and around 1 in 5 attempt ends with ‘current too low’ (motor didn’t even move) and initFOC fails, the only way to restore this situation is to power cycle the microcontroller (attempts at reruning motor initFOC function through commander instafails every time). This is however not needed right now, as I suspect I might not need precise torque control yet (or at all).

The more I try settings, the more convoluted and unexpected behavior emerges from this contraption. From time to time, when I get overwhelmed, I nuke everything from the orbit and load a fresh sample code. Now I got this: with motion::velocity and torque::voltage, my motor never gets to the setpoint (velocity is measured on my phone at around 30rpm instead of 33). However, when I downsampled motion by 10, it behaves OK (by that I mean, it floats around setpoint by ~2,5%). The same effect I got when I inserted some Serial.println, that was spamming some variable in the loop() (which, as I measured it with commander (MTT), resulted in around 250us of motion loop time - instead of 58us while containing no println or downsample). I am really curious if these numbers even make any sense, and if so, what can be a cause to such behavior?

Last thing I encountered (it’s a lot, I know) when trying to test things from the ground up; I cannot perform pole pair counting sample. For some reason, in the while loop, where motor should go in small steps in angle_openloop mode, it never even budges while the setpoint angle increases, resulting in 0 angle difference and inf PP error. I do have some mismatch in sensor direction, as I have to set negative velocity to get clockwise (or turntable-wise) direction, it might be part of reason why this doesn’t work, but I have no idea where to change that in software (if possible; I could maybe turn sensor board around, but I don’t know whether this affects it. I tried to turn a magnet around, but it seemingly didn’t make a difference).

@Rosewill2, I did perform a fair bit of experimenting with all PID variables. Turning LPF_velocity.Tf a bit up resulted in damping smallest oscillations (I could even call them ‘audible whine’), but too much resulted in unstable motion. I don’t think this setting could help with my oscillations, which have period of roughly 1Hz.

my most current code

• voltage (the only one possible till v2.4.0)
• estimated current
• foc current
• dc current

And loopFOC is the one doing the torque control.

Time to see what the routing is like in KiCad…..

// velocity low pass filtering

// default 5ms - try different values to see what is the best.

// the lower the less filtered

motor.LPF_velocity.Tf = 0.01f;

I know this update is long overdue, but SimpleFOCGenerator is finally up to date with the latest release of the SimpleFOC library.

The update includes: hybridstepper, new motion controllers, stepper current sensing, and lots more.

The update involved substantial internal changes, so there will be some bugs. Please use the built-in reporting feature if you encounter any issues.

Thanks for your patience.

Stijn

We have recently published a new release 2.4.0 with a lot of nice new features.

And we have also recenlty asked for your help in identifying the next important milestones for SimpleFOC.

One of the important things was the need for a better GUI tool, SimpleFOCStudio is starting to be a bit old and is hard to install sometimes.
Anothe of our apps the SimpleFOC Webcontroller has much potential for better user experience but has so far been equally as bad. Pretty bad UI and not very usable.

Due to its potential I’ve spent some time on the webcontroller and made it more robust, and up to date with the most recent library version. And I’m glad to say that it is actually pretty good.
I’d be happy to spend a bit more time on it if more people start using it. We can push it much further than its current state.

Basically the main features are:

• New simpler UI
• More parameters exposed
• Better and more robust monitoring (should not break if too much incoming data)
• Up to date with 2.4.0 (motion and torque control settings)
• Added motor parameters section
• Added a simple step function signal generator (For tuning control loops)
• Advanced features
  • Can launch automatic motor characterisation motor.characteriseMotor()
  • Can launch Current PI aut-otuning: motor.tuneCurrentController()
  • Can call the sensor re-alignment in runtime: motor.initFOC()
• I’ve also added INFO boxes pointing to the relevant docs and briefly explaining the parameters

So yeah let me know what you think and we can go further with this if there is enough interest!

The drv8316 is really nice and it makes perfect sense to use it for such project.
Microspora is a very good starting point. I love that board
We have continued working on it a bit more after the initial release from @rambros.
Its now a 4 layer board and has a lot of JST connectors for easier use.

Here is the easyeda link: MicroSpora - SimpleFOC - Platform for creating and sharing projects - OSHWLab

One thing to consider with microspora is that its using the SPI version of the DRV8316R, in most cases you dont necessarily need all this DRV8316 configuration to be done on startup and the configuration stays always the same. Also for low power motors there is no real big point in using 6pwm. 2x 6pwm + 2x SPI will use a lot of pins and you might not have enough if you plan using the stm32g4 chip.

I’d suggest using the DRV8316T where you can do all the configuration in hardware with no SPI connection at all. There are some choices to be made but it can reduce the complexity of the board by a lot.

Here are a couple of project examples:

• QtFOC - easyeda
• SimpleFOCShiled v4 - easyeda
• SimpleFOC mini v2 - easyeda

They all use the DRV8316T and QtFOC also uses onboard LDO.

Good luck!

That’s a very nice project.
The current sensing is very important when it comes to high speed applications and robotics like torque/velocity/position simultaneous control.

When it come to the appliancations like yours, where you need precise low speed operation, voltage mode might be the better option. Or even the estimated current mode if you wish to have to control the current.

The issue with current sensing is that if often adds in to the noise and complexity of the control loop. If you use voltage control, you’ll have only one sent of PID parameters for the velocity control (only the velocity PID + low pass filter).

Another thing that you can tey is increase the time between velocity calculations:

sensor.min_elapsed_time=0.001 // the default is 0.0001s;

Another way of implementing you application might be to use position control instead of velocity control. (I’d still use voltage mode). And update the motor’s target with the target velocity. This has produced some very smooth results for me in the past.

Hello fellow makers, I’d like to ask you for some directions regarding my somewhat unstable (yet repeating) chart of motor rpm. On picture, you can clearly see two periods of registered rotations, which are supposed to be around 33 and 1/3 rpm, but instead I get a floaty pattern, which can be also faintly heard in high pitch whisper coming from the motor.

I was tasked to create a replacement engine for a turntable (gramophone). My initial thought was to get a gimbal motor (as I need smoothness above all in driving turntable and gimbals are know for their smooth movement) and I was really pumped up to find a simpleFOC library, that I can simply load into arduino and bam work done. Sadly, even if programming procedure was easy enough, I cannot get a smooth motion.

I am using: GM5208-24 blcd gimbal motor, simpleFOCShield v3.2, AS5048 magnetic encoder and ESP32 Dev Module (which I program in Arduino IDE).

I expect the tiny fluctuations visible on the chart to be cogging torque ripple (which I for now have not enough skill to tackle), but the bigger oscilations clearly stems from some motion control problem and I was hoping for either some directions, what could I investigate to get rid of them or a definitive info that it is somehow an intristic feature of my setup and therefore not solvable without changing some parts of it.

I did a fair bit of PI(D) tuning/tinkering (Q current/D current/velocity), but I could not find the setting that would get rid of these slow oscillations.

My code: gramophonEngine - Pastebin.com