Encoder does not calibrate offset. Suggests to Invert encoder
  • Setup:
    Three axis gimball each havong GBM3506-130T motor installed. Every motor has a AS5048A (SPI) encoder.
    Encoder can't calibrate electric field and apparently asks to be inverted.

    In order to define a certain yaw position for gimball to assume on start up, I was trying to calibrate el. field for encoder on the Yaw motor.
    As was quite easy to expect nothing could go so easy and I kept receiving errors
    "The "gearing ratio" value after calibration differs from 1.0 significantly."
    And indeed the "Gearing ratio" parameter could never go highter than 0.2 regardless of number of poles and motor inversion that I used (and I have tried quite a few of them, because even the number of poles stated in motor specification (14) did not work) or PID setup.
    At the same time the "ENC_RAW_Y" variable in monitoring section always shows 16,300 with slight variations near that number and does not react on yaw motor being rotated.
    Another thing that sometimes happens is that after el.field calibration I get a -32,767 number in El. field offset spin box for in Yaw section of "Calibration" group box. As a spinbox description was saying (text that appears in the bottom section of GUI) that number is reserved to tell that I need to invert encoder direction, but I have no idea how to do that (did not find any control in GUI that allows it).

    1) How to invert encoder direction?
    2) What should I do to solve the encoder calibration problem, stated in details below?

    Any suggestions (especially helpfull ones) would be appreciated a lot!
  • Hello.

    First of all, you have to ensure that the encoder sends correct data. The "ENC_RAW_YAW" should precisely reflect all rotations (16384 increment per full turn).

    You can not expect a correct behaviour further untill this step wil be not complete.

    You did not say with firmware you use. Try to use the latest 2.66b2 firmware and GUI. To see what is wrong, it may be helpful using "Debug" tab and "Request system state" button.
  • And answers:
    1) How to invert encoder direction?
    calibration will detect it automatically. In latest firmware it is able to update motor inversion, too.
    2) Follow step-by-step instruction, first of all ensure encoder sends correct data and it is actually assigned to YAW motor (axes are not messed)
  • Thanks for answers, Alexmos.
    As for "ENC_RAW_YAW", it indeed sends weird data: when the motor is stable, the variable constantly changes around 32 thousands and when I rotate motor a bit, it starts to change for an instant, but then returns to 32 thousands, and then jumps to zero or to 16k or to -32k...in short, the variable changes are quite erratic and impossible to interpret.
    As for system state, I received this:
    Firmware ver.: 2.63 b0, board ver.:3.6
    assert_line: 0
    COM errors: 0
    Encoder[ROLL] type: AS5048A (SPI)
    magnitude: 66, auto-gain: 254
    diagnostic: CORDIC oferflow!
    read errors: 825
    Encoder[PITCH] type: AS5048A (SPI)
    magnitude: 69, auto-gain: 0
    diagnostic: no problems
    read errors: 590
    Encoder[YAW] type: AS5048A (SPI)
    magnitude: 0, auto-gain: 0
    diagnostic: no problems
    read errors: 2313
    TIME SLOTS FREE (us): 1:453, 2:455, 3:185, 4:402, 5:511, 6:458, 7:457, 8:257, 9:457, 10:506,
    I2C errors: none
    This data constantly changes in the following way:
    1) The "diagnostic: CORDIC oferflow! " does not show up every time I request state
    2) "read errors:" field numbers always grow for every axis with each system state request (i mean over time).

    I actually disassembled the gimball and found that the guy who constructed it mixed up motor and encoder connections for roll and pitch (i mean the encoder from roll motor was connected to pitch encoder slot, while the motor itself was connected to roll motor output slot). However the situation did not change when I plugged wires in a correct way. The data enclosed was collected after those amends.
  • A little addition to my previous comment:

    When I turn roll and pitch motors by 90 degrees, their "ENC_RAW_" variables first change by about 4 thusands but then they constantly jump +- 16 k. It is almost like a type overflow occurs and 14 bit value from encoder is misinterpreted in 16 bits (from -32k to 32k)

    Yaw axis on the other hand does not react on turns at all and stays fluctuating between 13 and 16 k regardless of how I turn it.

    I checked all pin connections at all three encoders and they are all whole and connected in the same sequence (6 wires from each encoder are arranged in plugs that go into the controller in the same manner for each encoder) so the problem does not seem to be in encoder connections.
  • "When I turn roll and pitch motors by 90 degrees, their "ENC_RAW_" variables first change by about 4 thusands but then they constantly jump +- 16 k. It is almost like a type overflow occurs and 14 bit value from encoder is misinterpreted in 16 bits (from -32k to 32k)"
    - it is an expected behavior, so all is correct at this point.

    If YAW encoder gives a lot of errors or does not provide angle, you can't move further untill you correct it. Some hints to find a problem:
    - SPI is parallel bus consist of 3 common signal wires: MOSI, MISO, SCK. If 2 of 3 encoder works, it means thatthose wires goes properly to them, and there is no GND or VCC short-through. But it may be connection error for YAW (broken connection) for 3 signal or 2 common wires GND, VCC.
    - 3 Individual signals CS goes to each encoder. It may be broken/shorted for the YAW only. Try to swap YAW CS and the ROLL CS pin on the board.
    - encoder board may be unfunctional. Replace it to 100% working (from ROLL motor for example) to check this.
  • "- it is an expected behavior, so all is correct at this point."
    That's good to hear, but if I leave only Roll encoder enabled and start calibrating electric field, I get 0.01 gearing ratio and error "ENCODER.CALIB.FAILED"
    And rol encoder also sends " read errors:" which does not make any sence at this point...
  • Ok it appeared that all three encoders were unfunctioning (all three lacked a capacitor on a power line and had wrong circuit voltage).
    After they were fixed, everything went ok.