ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

OpenCR and encoders

I want to use my OpenCR board to interface with two quadrature encoders for odometry and wanted to get your thoughts on different approaches.

I did some searching and the STM32F7 is capable of reading quadrature encoders (I’m not sure how many yet) but this may conflict with the current firmware settings on the board.
Anyone know if the Low-power timer (LPTIM1) is being used for anything?
STM32F746ZG Datasheet

My other option would be to use external counters and interface to them via SPI…
3 axis Arduino encoder shield

Other methods I should consider?

I’m leaning towards the external counters but is there anything I’m missing that would interfere with the above shield?

Any suggestions would be greatly appreciated!!!

Have you looked at the Turtlebot3 source? You can find it in the OpenCR code. The turtlebot3 uses encoders for odometry. It uses dynamixel’s sdk, which you can definitely find the source for.

I have slowly been working my way through the source, but haven’t made it to the odometry section yet. The Dynamixel motors are “smart” servos and perform their own position/velocity control and just report this info back the the Opencr board.

Sorry I wasn’t very clear with my plans. I want to use the Opencr board exactly as the TurtleBot3 does, but swap out the Dynamixel’s for larger motors with encoders. This will require the Opencr board to take on the servoing of the wheel motors and calculate odomerty on its own. I feel comfortable modifying the source to do this but wanted to see if anyone had advice or suggestions on adding encoders to into the mix.

I have experimented with the STM32 processor and did want to use it’s builtin ability to read quadrature encoders. I had to give up because of a conflict over timber use.

But I did find the CPU has zero trouble at all with VERY high interrupt rates I have four motors each spins up to about 11,000 PRM and has 64 pulses per revolution. The processor can handle the maximum rate and still do quite a lot else. that would be (4 x 11,000 x 64)/60 interrupts per second. That said the interrupt handler in C++ is very short and fast.

You can further speed up the processing by a large factor if you remember the last time the motor changed directions and then you can ignore that the encoder is using quadrature. And your handler becomes “i = i + direction” Just one statement.

So the simplest way to to do the encoder handing inside an interrupt handler in software.

But if you can use the STM32 counter hardware that just seems so much more efficient but in my case I ran out of timers