Issues with e-skateboard motors

dgp · July 21, 2019, 7:29am

I got my odrive v3.6 24v yesterday and I’ve been trying since then to get it to drive some e-skateboard motors for a track drive robot.

The motors are generic brand you’ve never heard of ones from ebay. They are exactly like this https://aliexpress.com/item/32956554997.html just with an output for the hall effect sensors.

Problem 1:

If I try to calibrate the encoder with “odrv0.axis0.encoder.config.ignore_illegal_hall_state = False” I almost instantly get “ERROR_ILLEGAL_HALL_STATE”.
I have 47nf ceramic caps between each of the encoder inputs and ground for both m0 and m1. Maybe I need bigger caps?

Problem 2:

If I try to calibrate the encoder with “odrv0.axis0.encoder.config.ignore_illegal_hall_state = True” sometimes calibration will work and I see the motor move in one direction and then the other. Sometimes I’ll get “ERROR_CPR_OUT_OF_RANGE”.
I followed the hover board guide that says the cpr should be the number of pole pairs * 6. There are 14 magnets in these motors so 7 pole pairs (I think) so 7 * 6 is 42 and that’s what I have in “odrv0.axis0.encoder.config.cpr”. I guess whatever is causing #1 is also causing this.

Problem 3:

When I do manage to get the calibration to complete the movement of the motors is very jerky at low velocity and a lot of the time they don’t move at all or stop moving when load is applied and only start moving again if I spin the motor by hand. I’m guessing that it’s jerky because the sensor input is bad but maybe I’m missing something else.

Problem 4:

If I have axis 0 in closed loop mode but not moving and axis 1 in closed loop mode and moving axis 0 will twitch. Stopping axis 1 stops the twitching. So I think the magnets in axis 1 are affecting the hall sensors in axis 0? I thought this could be the cause of problems 1,2 and 3 but disconnecting axis 1 and moving it far away doesn’t help.

Any help would be appreciated. I only have a 2 channel scope so I can’t capture all 3 signals. I do have a 16 channel logic analyser. If the traces for that would be helpful I’ll wire it up.

Cheers,

Daniel

dgp · July 21, 2019, 9:04am

This is the output from my LA. It looks like the issue is that the first triggered sensor is a bit sensitive and is still on for a time while the third sensor has triggered.

Is there a reason this shouldn’t work? It seems the odrive just needs to know the rotor passed the hall sensors and which direction (pulse order) it was going so as long as they go high or low without overlapping that should be workable?

madcowswe · July 22, 2019, 8:57pm

Your hall signals are not standard. They should be 120 degrees apart, but are only 60 degrees apart (electrical). You can invert “channel 1” and it will be correct. I don’t know if you are able to do that electrically? You may be able to do it in firmware if you are comfortable with that.

dgp · July 23, 2019, 1:25am

Thanks for the response!
I’ve changed the mapping here:

github.com

madcowswe/ODrive/blob/d2e975b95224da3e635f226d9c73b66c9e73fe3a/Firmware/MotorControl/encoder.cpp#L265


        return false;


    config_.offset = encvaluesum / (num_steps * 2);
    int32_t residual = encvaluesum - ((int64_t)config_.offset * (int64_t)(num_steps * 2));
    config_.offset_float = (float)residual / (float)(num_steps * 2) + 0.5f; // add 0.5 to center-align state to phase


    is_ready_ = true;
    return true;
}


static bool decode_hall(uint8_t hall_state, int32_t* hall_cnt) {
    switch (hall_state) {
        case 0b001: *hall_cnt = 0; return true;
        case 0b011: *hall_cnt = 1; return true;
        case 0b010: *hall_cnt = 2; return true;
        case 0b110: *hall_cnt = 3; return true;
        case 0b100: *hall_cnt = 4; return true;
        case 0b101: *hall_cnt = 5; return true;
        default: return false;
    }
}

Haven’t flashed it yet but I guess that’ll work.

Cheers,

Daniel