BLDC board for RC car?

[p-rott]

@Valentine its a cheap chinese clone (light blue aluminium), couldn’t get anything else quickly. I already checked the wiring, and some versions seem to switch SWCLK and SWDIO, so i tried both configurations.

@runger i haven’t updated the FW yet, as i was wary of bricking it. Will try though.

Oh okay, that makes sense. I tried powering it over the STLink as well as externally, no difference though.

I can only check the Option bytes once i’m connected, so it’s just throwing the same issue again.

Just for clarity, i’m using the supplied STEVAL-UKI001V1 connector board, and attaching the SWD connection to the 20pin header on there.

I think i got my STM into bootloader mode again, since the LED was on constantly, but had no success with either DFU or SWD. It’s really tricky to get the correct pin and also reset at the same time.

[Valentine]

@p-rott

cheap chinese clone (light blue aluminium),

Right, one of those USB-stick ones. I’ve got three and none of them was able to work with the Cube. My strong suspicion is the ST changed the Cube programmer to somehow check for genuine parts and rejects the clones.

I’m using the V3 programmer, or for quick work, a break-off of an old Nucleo board when I’m afraid I might burn it with my crazy design ideas. If you have a Nucleo board, just use that programmer.

The strange thing is that the genuine ST programmer has no problem working with all ST cloned chips, so at least that’s a good news. They don’t check for “genuine STM MCU” somehow. Any decent Chinese STM knock-off (like the GD ones) would program fine.

Cheers,
Valentine

[p-rott]

Thanks for your input. I’m happy to report, i got it to connect! Can’t really say what the issue was, probably user error, you know the drill…
Well, nice. Has been a few frustrating hours. I can flash binaries via STM32Cube, so thats nice, but i’ll look into how to enable DFU without this stupid BOOT0 game, as that would be quite nice.
But yeah, time to attach some motors and get cracking, haha.

I’m sure i’ll run into more issues down the line, but i wouldn’t have come this far without the help of you guys. So thank you all very much, especially @runger.
I’m seriously impressed by the support of this community, and very thankful for it.

[Valentine]

@p-rott

I’m happy to report, i got it to connect!

That’s good. If you got the time please post a few pics, I’m curious. I could use the Chinese ones when I’m afraid to damage my genuine parts.

Cheers,
Valentine

[p-rott]

Sure, will do. It’s looking quite messy in here, since i’m working from home, so i’m hacking everything together. For a while, my DC power supply has been 4x AA batteries jammed in a cup, since i didn’t have my lab supply.
One thing to note for the chinese STLinks, slide the cover off and compare the inscription with the port markings. There are supposed to be some with differences between labeling and actual port function.

[p-rott]

Also, one thing that really tripped me up: the 20pin header in the documentation for the STEVAL-UKI001V1 doesn’t show the notch and instead only the position J1 (top left, pin VDD). Turns out, J1 is printed in the bottom right corner on the board, so if you’re just going by that, you’ll get the pins completely wrong.

[p-rott]

[p-rott]

Heya, it’s me again. Since last time i connected both motors, both rotary encoders and got I2C to my Raspberry Pi working as well. So now, i’m working through the FOC docs, and ran into one question. It seems like my GMBL board does single shunt current sensing, but the SimpleFOC CurrentSensing requires at least two discrete phases. Does this mean that i’m unable to realize current sensing with SimpleFOC (and am therefore limited to Closed-loop control - torque using voltage)?

Also, the user manual states “6 - 8.4V voltage range (2LiPo batteries), which you can increase to 11V …”. [Page 1, UM2460] Does this mean that i’m fine with applying 11V straight to the battery terminal? It’s only mentioned once in the entire document, so i’m a bit unsure and don’t want to fry it :>

[runger]

I wouldn’t set it to 11 , even though I love Spinal Tap.

The STSPIN233 drivers support 1.8-10V input. So I wouldn’t go beyond 10V.

Regarding your question on the current sensing, unfortunately they only provide 1 shunt per driver, so this is single-shunt low side sensing. It is currently not supported by SimpleFOC, it is quite complex to implement compared to 3-shunt sensing.
We will support 3-shunt low-side sensing on a bunch of MCU architectures with the next release of SimpleFOC, but currently have no plans for implementing 1-shunt sensing.

So unfortunately you can’t do the current sensing with this board at the moment.
I also have to say though that at these voltage and power levels, the difference between torque-voltage and torque-current control should not be too big. Depends a bit on the motor you’re using, but for low KV, high ohm (Gimbal type) motors current control won’t be a requirement.

[p-rott]

Thats actually incredibly funny! I guess the 11V comes from the STSPIN233 docs, “absolute maximum rating” haha. So yeah, no dice. I’ve got torque control working fine, the car is driving. Next issue is the servo for steering, which is a whole new bag of issues, but i’ll figure it out. Definitely can’t use the third motor port like planned though.

In my downtime, i started playing around with the BGC3 clone again, and found your comment on it here: BGC Board I2C Trouble - #4 by runger

One small question on it, how did you “close the loop”? I’m guessing you used external encoders via I2C? Do you by any chance know if the board supports current sensing? I’m kind of stuck with the sensorless bldcs and this stupid board for a bit, so i’ll try to make the best of it, but it’s near useless in open loop. I’m asking because it came as a Gimbal kit with only those two motors (2208 80KV) and an external IMU, which seems to be enough to drive them properly as gimbal motors?

[runger]

@p-rott

One small question on it, how did you “close the loop”? I’m guessing you used external encoders via I2C?

Yup. I used 2 I2C magnetic encoders of type AMS AS5048B (note the ‘B’ at the end. the more common ‘A’ version is SPI).
Spoiler alert: it isn’t really worth it. The ATMega 328 in combination with the I2C sensors, even with some hacks to reduce the number of I2C calls, was not able to reach much more than 700Hz loop iteration speed. That is kind of ok for driving gimbal motors slowly, but really has no overhead at all for additional communications (like with the IMU), calculations or driving the motors at speed.

I’m guessing that’s why maker OllieW then designed the Storm32 boards - to support 3 axes, and have enough performance.

Although I think neither the BGC nor the Storm32 boards with their native firmware were doing FOC - they were probably using sinusoidal or trapezoidal open loop commutation of the motor, and closed-loop only for the motion control loop using the IMU.

So that would be like using SimpleFOC open-loop mode, but using a closed-loop control algorithm to set the target values to SimpleFOC’s move() function.

I don’t really know because I only bought the boards, never a finished gimbal, but my impression was that the BGC boards never worked too well, while the Storm32 boards produced working 3-axis gimbals.

[p-rott]

Alright, thats what i thought. I’ll see if i find any use for it. Thanks!
Just out of curiosity and because i want to learn more about communication, how would I2C compare to SPI (and PWM in the case of the AS5048) in terms of overhead?

[runger]

Hey,

So SPI is a very good option. Depending on whether the sensor is on-pcb or via a cable, length of cable, shields, etc speeds of 2MHz to 20MHz are quire realistic, though most sensors seem to support no more than 10MHz.
That’s the SPI clock speed. SPI is a synchronous protocol, so you receive something as soon as you send, and depending on the sensor model this can be directly the angle value you need, while other sensors make you do 2x 16bit reads to get a fresh value. It varies.
Either way, it is quite realistic to get loop speeds of 3kHz or more while reading from SPI sensors.

PWM sensors very typically have 1kHz PWM frequency - so that means you can’t get more than 1kHz loop speed, it takes 1ms to read the sensor. Basically that is too long to interrupt the commutation, and so unless you used MCU support (the timer/counter hardware) to do it asynchronously, PWM is a very bad option.

Some sensors support PWM variants like short code, which can be a bit faster, but we have no support for this in SimpleFOC.

SSI is basically like unidirectional SPI, and can be very fast.

I2C is much slower. While most MCU/Sensor combos can support 400kHz operation (Fast Mode) this is still not very fast, and I2C’s bi-directional half-duplex nature (SDA used in both directions for data) means any communication involves a lot of latency: first you send a read command, then the sensor sends back some data, one after the other, with pauses in between to respect protocol timings.

So you won’t get much beyond 1kHz main loop speed when using I2C, and that’s really a bit slow.

The advantage of I2C is that it supports longer cables due to its slower speeds, and its easier to wire up. For many less “real-time sensitive” communication tasks it is an excellent choice.

Another one to consider is quadrature encoder ABI type interfaces. Many magnetic sensors (like the AS5047 and AS5147 models from AMS, but also the MA732 and others from Monolithic) support ABI / ABZ type interfaces, and there are a wide variety of other position sensor types with ABI interfaces.
SimpleFOC supports these with an interrupt-based implementation, which is limited by MCU speed / interrupt processing speed. But for STM32 MCUs we also have a hardware driver in our Drivers Repository. Many MCU types have hardware support for ABI interfaces.
This way of attaching the sensor combines the best of everything: instant updates (no comms latency), high precision and no MCU overhead.