SVP and New Encoders

I’m thinking about building a robot using the SVP-1284 and some of your relatively new metal gear motors with the integrated 64 CPR encoders.

I’d like to use the PIC to handle the quadrature decoding and counts but I’m a little bit concerned about whether the counting rate will be too high for the PIC to handle, particularly for the highly geared versions (100:1, 122:1). Although the trade off between RPM and gearing probably puts all those motors in a similar range. Have you had any experience using these motors and encoders with the SVP?

Assuming the 100:1 motor at a worst case scenario of 100 RPM (no load)
You end up with 100 RPM / 60 * (64 CPR * 100) = 10666 counts per second
Also given an integer output for the count from the PIC, you’ll have to reset the encoders at least every 3 seconds but that itself shouldn’t be a problem.

I realize it’s not likely to be moving that fast in reality but at the same time I’m not sure what the interrupt latency and speed (12MHz?) of the PIC is. I wouldn’t think it should be a major problem, given it’s a kHz to MHz comparison, but it’s nice to get some confirmation. Those rates are certainly an order of magnitude more than the output shaft Pololu wheel encoders I’m used to using.

That’s a good question, lumos.

I just tested the Orangutan SVP with two of our 64 CPR motors running full-speed at 12 V. Both encoders achieved about 10000 counts per second (2.5 kHz) and the SVP was able to read them without encountering any encoder errors, so I think the SVP will work for you. I performed this test using a little SVP program that prints both encoder counts and beeps whenever there is an encoder error. The code is below:

#include <pololu/orangutan.h>

int main()
{
    unsigned short count = 0;
    svp_set_mode(SVP_MODE_ENCODERS);
    while(1)
    {
        lcd_goto_xy(0,0);
        print_long(svp_get_counts_ab());
        print_from_program_space(PSTR("     "));
        lcd_goto_xy(0,1);
        print_long(svp_get_counts_cd());
        print_from_program_space(PSTR("     "));
        lcd_goto_xy(8,1);
        print_long(count++);
        print_from_program_space(PSTR("     "));
        if (svp_check_error_ab()){ play(">c64"); }
        if (svp_check_error_cd())
        {
            while(is_playing());
            play(">f64");
        }
    }
}

Here are some tips for using the SVP with these encoders:

  • The Pololu AVR library only has 16-bit precision for the encoder counts, which means it will overflow in about 3 seconds with these motors. You should call svp_get_counts_and_reset_*() frequently and use that to keep track of your angle & position.
  • You should call svp_check_error_*() at least during the development phase of the robot to make sure that the auxiliary processor can read the encoders fast enough.
  • The auxiliary processor’s SPI communication is handled by an interrupt that is higher priority than the encoder interrupt, so if you use the SPI too heavily you might start getting encoder errors. I did not get any encoder errors using the code above, but it’s possible that when you add some more code that uses SPI you will start getting encoder errors. A good workaround for this would be to modify OrangutanSVP.cpp in the Pololu AVR Library and make all the SPI delays longer (increase the 2nd argument of every call to transmitAndDelay). But actually it would be easier to just change the SPI frequency to be slower, by writing to the correct AVR register after our library initializes the SPI module (after the first SPI command).
  • When making my connections, I found these crimping products to be very useful: Crimping Tool for 0.1" Housing Crimp Pins, Male Crimp Pins for 0.1" Housings 100-Pack, and 0.1" (2.54mm) Crimp Connector Housing: 1x2-Pin 25-Pack.

Good luck on your project, and let us know how it goes!

–David

P.S. You were right: the auxiliary PIC runs at 12 MHz.

Thanks David,

I appreciate you going out of your way to actually test it - great customer service!

I’ll definitely take those tips under advisement, I was aware of the 16-bit count issue but the SPI interrupts and SVP error checking is good to know. Will be keeping an eye out for those issues during development.

Time to get to work designing the chassis now!