monitor packet serial with MotionStudio?

General discussion of using Roboclaw motor controllers
Post Reply
jameslo
Posts: 4
Joined: Thu Jul 11, 2019 10:03 am

monitor packet serial with MotionStudio?

Post by jameslo » Thu Jul 11, 2019 10:51 am

I noticed that I can use MotionStudio to monitor motor speed, PWM, etc while a Roboclaw 2x7A is responding to packet serial commands, but it appears that if I choose to graph Motor1 Setpoint, it doesn't do what I would expect it to: display the speed requested in the most recent packet for Motor1. Is that true, or am I not setting things up properly?

I'm trying to chase down a bug where Motor1 stops responding to packets every so often. From my instrumentation code, it doesn't appear that I'm somehow failing to send packets, and it would be nice to know if the Roboclaw is receiving them. Any suggestions for further debugging steps would be appreciated.

User avatar
Basicmicro Support
Posts: 1201
Joined: Thu Feb 26, 2015 9:45 pm

Re: monitor packet serial with MotionStudio?

Post by Basicmicro Support » Fri Jul 12, 2019 10:14 am

The SetPoint chart data is from Motion Studio(eg Motion studios current duty, velocity or position for that motor). Motion studio does not query the Roboclaw for that data which is why when you use an external command to control the motor Motion Studio won't graph it.

As for your problem, are you using one of our libraries or something you wrote custom?

jameslo
Posts: 4
Joined: Thu Jul 11, 2019 10:03 am

Re: monitor packet serial with MotionStudio?

Post by jameslo » Fri Jul 12, 2019 6:59 pm

I'm using your Arduino library on a MKR1000, and am checking the forwardMX/backwardMX return value (always returns true). It's a mecanum wheel robot so I'm wrapping the calls inside a function that gives me a higher level movement command:

Code: Select all

//direction = 0..2, where 0/2 = forward, 0.5 right, 1 back, 1.5 left
//speed = 0..1
//turn = -1..1, where 1 = right
void movePolar(float direction, float speed, float turn) {
  //compute the longitudinal and lateral motion terms
  float longitudinal = cos(direction * 3.141592) * speed;
  float lateral = sin(direction * 3.141592) * speed;
  //add all terms in the polarities required for each wheel and convert to a controller speed value
  int FLspeed = castAndClip((longitudinal + lateral + turn) * 127);
  int FRspeed = castAndClip((longitudinal - lateral - turn) * 127);
  int RLspeed = castAndClip((longitudinal - lateral + turn) * 127);
  int RRspeed = castAndClip((longitudinal + lateral - turn) * 127);
  Serial.print(FLspeed);
  Serial.print(" ");
  Serial.print(FRspeed);
  Serial.print(" ");
  Serial.print(RLspeed);
  Serial.print(" ");
  Serial.println(RRspeed);
  bool success;
  if (FLspeed >= 0) success = roboclaw.ForwardM1(FRONT, FLspeed); else success = roboclaw.BackwardM1(FRONT, -FLspeed);
  if (!success) Serial.println("FL failed");
  if (FRspeed >= 0) success = roboclaw.ForwardM2(FRONT, FRspeed); else success = roboclaw.BackwardM2(FRONT, -FRspeed);
  if (!success) Serial.println("FR failed");
  if (RLspeed >= 0) success = roboclaw.ForwardM1(REAR, RLspeed); else success = roboclaw.BackwardM1(REAR, -RLspeed);
  if (!success) Serial.println("RL failed");
  if (RRspeed >= 0) success = roboclaw.ForwardM2(REAR, RRspeed); else success = roboclaw.BackwardM2(REAR, -RRspeed);
  if (!success) Serial.println("RR failed");
}

int castAndClip (float speed) {
  if (speed > 127.0) {
    digitalWrite(OVFL_LED, HIGH);
    return 127;
  }
  if (speed < -127.0) {
    digitalWrite(OVFL_LED, HIGH);
    return -127;
  }
  return round(speed);
}
I thought excessive current draw might be causing the controllers to briefly freeze so I upped the max current to 5A above the rated stall current of my motors, and that seems to have reduced the frequency of it being unresponsive. Would brief over-current conditions cause the Roboclaw to stop responding to new packet commands?

The program where I can see it most clearly is one where I am moving the vehicle in a circle while facing one direction. That consists of a constant speed while the direction ramps from 2 to 0 repeatedly. Graphing both the PW and speed under the velocity tab, I can see both level off briefly, then jump to rejoin the sine curve. https://www.dropbox.com/s/9rj6nknwjbz67 ... 1.JPG?dl=0 Also, when I graph Motor N Speed Error, it's flat lined. That's why I expected Motor N Setpoint to show the last requested serial packet speed.

User avatar
Basicmicro Support
Posts: 1201
Joined: Thu Feb 26, 2015 9:45 pm

Re: monitor packet serial with MotionStudio?

Post by Basicmicro Support » Mon Jul 15, 2019 11:00 am

If your power source cant supply enough power your input voltage will drop which can cause brownouts. Your delay in response is almost exactly as long as it takes to reboot the Roboclaw.

If you mean you set the maximum current limit to just enough to run the motor I'd recommend not doing that. If the problem goes away you know that was the cause of the problem.

jameslo
Posts: 4
Joined: Thu Jul 11, 2019 10:03 am

Re: monitor packet serial with MotionStudio?

Post by jameslo » Mon Jul 15, 2019 11:19 am

I don't think the Roboclaw is rebooting because the other channel M2 continues to follow the sine curve I've programmed for it.

The motors I'm using have a published stall current of 5A, and I've set M1 Max current to 10A while M2 is set to 6A. To test if the M1 motor was faulty, I swapped front and rear controllers, but the issue followed the Roboclaw. Even at 10A max current, M1 has occasionally stopped responding to serial packets, although far less frequently.

User avatar
Basicmicro Support
Posts: 1201
Joined: Thu Feb 26, 2015 9:45 pm

Re: monitor packet serial with MotionStudio?

Post by Basicmicro Support » Wed Jul 17, 2019 10:20 am

You will need to add debuging code to the library then, to see what is causing the unexpected delay. Add Serial.println statements where needed to determine where the program is freezing up.

The MKR1000 is an arm based board and has never been tested with the Roboclaw arduino library before so it could be something to do with that.

First, however download the arduino library again. We found a bug that only affects arm processors(probably only ARMs with MMUs though) earlier this week and just updated it. On ARM processors with memory protection it would have caused a hard fault everytime you used a read command.

Reproduce the problem with the new library before adding any debugging code.

jameslo
Posts: 4
Joined: Thu Jul 11, 2019 10:03 am

Re: monitor packet serial with MotionStudio?

Post by jameslo » Thu Jul 18, 2019 3:07 pm

I updated your Arduino library and improved my debugging code, but I don't think there is anything wrong with your library vis-a-vis the SAMD21 and my application. I'm only using forwardMX and backwardMX, and those functions are just wrappers to write_n, which itself is mostly handling your packet serial protocol ahead of straightforward serial writes and reads. The delay continues to be correlated with a maximum M1 current setting of 6A instead of 10A, which to me is odd since M2 is happy with a 6A max motor current setting. Actually, this issue now seems to me to be less about ignoring packets and more about periods of time when Roboclaw does not want to drive the motor, because I can't recall an instance where a motor was stuck running fast. I would like to investigate whether the Roboclaw is falsely detecting an overcurrent condition on M1, because in this last round of tests I've seen it limit the PWM when the motor speed crosses zero, not at peak. See https://www.dropbox.com/s/f0tvqczexfqxd ... 3.jpg?dl=0 for an example. Can you suggest a way to test this?

User avatar
Basicmicro Support
Posts: 1201
Joined: Thu Feb 26, 2015 9:45 pm

Re: monitor packet serial with MotionStudio?

Post by Basicmicro Support » Fri Jul 19, 2019 10:29 am

If the problem is in the current please graph the current. The motor speed doesnt necessarily correlate to motor current. You need to see the current data to make any connections.

In your first post you mention a 2x7A. But that was for a different question(PWM SetPoint). Are you still using a 2x7A now. If so it is surprising the current reading isnt spot on. The 2x7A has 10 times the resolution of any other Roboclaw(because it can use a larger shunt resistor to measure it).

Graph the current readings along with the other values you already graphed. Also you may need to adjust the current blanking percentage. It should be 5.3 or 5.4% by default. You can set it as high as 20%. At very low duty motor noise will swamp the current readings. If your motor is particularly noisy you may need to raise this percentage.

Also, if you are using dc motors with hall effect quadrature encoders? If so you may need to put .1uf or .01uf caps on the a and b signal lines and the 5v line going to the encoder(s) from the Roboclaw. Some of these motors are known to inject a large amount of noise in to the signal and 5v lines which could cause problems with analog readings(eg current sense readings).

If you have an oscilloscope check the encoder signals and 5v line as well while running the motors.

Post Reply