Using the SPI interface is pretty simple, and it’s much more robust because you don’t have to do an open-loop movement for index search (remember that if you have any significant load on the motor, then index search and encoder offset calibration are likely to fail).
On the RazorsEdge branch, AS5047P works out of the box with SPI. You just have to connect the MISO/MOSI/SCK/CS wires (plus VCC and GND) and then set the encoder type to ENCODER_TYPE_ABS_AMS, and also set the GPIO pin that you are using for CS.
1 degree might be enough for you in terms of positioning, but what about noise? It’s pretty normal and usually unavoidable for any motor controller to vibrate at least +/- 1 encoder count when holding position, and the frequency of that vibration depends on the gains you set - the tighter your tuning the more severe that vibration (limit cycling) gets, until it becomes completely unstable. The motor’s natural cogging effectively puts a variable offset on the torque that the drive applies, depending on position, and disturbs the usually linear relationship between current and torque.
With a higher resolution encoder you give the odrive a chance to reduce the motor vibration, and even to measure/model the cogging and calibrate it out, which helps linearise the dynamic system and achieve better performance without becoming unstable.
Edit: As to the behaviour in your video, try using the liveplotter to check that the odrive is aware of this position error. If it is, It may be that your gains are set SO low (to avoid instability) that the only thing still active is the velocity integrator, and it is jumping between two poles due to cogging.
If you are unable to tune the motor better than this, then perhaps you are in trouble.
If it’s not aware (ie the odrive doesn’t see the huge discrepancy between commanded and actual position) then there is something wrong with your encoder.
Since you only need on/off control, you could try a different approach- what if you had no position feedback at all, and just drive the motor like a 3-phase stepper (this is what the encoder offset calibration and index search do) until it hits a limit switch? (or until you see your encoder position stop changing)
Also, try setting the position gain to 0 and seeing if it is stable in CTRL_MODE_VELOCITY_CONTROL - you can probably increase the vel_gain and vel_integrator_gain a bit.
Once you’ve got that working, you could then try increasing pos_gain, maybe you will get something which works well enough…
v4 tho