Hello everyone!
This is my first post on the VESC project forums. I am not sure if this is the right forum to ask this question in so, if this topic would be more suitable for another forum here please do let me know!
To give a bit of context, I am currently working on a 4-wheeled robot. The wheels are mecanum wheels. Each of the wheels is driven by a "TRAMPA 160 KV 637 Out-Runner Motor", each motor in turn being controlled by a VESC MK 4 with the latest firmware (I have used both the latest stable FW release and the test versions being currently released and the described behavior was always the same). The mecanum wheels have a diameter of 254 mm and each motor-wheel pair has a reduction rate of 5,846.
One of the features I am currently trying to implement for this robot is standing still, with all the wheels locked at a fixed position, both on even ground and on a slope. While I am aware there are better and simpler ways of achieving this, currently I am trying to do this just by sending certain commands from the VESCs to the motors and making use just of the motors and their reduction rate. These are the limitations I have to work with currently and the target of this thread is not to research better options of doing this.
Initially I managed to somewhat achieve that desired behavior by sending constant handbraking current to the motors from the VESCs but this approach had its obvious drawbacks (figuring out what would be the necessary handbraking current to stop under various scenarios was not exactly straightforward and just sending a constant value always wasn't doing the trick in every situation). So, I decided to try to approach this by instead sending position control commands when wanting to stand still. I firstly tried doing the position control just with the Hall Sensors which the motors have but, as you might have already figured their resolution was really poor and on top of that, achieving the desired behavior with just Hall Sensors required a lot of tuning for the gains of the position controller. So as a next solution for this I got some AS5047 encoders and made some mounts for them and started playing around with those. The position control with those is amazingly nice once they are properly mounted and configured but there is still one issue that bothers me a lot and I can't seem to figure why it happens.
What happens is that, for some of the encoders, after the whole detection process (which by the way finishes without any issues or faults thrown by the VESC tool), they are detected to be inverted although they clearly are not. I have encoders that are working correctly and once their parameters are detected, they can track the motor position flawlessly and with an error of around 0.3 degrees, but also when I am sending a position control command from the vesc tool, then the position jumps to the expected one. With the ones that have the weird behavior, they are detected as inverted, but when I just turn the motor forwards the encoder is also counting forwards, so clearly it is not inverted. Still, being detected as inverted, almost everything seems to be working fine, until I send a position command. Then, when I send the command (whatever that might be), the motor jumps to a position that is 360-desired_position. So if I send a position control command of let's say 100 degrees, the motor jumps to 260 instead the expected 100. If I try to manually set the "Encoder Inverted" parameter to be "False" for those encoders then nothing works anymore, I can't even drive the motor at all after doing that change. What is interesting is if I leave everything as it is, then everything else works nicely...i can drive the motors and they work smoothly, the only issues is that the position control commands are flipped. And this is a big issue for me as when I am driving the robot as a whole and then I engage the simultaneous position control for all of the motors to keep a specific locked position, the ones that have the encoders with this issue jump to that weird position and this generates a weird shaking from the robot.
This has been puzzling me for the last couple of days and I would greatly appreciate if someone would be kind enough to share some opinions or advice regarding this issue. If any more info regarding the problem and how it is happening is needed, do not hesitate to ask me, I will do my best to try and describe it better.
Sorry for the rather long post, I do hope some people will read through it all! :)
Best, George
On the jumping ones the chip is probably not 100% centered. Another problem you might face is that the ESCs might start to work against each other. Small inaccuracies can make one VESC controller make the robot move forward a bit and another one will start to work against that wish. That will make the other even try harder to reach its position etc... That can cause some weird behavior. If you experience such a thing, you know why....
The inverted flag on the encoder depends on the direction the motor will turn when the phases are advanced in a given direction compared to how the encoder advances. If the motors turn in the wrong direction you can either swap two of the cables or select invert motor direction from the general page in vesc tool. Changing the detected inverted flag of the encoder will not work. If you swap two of the cables you have to run the encoder detection again.
Hello Ben and thanks for the quick reply!
I understand what you said about how the inverted-ness of the encoder is detected but I do not understand why I can't just change the inverted flag for the encoder. I tried what you suggested, inverting the motor direction from the general page led to the expected behavior from the encoder, but this does not help me at all as the motor was already spinning in the correct direction after the "Setup Motor FOC" wizard.
How everything happens for me is: I run the "Setup Motor FOC" wizard and everything is in order. At the end of the wizard I check if the motor spins in the correct direction for my robot and if it doesn't I then set the inverted flag accordingly. For the VESC/encoder I am currently doing this for, the inverted flag for the motor is correctly placed straight after the end of the "Setup Motor FOC" wizard. Then when I go and check the detected encoder settings, I see the encoder is detected as inverted. Without changing anything i switch to the real time data tab, go to rotor position tab and enable the realtime tracking from the encoder data. There, when I either spin the motor by hand or by just driving it with the keyboard, the encoder behaves as expected, it counts incrementally when I spin the motor in the detected and correct forward direct, and count decreasingly when I spin in the other direction. This happens although the encoder is detected as inverted. Then, when I proceed to send a position control command from the VESC tool, all the commands end up being flipped by 360 degrees, as I stated in my initial post.. Inverting after this the motor direction leads to the encoder to handle "correctly" the position commands but this is of no use to me, as inverting the motor then means it would be spinning in the wrong direction for my robot to just drive normally... Can you tell me maybe why this happens?
One other very weird thing is that, all the encoders for me are detected as inverted. No matter if straight after the setup motor foc wizard the encoder counts forwards or backwards, always they are detected as inverted...and this just seems odd... I am using the latest beta testing build of the VESC tool, maybe this info helps somehow.
Sorry for the long reply and thank you for your help! Looking forward to your reply!
Best, George
Later edit: in addition to the description of my issue above I have to say that I am configuring each of the VESC + encoder pairs separately and not all over CAN. I am doing this because at one point I was configuring them all at the same time and ran into some issues with the encoders, can this behavior appear because I am not configuring everything over CAN all at once?
Later edit 2: I didn't yet try to switch 2 of the motor connection cables to the VESC. Can you tell me which 2 cables are safe to switch around? A with B or A with C or..
Later edit 3: After switching around 2 of the motor connector cables and re-running the configuration, the encoder works as expected! Thanks again for the help!
Switching any 2 of the 3 cables always inverts the motor direction.
The settings under FOC->Encoder are user to translate the encoder position and direction to the electrical motor position and direction. This is needed for the commutation to work at low speed where the observer doesn't track the motor well. If you change the encoder settings from the detected values the motor will not run properly. The encoder and position control settings you can change to match your application are under PID controllers.
I had a look, and did notice that the PID control direction will be inverted compared to the other directions when the encoder is inverted. That is fixed in the beta build that I uploaded just now. I also fixed a problem that would cause the motor to glitch when enabling position control the first time, even when the set position is the same as the current position.
Thanks for your great work.
my hardware is based on 75/300.
how can I control speed and acceleration in position mode?
and can I replace the MT6816 encoder with AS5047 ? directly with encoder port or hardware SPI?