Hello everyone !
I’m quite new to the simpleFOC library, i want a cheap way to control the torque of gimbal motors, from the github example I found this code :
From what I understand the code need an encoder built in the motor ? Is it mandatory to have that encoder even though I have inline current sensing ?
There are also voltage control one step above in the torque control github repo but they do not seem to use inline current sensing
Thank you for your answers !
Have a nice day
Yes I’m afraid right now you need some kind of angular position sensor, unless you want to go completely open loop, which can work for some things.
Yes, you need the encoder. Torque is proportional to q axis current, but current sense gives you the combined q and d axis. No way to sort them out without knowing the rotor angle.
Thank you ! When you say rotor angle do you imply relative to the stator ? If so it has to be built in the motor right ? for exemple an outside magnetic position sensor would not work
An outside magnetic position sensor can certainly work! Many people use them. The magnet for the sensor has to be attached to the rotor, while the sensor remains stationary. In this way the sensor measures the absolute rotor position via the attached magnet.
Oh ok ! since the github example uses voltage_control for torque control using a magnetic position sensor and the “true” current control (using inline current sensing) is used with an encoder I thought that an “inside” encoder was mandatory, but if i can use in line current sensing with magnetic position sensor for torque_control that’s a great news for me !
Thanks again for your answers !
maybe someday there will be an implementation of a sensorless observer 
For low speed it would probably require some HFI, though…
I think that would be a really good idea, I posted a thread a little while ago dedicated to sensorless drive.
I think sensorless drive can get higher efficiency because you don’t have sensor error to mess with the motor timing.
Also it could be completely plug and play, and you could have a servo motor with no sensor, which would be really cool.
You are packing the brains into the software instead of spending all this money on sensors. The sensor itsself isn’t that expensive, but the work to make the magnet holder and assemble everything, and mounting brackets, then calibrate the sensor and so on and deal with any stray magnetic fields - or align the rotational axis of the sensor if it’s an encoder - that stuff all adds to the de facto cost.
Also for my application, waterproof is good. I have to waterproof the sensor and it’ smore parts to break and so on. Sensorless is the bees knees, it’s the next stage of evolution imo, but the details require significant understanding.
I am hopeful we can borrow a bunch from VESC, they may even help us with a high level system design. I wish they had a pseudocode level description of their code and why it is the way it is. IMO such information is an important part of the source code. We don’t need to know only what works, we also want to know wha you tried and didn’t work, and some of the dynamics and stuff, in order to continue the development process efficiently. Maybe we can talk to the VESC people and they could help us come up with a foundation of documentation that enables the next developer to get in and go. I think the reality is that almost all of us could use that, even though there are many people here that know a lot more than I do and a very respectable amount.
Hey,
I‘m certain we’ll eventually get to some sensorless code, there’s a lot of people interested in that!
But I also want to make clear that we’re not trying to compete with or copy VESC, nor have we any intention of copying any of their code…
VESC is a super cool project, and we can learn from it, but Mr Vedder set out with a different goal: specific hardware and specific software to implement an ESC that you can buy and immediately use.
That’s not the goal of SimpleFOC. SimpleFOC has the goal of making field oriented control, well, simple. And it’s hardware-agnostic, so you can run it on any Arduino, with all kinds of drivers and various motors. It’s also designed with lower cost to entry.
We’re more about education and DIY, we’re not that “producty”.
Because of this, many people find it a good match for their projects, and the variety of things people do with SimpleFOC never fails to amaze me
But for a “turn-key” solution, VESC, ODrive or Moteus are more appropriate choices… but of course their highly optimized, feature-rich codebases are probably harder to understand and adapt if their existing functionality doesn’t meet your needs…
I don’t think adding sensorless would be terribly difficult. It only works in velocity mode, but there are plenty of good applications for that.
One issue is that most boards designed for SimpleFOC don’t have the necessary resistors connected to ADC to measure back EMF. But B-G431B-ESC1 does, and we could add support for running on regular drone ESC hardware too.
I think the general approach would be to make a new Sensor subclass that monitors the ADC signals for zero crossing and steps the angle 60 electrical degrees at a time. Then we could potentially run it through SmoothingSensor to get smoother motion.
Ideally we should keep the specialized startup code confined to the SensorlessSensor so it doesn’t clutter BLDCMotor for everyone else. Maybe just randomly changing the reported angle every couple hundred milliseconds would do it. High-frequency injection would almost certainly need to be done in BLDCMotor.
That works for sensorless six step, but I found sensorless FOC is much harder. You need some kind of state observer usually, some people have written peer reviewed articles on relatively sophisticated approaches. Unfortunately you can’t just look for zero crossings with FOC I think. However six step would be a good start and works fine for most things most of the time, I think it would even work fine for me, I tried trapezoidal waveforms and it wasn’t any noisier.