Page 1 of 1

Detecting A 90 Degree Turn

Posted: Thu Aug 29, 2019 3:01 pm
by Bill
My first project ...

small 2 wheeled robot car
a third wheel (ball caster) for balance

5" wide, rotate on the center point between the wheels

3" diameter wheels

motor like one of these in the 90 rpm to 270 RPM range:
https://www.servocity.com/motors-actuat ... h-encoders

For various RPMs and percentages of the RPM I have spent a lot of time figuring out how to calculate times and pulse counts to rotate 90 degrees.

For a 90 RPM motor running at 25% of its no load RPM it theoretically should take about 1.1 seconds and 744 pulses to reach 90 degrees.

I looked at another motor controller. It has two functions for reading encoder values:
  • #1: the values read are updated every 1/8 of a second but "the three least significant bits are padded with zeros", which I think means are set to zero, i.e. the values are rounded DOWN to a multiple of 8.
  • #2: the values are updated every second, no "padding" of bits, but if I read at the 1.5 second mark, I get the 1 second value.
Question #1: Can the RoboClaw provide encoder values to a Raspberry Pi quickly enough to detect when 90 degrees has been reached.

I've read this topic:
viewtopic.php?f=2&t=523

Question #2: Does that imply that I should look for a different encoder than the hall effect encoders on the ServoCity like motors OR stick with hall effect encoders for this first project.

Thanks

Re: Detecting A 90 Degree Turn

Posted: Fri Aug 30, 2019 9:28 am
by Basicmicro Support
With a properly tuned PID you can just tell the Roboclaw to move X amount or move at Y speed(see position and speed commands).

You can, of course, do this all manually yourself. Roboclaw updates its encoder counts 300 times a second. Most commands take 1 to 2 ms to process at 115200bps. But it would make more sense to offload the accurate movements to the Roboclaw since that's what it was designed to do.

Re: Detecting A 90 Degree Turn

Posted: Wed Sep 04, 2019 6:28 am
by Bill
Thanks for the pointers.

Question: Are these the commands that you are referring to?

41 - Buffered M1 Drive With Signed Speed And Distance
42 - Buffered M2 Drive With Signed Speed And Distance
43 - Buffered Drive M1 / M2 With Signed Speed And Distance

or

44 - Buffered M1 Drive With Signed Speed, Accel And Distance
45 - Buffered M2 Drive With Signed Speed, Accel And Distance
46 - Buffered Drive M1 / M2 With Signed Speed, Accel And Distance

or

65 - Buffered Drive M1 with signed Speed, Accel, Deccel and Position
66 - Buffered Drive M2 with signed Speed, Accel, Deccel and Position
67 - Buffered Drive M1 & M2 with signed Speed, Accel, Deccel and Position

Question: regarding 41, etc and 44 etc versus 65 etc

Are Distance and Position the SAME thing, both in quad pulses per second

Question: given pulses per second, does that mean I can't move 1/4 of the pulses per second?

Thanks

Re: Detecting A 90 Degree Turn

Posted: Wed Sep 04, 2019 9:57 am
by Basicmicro Support
For a wheeled differential steering vehicle, you want the distance commands(the accel versions are better since you can specify the accel/decel rate).

But I got the impression this is more for controlling something like a servo. For servo like action use the position commands.

Distance commands move a specific relative distance from the current location.

Position commands move to a specific absolute position.

The resolution of the encoder dictates how accurately you can move. No, you cant move 1/4 of an encoder count. If you need that kind of resolution you need a higher resolution encoder. In fact, you should have an encoder that is several times higher resolution than your movement resolution needs to be because of gear train slop and tuning. As long as your encoders are sending out clean signals your encoder count will always be accurate. However, telling the controller to move the motor to a precise location with 0 error isnt likely without excessive time and/or expense. Controlling positional accuracy within a few counts(especially on a high resolution encoder) is usually more than enough.