I was actually using the b-g431-esc for HFI/sensorless dev work, but so long as current sensing works, it should port over. Right now I’m only using one STM32 specific thing, and I think that’s even optional/possibly a red herring. This is easily worth it’s own thread though.
On the external encoder, the most recent rev breaks out some more MCU pins, specifically ones that expose a timer for the ABZ hardware encoder feature. An i2c bus may be exposed in the same “user header”, but I’d need to look at the schematic.
I took a peek and there isn’t one available, although there does look like there is a free GPIO that I can use which would allow use of I2C1, so I think I’ll make that change and push today for whenever the next rev ends up happening.
Like Copper said, I did break out an extra hardware timer for use with an AB encoder. If you don’t need absolute positioning, you could easily use this. I would not recommend AS5600 but there are plenty of other encoders which support both I2C/SPI and ABZ simultaneous. Also, I2C is multi-drop bus, so if you wanted to use an I2C sensor and I2C to talk to this board, you could just put them on the same bus if you have an external controller (which for a robot arm, I imagine you do).
To be fair, it doesnt need to be an as5600, or even I2C. Our main need is to have an external absolute position sensor after the gearboxes. It could be anything that could be connected with a wire to the board
Depending on how you’re planning on closing that outer loop, it might make sense to read that sensor from your host/motion planner, then send torque or position commands to the motor.
Using something like the as5600 in the FOC loop will slow things down dramatically on a controller like this.
Since the motor does have absolute positioning (MT6835 on the driver board), you could use that to correlate non-absolute encoders, so even just ABZ might be fine for what you need, with a little firmware trickery.
On the steppers I have, the wires are fixed from the motor, so I just cut them about 1" and crimp on JST-XH connector. I bought a kit from amazon with crimps, connectors, and the crimp tool for about $20 and it’s worked well. There are some motors coming with detachable cables, maybe for these you can find like 1" JST-XH 1x4 jumpers but I haven’t looked.
Yes, exactly, it works pretty well. Using 16-bit ABZ hardware encoder mode, there is no noise introduced from this (you can resolve 1 LSB movement). I don’t know the real noise floor of the MT6835 (spec is 21-bit but we all know the lower bits are junk anyway) so for me this is fine, I don’t need more than 16 bits. Maybe if you are reading SPI and want full resolution, it might introduce some hysteresis or noise. I meant to characterize this but didn’t get around to it yet.
Did you check there is enough room for the Lemon Pepper board and connectors in the Arctos? I just saw the assembly video and it looks quite tight.
Does it make sense to use encoders on the motor- and the output-shafts?
PID tuning both sounds like a nightmare and can easily lead to excessive gearbox-wear and noise.
I would only have one PID on angle, using the sensor on the output shaft, output would be a speed setpoint, either for a PID using motorshaft or outputshaft sensor depending what you want.whats important is to use the sensor of the motor shaft for the actual focroutine to make sure the two magnetic fields are exactly 90degrees appart. So no need for 2 pid’s
I was under the impression that there are always default PID values at work in angle mode.
It would be interesting to know how to disable them… P = 1, I = 0, D = 0?
