Q's about closed loop speed and count mode for 4 wheeled vehicle.

We are using 4 MBL1660A drives in a 4-wheeled vehicle that we plan to ride along a pre-defined track. The track is a closed loop track. End point is the same as starting point. At any given point along the track we want to be able to have control over the speed and position. We have been evaluating (on a setup with 1 drive + motor):
- Closed loop count position mode
- Closed loop speed position mode
- Closed loop speed mode.

We have done most evaluating for Closed loop speed position mode. During the tests we write speed commands (every 20ms) that match a certain predefined speed profile. We read the CB counter (@20ms interval) and log it. We use the hall sensors as feedback (96 counts/rev). During the test we also monitor the loop error.

In order to evaluate the outcome we want to compare the speed and position of the vehicle to the reference speed and reference position information that we define/calculate in an offline script. From the CB count values from the vehicle we can calculate the actual vehicle linear position and by calculating the derivative we know the speed. The reference speed we define as a sequence of speed command over time. The reference position information can be calculated by integrating the defined speed profile. This model isn't accurate enough. It does not take into account how the motion planner and PID loop shape the internal speed profile. The questions below will help us get a better understanding of the inner workings of the drive in the various modes.

Loop error:
- What is the definition of the loop error value in the 3 modes above, does it represent a speed value or position value?
- When running the motor in closed loop speed counter mode the loop error is not zero. We have seen it fluctuate around base values of ~20-200 depending on PID setting. What the correct behavior of the loop error? Are the values we are seeing within range? In closed loop count position mode the value fluctuates around zero? The speed modes have a much higher average value.
- To get the most accurate CB value reading can we offset the CB value with the loop error value at a given time?

Motion planner:
- In closed loop speed position mode, according to the manual, the trajectory planner calculates a new position command every 1ms. What's the algorithm, profile etc used by the trajectory planner? When we write a new speed command every 20ms, what the influence of the trajectory plannner on the speed profile. We want to include the behavior of the trajectory planner in our model that calculates the reference position.
- Are the trajectory planner in "closed loop count position" mode and "closed loop speed count" mode the same?


Operating mode:
- In general what's the recommended mode for a scenario like ours.



Thanks.

You are always going to have inaccuracies with this method of calculating linear position since it is a form of dead reckoning - all position data is based on odometry and is not localized to anything within the outside world. When your wheels slip, the change in position will not be reflected properly in the counter, and over time the error will drift until you localize to something. We are actually working on a sensor that will be able to provide a much better form of odometry, but even with that you should still be localizing to features in your environment at some point.

How you are commanding the Robot doesn't really matter - the amount that the wheels turn will always be accurately reflected by the encoder counters, so there is no need to derive and re-integrate it again. All your error is going to come from differences between the wheel osition and your Robot Position.

What is the definition of the loop error value in the 3 modes above, does it represent a speed value or position value?

Loop error represents the error that is presented to our internal PID loop. In position modes, it is a difference between a desired speed, calculated through our firmware's trajectory planner, and the encoder counter. In closed loop speed mode, it is a difference between the measured speed of the controller and the desired speed from the motor command. How our firmware plans trajectories, and implements the PID controller is documented for each mode in our User Manual .

When running the motor in closed loop speed counter mode the loop error is not zero. We have seen it fluctuate around base values of ~20-200 depending on PID setting. What the correct behavior of the loop error? Are the values we are seeing within range? In closed loop count position mode the value fluctuates around zero? The speed modes have a much higher average value.

The error in closed loop speed position mode is the target counter ticks of the rotor minus the current counter ticks of the rotor. The target ticks are gotten from a planned trajectory that is generated as a motion path from the rotor being at a constant speed that you command with a motor command.

To get the most accurate CB value reading can we offset the CB value with the loop error value at a given time?

No. That is the point that I would really like to drive home with this post. Regardless of what our control loop is doing, the counter value is the counter value, and it keeps track of the position of the rotor very accurately. However, getting the position of your vehicle from the rotor position is not very reliable.

In closed loop speed position mode, according to the manual, the trajectory planner calculates a new position command every 1ms. What's the algorithm, profile etc used by the trajectory planner? When we write a new speed command every 20ms, what the influence of the trajectory plannner on the speed profile. We want to include the behavior of the trajectory planner in our model that calculates the reference position.

Closed Loop speed position mode just adds counts to the target position at a set interval. It is the equivalent of calling a series of relative position moves, but at set intervals. It will then increase the amount of counts to the target position to match the speed you set. However it plans trajectories, the commands you send to it are not a good thing to base your position measurements on when you have your counter available.

I hope it's clear that trying to model the vehicle position by integrating over your motor commands is the wrong approach, and that trying to measure an autonomous vehicles position in space using only internal measurements is an nonviable approach. You will have to use some kind of external position sensor for a reliable position measurement.