Hi, sorry I took a while to answer.
There are 3 ways to keep the encoder calibrated:
- Run the encoder calibration on every startup. This is default if you don’t configure the other options.
- Use an encoder with Index output, sometimes called “phase Z”. This means you don’t run the calibration, but you still need to spin the motor to find the index. We have support for this.
- Use an absolute encoder. This means you don’t need to move at the start.
For nr 2 and 3 you can only use it if either
- your transmission ratio is a factor of your pole pairs. So because you have 28 pole pairs, you can only use this option if your transmission ratio is exactly: 1:1, 2:1, 4:1, or 7:1.
- OR you have a separate encoder on the wheel directly also: so you have some other encoder/potentiometer on the wheel, and still the large ratio to the encoder (not exact factor of 28). You need to add some logic that uses the knowlege of which “turn” the encoder is in, derived from the wheel encoder/potentiometer.
Yes you are absolutely right, the position control reference position is just 0 at where the encoder was on startup. You can use a home switch, or indeed a potentiometer like you suggest:
yes. But you need to add some code for this, as we don’t have it available yet.
The future is today! This is due to be released soon, and you can already try it on devel.
To increase the speed attempted to control to the setpoint with, increase
pos_gain. To increase the current used to achieve the correct speed, increase
vel_gain. You can play with both together, a general description is here.
I don’t think you can see this on the Legacy protocol, sorry. We don’t have much support for that protocol, and we recommend to use the Python USB protocol. We will in the next couple of weeks roll out a new ASCII protocol for use on UART, and there it should be much better. Until then sorry you may have to just wait a fixed ammount of time for now, or hack in your own variables in the exposed variable table.
They should be equal if the tracking is good. If they are not close, then you need higher gains to get the tracking to be better.
I assume you are using SoftwareSerial on the Arduino? SoftwareSerial is rally crap, and it’s better if you use a more powerful arduino like Teensy (recommended), or Arduino Mega.
No, the reason you see that is because it was left out of a half-done refactoring, so those values don’t work right now. This will be fixed with the new ASCII protocol.