Hello everyone,
I am using two VESC6 units; each communicating via UART with its own serial port to a custom microcontroller setup of mine. (two VESCs hooked up to UART 5 and 6 on my controller)
Before using this UART communication I was using PPM + CAN to send these commands. Everything worked amazing besides the fact that I need to control these motors separately. When I switched to UART, Everything works great at low speeds. As soon as I try to accelerate heavily in the slightest bit it starts cutting out every 10-100 milliseconds.
I have tried disabling and unplugging one controller and then the other from the UART port on the VESC to see if there was some sort of ground loop or if maybe it was only one controller causing issues. Problem is still there.
I have checked the VESC fault codes: nothing reported.
I am about to slow down the transmission speed of UART.... but its already way slower than I would assume the VESC can handle thanks to the tiny packet size. It sends every 100ms. I also would assume this would be an absolute; it would work or it would not like the previous motor controller I was using that used a much larger packet and a slower processor. (I am using the same sending frequency as this controller)
I made sure the set_current is not higher than 60 or -40; the values chosen by default for the VESC when being setup. I also would assume that since I have not changed these current values or any settings at all on the VESC since using PPM that this could possibly not be the issue either.
I don't know where to go from here.
Thanks for reading!
Dillon
I am still having trouble even sending only two packets per second.........
At this point I have tried everything I can on my end. It was working great over PPM + CAN, now it stalls and sputters during even mild acceleration.
I tried updating the VESC UART library thinking maybe that was the problem. Problem is still there unfortunately.
On the VESC side all input methods just call the same global functions. Very unlikely some conversion happens between receiving the UART command and calling the function.
I would rather expect things like timeouts, e.g. you send a command via UART, the motor spins and then you are not sending another command within the heartbeat-time. Hence the motor goes into an emergency stop. Just to receive the next valid command a little later.
I am sending UART commands 50 times per second and have not noticed anything.
Are the power supplies for the VESC(s) and your microcontroller board galvanically isolated? Or do they share ground potential?
This is most likely an EMC issue, TTL level serial data is not suitable for noisy environments (like the vesc), especially not when the circuit communicating with the vesc is also connected to other systems with its ground / power (that is why bluetooth works fine but other systems sharing ground / power with other systems likely don't). If you really insist on using uart you could lower the baudrate significantly and ad RC filters on the receiving ends (similar to what the PPM input has). Probably the best solution would be to switch to CAN control, that protocol and its hardware implementation is way better in recovering / resistant to a noisy enviroment.
Yes! Exactly what I was thinking. It's just sending commands so there should be no gray area. It works or it doesn't. I ended up reflashing the firmware and rerunning the motor setup wizard. "Have you tried turning it off and on again" apparently not. All working now. Thanks a bunch!
I would love to get CAN communication working and there is in fact a CAN chip in my board. I can't say I know how to go about using the libraries over CAN
I've been testing UART all day today. Not a bit of trouble. I must say that these VESC6 motor controllers are about 100 times better than the previous controllers I was using; the SBL1360. The energy density is much better. Every time I stalled out those SBL1360s they would literally shoot fire out of the mosfets. I have 10 dead SBLs and no dead VESCs. These are making a great first impression on me to say the least.
You should probably not connect both VESCs over UART to the same controller, that is likely to kill the microcontroller in the VESCs and/or your controller because of ground loops. The best way in your case is to connect your controller to one VESC over UART and connect that VESC to the other VESC over CAN-bus. You can forward commands to the other VESC over CAN-bus from the UART connection. It is surprisingly easy, all you have to do is to append COMM_FORWARD_CAN followed by the ID of the VESC you want to forward to, and that packet will be forwarded over CAN-bus.
I also connect two VESC6 to Arduino Mega through Serial1 and Serial 2. is it unstable? Which is the best way to do it?
I have been struggling to make COMM_FORWARD_CAN to work with the VESC library.
Getting the library was hard enough for me. This task may be easy for someone who has more experience in this field.
Heavy duty hardware programming (ST and such) is still a newer thing for me.
I added this to the bldc_interface.c file but it does not work:
I left the commented out commands in there to see what else I have tried.
Thanks everyone for their contribution!
Got it working, found some sample code.
Thanks!
I had this issue again, but with what seems like just one motor and only under heavy acceleration. It was very scary, and I'm glad I was going slow and wearing my motorcycle helmet lol. I have flashed the firmware to the latest version and reran the motor setup wizard as that fixed the problem last time. Considering this seems to always happen at lower speeds perhaps it is due to the switch from hall sensors to FOC. I was using .89 of the tool and whichever firmware came with that version of the tool. I will post my results of flashing latest firmware and rerunning the wizard. I don't want to try and recreate the condition because I almost fell off so it may be a while till I report back. The phase wires were a bit warm, but not hot. I switched out a dead battery pack of LG HG2's to Sony VTC6s on just one of my two controllers. They are capable of 30 amp discharge vs the HG2 20 amp discharge. Running 2P that gives the controller 60 amps continuous vs the 40 amp of the HG2's. I didn't run the motor wizard again after changing packs. Could that be the issue?
Still having the issue which seems to be fixed somewhat by changing the saturation compensation.
I can't say I quite understand the documentation. Can I go over 15% saturation compensation? From my understanding of the documentation the answer is no, and that I have a problem elsewhere. If that is the case, where should I look?
Running my motor at 10S, and its top speed is 4K RPM. I had it custom made for me to be 1000 watts continuous, 120mm inrunner, and I am pushing it at 60 amps battery limit, 120 amps motor limit. Is my motor simply being pushed too hard? What happens if I go over 15% saturation compensation?
Can you draw a connection diagram of your exact setup and describe what is happening again?
i have had luck setting the hall sensor integrator to a higher eRPM. Ideally I can get FOC working at lower RPMS for higher efficiency, correct?
CAN should have two cables only: CANH and CANL. Did you connect GND too? That is very likely to cause ground loops.
Hmmmmm.... I don't think I did, even though I drew it that way but I will check to make sure. Thanks for the input!
Ok just checked the wiring, the slave controller is only connected with CAN H and CAN L. Sorry for drawing the diagram incorrectly.
Just to recap because this thread is long:
both motors will act erratic under heavy acceleration which goes away mostly by turning motor saturation to 15%, and setting hall sensor integrator to a higher RPM. Which value should I increase more to eliminate this problem completely? It would be nice to keep FOC for a wider RPM range. These motors are about 120 mm, rather large.
If the motors act badly under hard acceleration and saturation compensation helps, it is likely that they get saturated and need the saturation compensation. If the motors have a temperature sensor, adding temperature compensation and setting the base temperature to the temperature the motor had during detection usually helps a lot.
Awesome! Thanks so much Benjamin! I turned up the sensorless erpm to 8000 erpm which helped a lot but still not perfect. Oversaturation makes the most sense. Looks like I will make the motors for a higher watt rating as these motors were designed for a different controller (roboteq) that kept burning up on me. Glad they did because these new VESC6 controllers are amazing. So glad they were the exact same dimensions. my motors currently do not have temperature sensors unfortunately but perhaps I'll glue on some for prototyping purposes. Thanks again.