Backward / Reverse with SpeedAccelDistanceM1 Function?

[nickosinski]

Hi all,

I'm passing a negative value for speed in the SpeedAccelDistanceM1, but not getting the expected results; clearly this is wrong. Can the SpeedAccelDistanceM1 function be used to go backward? If not, then how should I go about it?

Thank you again!

Nick.

[Basicmicro Support]

Yes, it can go backwards. Please provide your code so I can see if anything is wrong. Distance should always be possitive and direction is controlled by speed sign when using this command.

[nickosinski]

Thank you for your reply!

I've figured out why it's not working, but it poses another question. Here's the command I'm using:

roboclaw.SpeedAccelDistanceM1(address,1800,(speed*1.029),distance-2600, 1);
roboclaw.SpeedAccelDistanceM2(address,1800,speed,distance-2665, 1);

The reason for these adjustments to distance and speed is to accommodate slight variances between the individual motors. Maybe that's not the correct way to calibrate the motors, but if I remove the multiplication factor, the negative speed values then work as expected.

Do you know why the multiplier may be messing things up, or even better, the correct way in which I should be calibrating for differences in the power/speed of my motors?

Thank you again!!!

Nick.

[Basicmicro Support]

1. Make sure the motors speed is matched. If not the tuning isnt close enough yet.

2. The different may be in the wheel diameter. Its a fairly small difference so I could see that being the case.

3. It looks like you are not sending a second distance command for each motor to stop them. If you dont do that then when the first command reaches the specified distance the roboclaw will automatically stop the motors with a 1 second deceleration rate. This is most likely where the -2600 and -2665 are coming from. You just need to send a second buffered command(eg the buffer argument should be 0) to each motor to set the motors to 0 speed at your deceleration rate. When the first command finishes then the buffered command for each motor will be executed.

To calculate how far the wheels will turn during the deceleration back to 0 you need to do some math. Here is a post I made about it: http://forums.ionmc.com/viewtopic.php?f ... tance#p158

[nickosinski]

Thanks very much. Let me read your other post and try again.

Again, very much appreciated!

Nick.

[nickosinski]

Hi again,

I think my problem has to do with properly configuring the PID settings. However, regardless of what values I use for Kd, Kp,Ki, or qpps, the encoders read the exact same values when driving at speed. In fact, if I take out the below statement completely, nothing changes in the motors/roboclaw behaviour or read outs. I'm clearly not setting these values at all no matter what I put into the below function call.

roboclaw.SetM1VelocityPID(address,Kd,Kp,Ki,qpps);

Would you please advise?

Thanks again,

Nick.

[nickosinski]

I've also noted in the forums that the order changed to Kp,Ki,Kd, qpps... I tried that, but no luck there either.

Thanks again,

Nick.

[nickosinski]

Sorry for the rapid posting, but it may help to know that I'm using a very old firmware version: Roboclaw 2x5a v3.1.5

I know it's old, but I don't want to bother upgrading right now. I just want to correctly set the PID values, but the command I'm using is clearly not working. Thank you for your help!

Nick.

[nickosinski]

I hope that I'm not being a nuisance, but I could really use some help.

I only have a Mac computer, but tried installing the IonMotion App via FusionWare... but I don't even see the port available when connected via USB to the Arduino, so I don't think that will work either.

I really just want to be able to use the command to set the correct PID values, but the function doesn't appear to work / respond at all.

Thanks again, in advance!

Nick.

[Basicmicro Support]

Its unlikely the USB functionality will work correctly on a virtual machine. But that doesnt really matter because IonMotion would require the firmware update before it will try to communicate with the board.

The order of the Kp,Ki,Kd didnt change in the firmware. It only changed in the arduino library.

At this point Im not sure there is much else we can do except update the board as we originally offered.