Arguments for Commands 65, 66, 67

Questions about using encoders with the Roboclaw product line
Post Reply
skcolb
Posts: 22
Joined: Mon Oct 19, 2015 5:05 pm
Arguments for Commands 65, 66, 67

Post by skcolb »

There was some discussion of this here but this is a different enough question I think it merits its own thread.

For commands 65, 66, and 67 (buffered drive M* with signed speed, accel, decel, and position), [1] what are the expected types for each argument, and which ones are actually signed?

It would seem to me that only the position value should be signed. However, in some of the Arduino example code, the speed is signed (PacketSerialEncoderSpeedAccelDistance.ino).

This brings me to a related question, [2] can I get away with treating the encoder position as a signed 32-bit integer everywhere? It looks like that's what the Arduino library does. What does the direction bit of the encoder status actually mean (commands 16, 17)?

[3] Is encoder speed (commands 18, 19, 30, 31) reported as an absolute value, or a signed 32-bit integer? As in, do I need to use the direction bit to determine a signed speed?

In general I'm a little confused about the signs of the various parameters, especially since it looks like the Arduino library disregards the sign bits, yet the IonMotion program nicely displays signed information.

And sorry to pile on another question, [4] is there any way to do a relative position command? Say I don't know what position I am at, but I know I want to go 1000 encoder counts forward. Are the two options to (read back the encoder position and add to it) and (set the encoder to 0 and send it to 1000)?

Thanks!
User avatar
Basicmicro Support
Posts: 1594
Joined: Thu Feb 26, 2015 9:45 pm
Re: Arguments for Commands 65, 66, 67

Post by Basicmicro Support »

With these coommands only position is signed. The other three are all unsigned 32bit values.

When using distance commands(not position commands) the speed value is signed which probably explains the examples you saw.

Yes, you can treeat the encoder value as a signed value(or unsigned if you prefer).

The Direction bit indicates if the encoder moved forward or backwards since the last time it was read(eg 1/300th of second previously. If it did not move since then it keeps the value that was already set.

The GetSpeed commands return a signed value. You do not need to use the direction bit. Note that the average speed value(18 and 19) sign and the direction bit will not necessarily match. The instant speed value(30 and 31) sign should match the direction bit though.

The arduino library does not disregard the sign bits. However there is a catch with howthe utility functions work in the arduino library. Some functions. These functions have to be sign agnostic so they are all unsigned(eg the compiler isnt going to create code that changes the sign without my code explicitly doing it).

To execute a relative position movement read the encoder and add the 1000 to that value to move 1000 from the current position using a position command.

The other method you describe will not work(in most cases). If the position is already being held(some previous position command was executed) and you zero the encoder, the PID will think the position has changed(assumign the previous position wasnt already zero) and try to correct it(eg move to the old encoder value).

I think that was all the questions. Let me know if I missed something.
skcolb
Posts: 22
Joined: Mon Oct 19, 2015 5:05 pm
Re: Arguments for Commands 65, 66, 67

Post by skcolb »

Thanks for all the responses!

I completely missed the distinction between the distance and position commands. I think what I actually to use all the time are the distance commands. I noticed that those don't take in a deceleration value -- do they use the same as the acceleration value, or do they use the default?

I assume the distance commands use the same velocity and position PID parameters as the position commands, right?

I am reading and logging the speed data at 10Hz (I think), so I think I will begin using the instant speed value command. Or maybe log both.
User avatar
Basicmicro Support
Posts: 1594
Joined: Thu Feb 26, 2015 9:45 pm
Re: Arguments for Commands 65, 66, 67

Post by Basicmicro Support »

Distance commands accel or deccel depending on what the current speed of the motor is and the specified speed in the command. So if the motor is stopped and you give a distance command the motor uses the accel value to increase the speed to the specified speed. If the motor is already running another speed command and you give a new speed that is lower than that speed it uses the accel argument as a decceleration value.

Unlike position commands distance commands are not inherantly trapezoidal(eg they do not accel, move and deccel). They only accel and move. You must use two distance commands to produce a true trapezoidal move with accrurate distance. First command to accel to speed and run some distance and the second command to deccel back to 0 speed. It takes a little more math since you have to determine the distance it will take to deccel back to zero and subtract that from the first commands distance, but it gives you complete control over how the motors will operate.

One gotcha, if you give a distance command and do not give a command to slow back down to 0 speed, the roboclaw will automatically add a command to slow back to 0 in 1 second after tha last distance command you sent finishes its movement distance.
skcolb
Posts: 22
Joined: Mon Oct 19, 2015 5:05 pm
Re: Arguments for Commands 65, 66, 67

Post by skcolb »

Hmm, okay, I think I actually want to continue using the position commands to have the inherent trapezoidal velocity profile. I think I understand what I'd have to do for the distance commands and how a second buffered command would take care of that though, thanks.
User avatar
Basicmicro Support
Posts: 1594
Joined: Thu Feb 26, 2015 9:45 pm
Re: Arguments for Commands 65, 66, 67

Post by Basicmicro Support »

Ok. Let me know if you need any help. You should be able to calculate the aboslute position at any given point based on your incremental movements. Just keep in mind the position commands have a min and max value setting(soft limits). Change these to the largest range you think you will need(or more).

Post Reply