Page 1 of 2

monitor packet serial with MotionStudio?

Posted: Thu Jul 11, 2019 10:51 am
by jameslo
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.

Re: monitor packet serial with MotionStudio?

Posted: Fri Jul 12, 2019 10:14 am
by Basicmicro Support
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?

Re: monitor packet serial with MotionStudio?

Posted: Fri Jul 12, 2019 6:59 pm
by jameslo
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.

Re: monitor packet serial with MotionStudio?

Posted: Mon Jul 15, 2019 11:00 am
by Basicmicro Support
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.

Re: monitor packet serial with MotionStudio?

Posted: Mon Jul 15, 2019 11:19 am
by jameslo
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.

Re: monitor packet serial with MotionStudio?

Posted: Wed Jul 17, 2019 10:20 am
by Basicmicro Support
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.

Re: monitor packet serial with MotionStudio?

Posted: Thu Jul 18, 2019 3:07 pm
by jameslo
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?

Re: monitor packet serial with MotionStudio?

Posted: Fri Jul 19, 2019 10:29 am
by Basicmicro Support
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.

Re: monitor packet serial with MotionStudio?

Posted: Sat Jul 20, 2019 10:49 am
by jameslo
Thanks, I think current blanking was the issue. The 2x7A in question was set to 4.8% while the other was over 5%, which explains why the issue followed the controller. When I increased current blanking to 8%, I was able to reduce maximum motor current to 6A with only one hesitation in 24 hrs. I will continue to monitor and adjust over the next week or two.

What is the tradeoff of having a high current blanking value? Does it affect the optimum PID values? What maximum motor current setting do you recommend relative to the motor's published stall current?

Regarding hall effect encoder noise, I am seeing what looks to be a lot of HF noise, see https://www.dropbox.com/s/195sjezb89anf ... 0.JPG?dl=0. Is this a lot in your experience? Adding a 0.01uF bypass cap lowers the noise a bit at the expense of a slower positive slew rate, see https://www.dropbox.com/s/3ej28rsv72t7b ... 2.JPG?dl=0. Is this level of noise and slew rate acceptable? 0.1uF doesn't appear to reduce the noise any further, but is so slow that the pulse doesn't reach the high level at fast motor speeds. For testing, I am placing the bypass cap at the roboclaw input pins, but would it be more effective nearer the motor?

Re: monitor packet serial with MotionStudio?

Posted: Mon Jul 22, 2019 10:05 am
by Basicmicro Support
Current blanking sets the range of PWM duty that current will not be sampled. From -8 % duty to 8% duty in your current case.

Primarily you want to make sure your motor cant produce current high enough to damage the controller within that range. So for example, it would take a motor with a stall current of 94 amps to potentially damage the controller anywhere within the range you set(eg 7.5amps/.08 = 93.75amps, eventually. And even then it would have to be a stalled motor to do it. It would take a long time, assuming ambient temps are around 25C, but eventually, you could damage the controller in this totally theoretical and unrealistic scenario.

In most cases, I recommend not changing the current limits. If you know you will be running in a high ambient temp environment then you can start worrying about it. Or if you have a motor that CAN pull more current than it can safely use. In that case, set it to a reasonable setting for that particular motor. In all other cases, relatively normal ambient, motors that cant damage themselves, leave the current limit set to defaults.

When running a DC motor in most situations you will have periods where you will briefly want as much current as the motor can draw(or the controller can source), like when accelerating.

If the .1uf isn't cleaning it up much it maybe something else. I see several fairly high spikes but it doesn't appear to be at 20khz(eg pwm). PWM across the motor causes noise and commutator transitions to cause noise. This may be mostly commutator noise(eg sparking) remaining after add the .1uf cap to the signal lines.

You should probably add a .1uf cap across the motor leads at the motor. You can also try adding 0.1uf caps from each motor lead to the motor chassis as well. This is a common method to reduce commutator noise.