Hi @Owen_Williams, many thanks for working on the HALL commutation. I’m also interested in getting the hoverboard motors work with simpleFOC and Arduino Mega. I just received my simpleFOC shields and pulled the dev branch to try the hall examples.
After configuring the solder pads on the board based on all the info Antun provides (red are the selected/set):
and making the respective adjustments to your velocity_control example (15 pp hub motor). I did not make any changes to the default parameters file.
// motor instance
BLDCMotor motor = BLDCMotor(9, 10, 6, 15, 8);
// hall sensor instance
HallSensor sensor = HallSensor(2, 3, 4, 15);
I’m getting kicking movements but no rotations and the driver heats up instantly (can’t touch it) so I turn off the supply and can’t do many tests.
When using the torque_control example it does change the torque but holds its position. There is also a high frequency noise.
So, before I get too much into debugging I wanted to check with you if I’m missing something obvious. Maybe this motor needs specific settings in some way?
This is the response I get from the monitor:
MOT: Monitor enabled!
MOT: Init pins.
MOT: PWM config.
MOT: Enable.
MOT: Align sensor.
MOT: natural_direction==CCW
MOT: Absolute zero align.
MOT: Not available!
MOT: Motor ready.
Motor ready.
Set the target velocity using serial terminal:
@Antun_Skuric If there is an easy way to limit the max current at the current loop please let me know, before I melt anything
My advice for big motors like this is to initial to ignore feedback loop. Forget about the hall sensor and get it moving in open loop.
The code is super simple, @Antun_Skuric posted an example here: https://community.simplefoc.com/t/cant-get-good-data-from-sensor-cant-turn-the-motor/57/22
He says that the shield shouldn’t be used with motors under 10 ohms, but that is a simplification. If you set your target_voltage to 1 to 2v with your hoverboard motor (~1 ohms). Then run in open loop at about 60 rpm it’ll be well under 1amp. So the shield is fine for testing just don’t push it to hard.
Once you get a feel for open loop, take a note of the target voltage that you could run the motor at whilst keeping the l6234 chip on shield fairly cool. Use this voltage to set some safety limits!
motor.voltage_sensor_align=xx;
motor.PI_s.voltage_limit=xx;
motor.move(xx); //when in voltage mode
xx above should be higher than that safe voltage you found in open loop testing.
Some notes on what 1) 2) 3) mean…
voltage_sensor_align is used during setup when you call motor.initFOC(). Essentially it’s the voltage used in the calibration test (where electrical angle aligns to sensor angle).
PI_s.voltage_limit is used if you are using velocity or angle control mode
Motor.move(xx), whilst xx can mean voltage, velocity or angle (depending on control mode) I’m referring to voltage mode.
Keep that voltage low!
I have a bench power supply set to 12v and limited to 1A. So it is not possibly for me to damage the shield. If you are using a battery or non current limiting psu then be careful.
I think voltage control mode is technically still open loop, but you typically configure a sensor, use this mode to initially monitor whether you are getting sensible values (radians) out of the hall sensor. This is the easiest mode to try next.
Then try Velocity mode, this requires a bit of tuning of P, I anf tf. Finally try angle mode which requires tuning if a second P constant (there are two PID loops in angle mode).
That is the number of pole pairs. If you count the magnets and divide by 2 you’ll get it.
Unfortunately there isn’t a find_pole_pairs example sketch for hall sensors.
It would be easy to write. The hall will go through 6 commutations (state changes) per electrical revolution. So as my motor has 15pp (15 electrical revolutions per shaft revolution) i have 90 commutations per shaft revolution. Each commutation happens every 4 degrees.
Hey @Francesc_Riera_Vidal, maybe just one thing @Owen_Williams did not say is that the number of pole pairs you provide to the HallSensor’s 4th argument is the same as the one you provide to the BLDCMotor’s 4th argument.
Are you getting sensible angles/velocities without motor code? There is a hall sensor example in repo.
It is difficult finding the zero offset angle/natural direction. initFOC() tries to work these out (calibration steps) but i don’t think it works very well. I’ve been meaning to look into it more as numerous people have struggled with similar problems.
Hi François @Francois_DESLANDES,
You can try “motor.disable()” when the target is at 0.
@Owen_Williams, you are right, there is a real issue with the halls, as soon as I get the time I will do more tries. Can you tell me where are your halls position on your motor to understand what can happen or the reference of your motor that you use, please ?
Yes, I tried
even with 0 speed, same result. When I check PWM at the ESP32 output, bridges are always receiving orders. difficult to explain. I’ll try to post pictures later.
Hey @Francois_DESLANDES,
This is normal behavior. We have discussed it few time over the course of several conversations now. I’m not sure what we’re the topics any more.
The idea is that since we are using the three half bridges we vented the voltage around the half of the voltage of the power supply. So the duty cycle 0.5 becomes 0. You should not have any current for duty cycle 0.5 though. If all the phases have the same duty cycle 0.5 the current should theoretically be 0.
Now this depends on the hardware you are using. But this should be the case for all the simplefoc supported MCUs.
You can visualize the waveforms of the voltage by outputting the motor.Ua, motor.Ub and motor.Uc variable using serial.
There is a way to pull the 0 to ground. You can do this only in the space vector modulation. And you can do it by using the centered variable in the setPhaseVoltage function. Set it to 0 and you should have the behavior you are searching for.
Last thing I wanted to say is that the hall sensors have the least tested support so far in the library and any help in terms of improving it is highly appreciated.
It’s hard for us to cover all the topics we would like to
Hello, Thank you for SimpleFOC!
I have been heavily involved with another open source project called OpenHD (primarily as a tester as i’m really not good at programming)…
But, I have a lot of interest in a micro 3-axis gimbal for fpv drone usage based on the Storm32 platform (which I’ve seen some other threads on here about).
I have picked up some stock DJI Mavic style gimbals and looked into the inner-workings and, learned that most of the models utilize LINEAR HALL sensors with the designs. I’ve attached some pictures below… There are one TWO- TI DRV5053 LINEAR HALLS ON EACH AXIS… (I assume because the gimbals do not move more than 45° on each axis roughly)??
Here is a YouTube video showing how they work…
My thinking was that with a company as big as dji, there must be a reason they’re utilizing this kind of Hall sensor on the really small brushless motors?
My primary objective is to have the ability to drive the three axis nice small stock gimbals as a standalone drone gimbal or laser pointer… But, all open source solutions appear to opt for the on access magnetic sensors…
Going out on a limb here, your assumption about the limited angle response appears to be correct. With two ratiometric hall sensors in this configuration you can control the motor angle without the need for expensive angle sensors and protocols, just measure the voltage and get immediate feedback, it’s cheap, it’s simple, and it’s fast as long as you don’t exceed that small angle. It’s a simple, cheap solution both hardware and software, probably takes like 20-30 lines of code and a couple dollars worth of sensors.
Hey, Thank you for the reply! It’s funny, earlier today was the first time I came across the term ratiometric hall term… It actually makes perfect sense because, as long as there’s a hard stop on the axis, somehow software could just compare the difference between the bipolar linear halls (as I understand it). I know a guy in China on the open HD group who hacked the gimbal from a mavic mini to run with just the Monolithic MP6536 motor drivers on each axis…
Attached I made a YouTube video compiling some other pictures and, the video he shared last year sometime…
I’m not sure how familiar you are with drones and gimbals but, one of the problems with open loop storm32’s is something called “horizon drift”… Where the IMU starts drifting to an angle compared to the horizon…
I have mapped out all the pins on the multiple DJI Mavic 1 Pro, Mavic Mini & Mavic 2 Pro also I believe… I intend to have some custom flex cables made to easily break out the pins and, integrate a MP6050 IMU by the camera side connected to the factory micro coax camera…
If I can assemble a ready to use test platform would you or anyone have any interest in using it to write the code to utilize the integrated halls?
Hey, So overall there would be a lot of use cases for a compact small 3 axis stabilizer gimbal… Note- The pictures might not give Justice to how tiny these things really are… Each Kindle motor has a diameter of about 10mm…
My primary purpose would be to adapt the factory micro coaxial wiring connector that is routed through the gimbals to something like a Raspberry Pi MIPI CSI-2 camera which comes with the factory FFC ribbon…
Theoretically, a micro gimbal like this could fit on a tiny whoop quadcopter…
Also, I’m interested in extending the camera sensor from a GoPro… (Normally a GoPro gimbal as many times bigger than it needs to be so that it can swing the mass of the entire camera and battery vs just the sensor like we see on the DJI stock stuff…
Here are a couple examples of OEM replacement gimbal assemblies from aliexpress. as you can see, they’re cheap & abundant… You can buy an assembled 3 axis unit with low inductance premium brushless motors where each axis has integrated Hall sensors and HOLLOW MIDDLE SHAFT for routing the extremely tiny camera and sensor conductors for $25-$80 Total… The ultra compact motors with Hollow motor shaft is the primary benefit because, using the on axis magnetic sensors make it difficult to have a hollow motor shaft for routing sensor and motor wires…
This solution would open up an opportunity for compact three axis gimbals with Premium & Smooth FOC control for limitless CV, Hobbyist, Robotics and drone applications…
Does this kind of give you an idea of what I had in mind?
US $44.49 40%OFF | For DJI Mavic Air Drone Gimbal Camera Replacement Repair Part with Signal Line Flex Ribbon Cable https://a.aliexpress.com/_msSQKRl
US $25.66 19%OFF | New HD 4K Cam Gimbal Repair Part Gimbal Arm Motor with Flex Cable for DJI Mavic Pro RC Drone FPV DJI Mavic Pro Camera Lens https://a.aliexpress.com/_mNvWGRH
Also, it might be worth sharing this example how all of the DJI camera gimbals boot up…
There is this O-gs GitHub repository that has all kinds of interesting DJI firmware and hardware info that was really helpful to me just figuring out how everything works from a hardware standpoint…
Something worth mentioning is that dji normally boots into a “CALIBRATION” Process called “JOINT COARSE” & “LINEAR HALL” CALIBRATION…
***My guess is that on boot it measures the “ratiometric” offset from the midpoint of the whole sensors and, the Drone body sitting on a flat surface… I think that would be logical but I could be wrong…
*** Someone who is much smarter than me could probably look at that code and possibly find some clues…
There are one TWO- TI DRV5053 LINEAR HALLS ON EACH AXIS… (I assume because the gimbals do not move more than 45° on each axis roughly)??
I’m not sure how familiar you are with drones and gimbals but, one of the problems with open loop storm32’s is something called “horizon drift”… Where the IMU starts drifting to an angle compared to the horizon…
