Robot not moving straight because of different friction in motor gears

[fjp]

The odometry updates are working after the use of wheel joint delta angles to update the joint positions in the hardware interface (see the code here). However there is a problem when simply mapping the velocity command from the diff_drive_controller to the power output percentage for the motor driver in the RobotHW::write(). The robot is not moving straight, its moving slightly to the left. This is because one of the motors (the one on the left side) seems to have slightly higher internal gear friction. I have created a video to show this behaviour.

diff_drive_controller cannot solve this problem because it is only forwarding the /cmd_vel command: see its code here so it is not taking care whether the encoder ticks increase on one wheel but not the other.

As seen in the video possible solutions are:

1. Use better hardware, more precise motors in this case - not really an option for me because I would like to keep using the current motors.
2. Calibrate the motors in code using threshold/tolerance offset values to provide slightly different outputs to the motors, so that they move and stop at the same time.
3. Implement a PID controller inside the high level DiffBot's RobotHW::write() method or in the low level motor driver node, something like u=k*(v_actual - v_target)? This should apply the correct amount of output power to a motor depending on the actual velocity error on the wheel joint. ROS Control expects that the commands coming from a controller such as diff_drive_controller (velocity command) must be applied at the actuators.

To get the robot driving straight are there other ways other than the ones mentioned above and which one should be used to solve the issue? I prefer the PID controller, because it seems to solve the problem with less code. I tried the 2nd option but it seems that a lot of if else cases or even a simple state machine are needed for this. And in case of the 3rd option where should the PID be implemented? In the high level hardware interface RobotHW::write() or the low level motor driver.py node? Currently I would put it in the high level hw interface because all the joint velocities (actual and desired) are already calculated there. But having it in the motor driver node seems also correct, although this will require at least another subscriber in this node or re-writing it so that it subscribes to the commanded and measured velocity.

Any suggestions are more than welcome.

[fjp]

Comments from The robocademy:

I'd go for option 3 with the PID controller inside the hight level hardware interface because it's easier to adjust and also you could implement the dynamic reconfigure in order to have a flexible adjustment of these parameters.

Let's start by implementing a PID in a high-level hardware interface. We will get a lot of issues while choosing a cheap motor. These motors are not designed for accurate operation, so each will be triggered in different levels of voltage. One initial step that we can do is, apply the same voltage to both of these motors and keep changing the voltage using a standard SMPS power supply, so you can identify which starts first and which start next. If we have multiple motors, we can test in all combinations and select the best matching motors.

Also, I hope you also checked the voltage from the motor driver. Make sure, both channels giving the same values. So if the values are correct, then the suspect is the motor.

I also assume the caster wheel is fixed, so that it will not rotate when the robot starts. If it rotates, then it can change the direction too. Check the wheel alignment too. Choose very similar wheels and check the axis of rotation. If there is any change in the axis of rotation, it may affect movement.

Also, weight distribution plays a role too. The motor triggering can be delayed due to more weight distribution to one wheel.

Even though this robot is very difficult to make accurate, the good thing is, we will learn a lot of aspects of robotics and its fine-tuning in hardware and software.

[fjp]

I'll start to implement the PID controller in the high level hardware interface and see how it works.

implement the dynamic reconfigure in order to have a flexible adjustment of these parameters.

Good idea, I add that too.

One initial step that we can do is, apply the same voltage to both of these motors and keep changing the voltage using a standard SMPS power supply, so you can identify which starts first and which start next. If we have multiple motors, we can test in all combinations and select the best matching motors.
Also, I hope you also checked the voltage from the motor driver. Make sure, both channels giving the same values. So if the values are correct, then the suspect is the motor.
Also, weight distribution plays a role too. The motor triggering can be delayed due to more weight distribution to one wheel.

Good suggestions, I didn't check the voltage levels of both channels yet. Maybe the motor driver is the main problem.

I also assume the caster wheel is fixed, so that it will not rotate when the robot starts. If it rotates, then it can change the direction too. Check the wheel alignment too. Choose very similar wheels and check the axis of rotation. If there is any change in the axis of rotation, it may affect movement.

The caster wheel of the kit that DiffBot uses can rotate freely but as you mention it can lead to errors depending on how it is initially aligned.

[fjp]

Also, I hope you also checked the voltage from the motor driver. Make sure, both channels giving the same values. So if the values are correct, then the suspect is the motor.

I have just checked the voltage output of the motor driver. Both channels give the same voltage level when the same output value is applied.

[fjp]

Here is an update on how this issue is going on (should be solved soon):
To control the motors I am now using two instances of a new PID class that inherits from control_toolbox::Pid which is part of ROS Control. The control_toolbox::Pid provides ROS dynamic reconfigure for the its three gains (P, I, D). With only these gains it is hard to tune the motors resulting in overshoot and instable behaviour (motor output switches between positive and negative values). Another problem is that the i_error can get really large (windup) when the setpoint isn't reached for a long time. Although there is antiwindup functionality in the control_toolbox::Pid, I have added the following check (also done by Linorobot's low level PID) to reset the errors (especially the i_error), (here in my code):

// Reset the i_error in case the p_error and the setpoint is zero
// Otherwise there will always be a constant i_error_ that won't vanish
if (0.0 == setpoint && 0.0 == error_)
{
     // reset() will reset
     // p_error_last_ = 0.0;
     // p_error_ = 0.0;
     // i_error_ = 0.0;
     // d_error_ = 0.0;
     // cmd_ = 0.0;
     reset(); // this method is inherited from control_toolbox::Pid
}

To get everything more stable I am using a feed forward gain (adding f * setpoint to the PID output) to reach the setpoint faster. This helps a lot to get the motors spinning at roughly the same time.

The only disadvantage is that the F gain value is currently hard coded. Now I would like add this gain value to the same group of dynamic reconfigure values as the ones provided by the control_toolbox::Pid which my PID class is inheriting from. Currently there is /diffbot/pid_lef and /diffbot/pid_right for the left and right motor respectively, each having parameters for p, i, d, i_min, i_max, anti-windup. I hope adding the f gain parameter is possible.

[fjp]

I checked the voltage levels of the motor driver Grove i2c motor driver v1.3 and they look good, both motor outputs give the same voltage.
I will also test some different sets of motors next, maybe one of them has a slight defect.

And I finished editing the PID tuning video, you can see the best result at the beginning. The rest of the video shows the tedious tuning process (feel free to skip some sections). For the best found behaviour, the parameters of the high level PID are set to the following:

F = 0.8 (the feed forward term is used to reach the set point faster)
P = 0.35
I = 0.5
D = 0.01 (if this is set higher, everything becomes unstable. I think because of the encoder measurement noise)
anti-windup: [-3.5, 3.5]
control loop rate: 10 Hz
queue_size = 1 (this could be increased)

It was really hard to find some good values and even now it is not ideal because the dc motors DG01D-E are a non-linear system. Especially at low speeds it can happen that one motor starts rotating slightly before the other and then stops again after it has overcome the internal gear friction because it's spinning too fast due to the initially required "high" voltage.

Anyway, the robot drives more or less straight now when the motors operate at a steady state. Still there are some options that can probably improve the behaviour:

• Vary the control loop rate: Linorobot uses 20Hz, 10Hz works as shown in the video but 100 Hz seem too much. It is not exactly clear how to find the limiting factor.
• Implement a low level PID on the Teensy 3.2 or Teensy 4.0 to operate the motor driver board Grove i2c motor driver v1.3. There exists already a library for Arduino. And avoid using the current python motor_driver.py node.
• Remove delay() after the nh.spinOnce() in Arduino/Teensy code (although this lead to errors, see the code in the link)
• make use of odometry calibration using the gain/trim model. This would probably require implementing a new ROS-Control controller instead of the diff_drive_controller which provides only open loop control and therefore requires the speed PID controller.
  
• Try other controllers and use a more detailed model including the motor:

• Use a LQR instead of a simple PID
• "Go to angle" controller

Or try some other differential drive ros packages instead of ROS control, although I would prefer to keep using ROS Control.

• diff_drive
• differential-drive seems outdated, see wiki, although it might still work.

The currently found gain parameters seem to work ok but I need to do some more testing, like trying to map a real enviornment with the RPLidar and gmapping. Depending on how this works, I will try some of the methods mentioned above. Although I would like to implement the low level PID on the Teensy anyway, just for comparison with the high level PID.

Regarding rosserial I have also another question (might be suited for another issue): I have read something about adapting the ros.h and NodeHandle for the Arduino when using rosserial in the wiki here (changing buffer and publishers/subscribers). I am wondering if this will be required for the teensy or if it could already improve the current behaviour and which values should be adapted.

Please let me know if you have some other ideas to improve the driving behaviour or find some bugs in the DiffBot code or anything else that could need adjustments. Any suggestions or discussions are more than welcome. Thank you.

[fjp]

Maybe one approach to having a more realistic model would be doing these tests with the robot on the floor, because, then you have the load of the robot weight and the behavior would be closer to the "real behavior".

Yes this would be helpful. As in the video I did some tests on the ground but next time I will use a tape to make a straight line of 2 meter and record the final offset.

I didn't get it but, is it possible to have different PID values for the wheel? Because, as you said, if the motor is behaving differently, probably they need different parameters.

It is a dynamic error that will vary with speed. I would apply a different pid for each wheel.

Yes right, there are two PID controllers, one for each wheel. It is just not that easy to find good values. But I think doing more tests on the floor will be helpful to tune them individually.

The error is causing it that the motor reduction does not rotate symmetrically. When I have run into these errors, in almost all diffbots, I adjust to the slowest wheel. In your case the left wheel.It starts to turn at 45%, calculates the speed and you give it the value that corresponds to the right motor, maybe 37%, is an example. At low speeds it usually works quite well.

This might work as well. I previously started with a simple approach (adding an offset to the left wheel) but it seems to me that this requires a lot of code to get good behavior for different speeds and also requires different cases for accelerating and decelerating. Do you have some references or examples where this is implemented?

Seeing the platform you have in amazon. Can you turn one of the motors and connect the wheel where the encoder goes? If they rotate on the same axis,and the same speed, that way connecting a motor in an inverted way to the driver eliminates the difference in reduction.

Good point. Having the encoder directly where the wheel is attached ("after the gear reduction") would be better I guess. Unfortunately, with the motors I am using (Hobby Motor with Encoder - Metal Gear (DG01D-E)) it is not really possible to change the location of the encoder because it is directly attached to the rotor shaft of the motor. I just opened one of them:

So far I didn't find motors with a quadrature encoder that can be installed on the bottom of the chassis and leave enough space for the battery pack (which is currently located at the bottom). And adding separate quadrature encoders will also be hard because the battery pack leaves too little space. I might need some new part placement or use a double-decker chassis.

Also, I just made a voltage sweep test (slowly increasing the voltage) with six of these motors (all that I have) and only one (the one that was installed on the right of DiffBot) starts already to spin at 2.5 V, sometimes even 2.4 V. Another one starts to rotate between 2.6 V and 3.0 V (although this one varies a lot). All others require more than 3.0 V to start rotating, as specified in the datasheet:

So I will start using a pair of motors that start spinning at roughly the same voltage level.

[fjp]

The following video shows the results of driving straight on a 2m test track:

Keeping in mind the used hardware, the resulting accuracy of the different test runs seems to be ok. As noted in other comments of this issue the different offsets can be caused by:

• Orientation of the start pose
• Inaccurate motors start to spin at different voltage levels
• Low encoder resolution (geared output resolution at wheel)
• Wheel slip or alignment of the left/right and caster wheel
• Weight distribution
• Not tuning the individual PID controllers for each motor

[altineller]

Hello fjp,

I saw your post on duckietown stackoverflow, and decided to respond here. I have implemented a circuit, that drives two motors, in a duckietown like configuration. Except I am using n20 encoder motors, and the chassis is 3d printed. (https://gitlab.com/ROSRider/rosrider)

Here is my experience: even if the PID is implemented perfectly, for a robot of that scale, and for motors of that non-linearity, it is not possible to make the robot drive straight, without external correction. Also PID makes it slower to respond, and this is a problem when turning, etc. The deadzones of the motors you are using are 30-40%, which is horrible. There are also wheel slip factors, etc. Not only that the deadzones are horrible, the motors will turn at different speeds when same voltage/current is applied. Yes, PID corrects those, but it can only correct so much.

In your PID code you also have to implement the case when the motor changes direction, like full forward to full reverse.

Best Regards, and good luck on your work.

[fjp]

Thank you @altineller for sharing your valuable experience. Yes, the motors are not easy to handle. I soon want try running the PID software more low level on the microcontroller (similar to Linorobot), instead of in the ROS control hardware interface, to see if this improves the behaviour. But I also think switching to other motors/encoders would be easier.

The ROSRider board you have is very interesting. What dimensions does the board have and when will it be ready? Because we are working on a 3d printed chassis as well and I might try to fit this board at the bottom of the upcoming chassis #26.

Thanks, also good luck on your projects.
Best regards,
Franz

[altineller]

Helllo,

If you move the PID to the micro-controller, it will have some advantages, mainly around latency. I have done both ways, and although the PID running at a lower latency improves performance, it is not enough to compensate for the non-linearity of the motors. I have done first PID on the micro-controller, then decided the advantages were not so great, and decided to run ROS's PID package on the host computer instead of the micro-controller, in favor of configurability.

The problem is the non-linearity of the motors, and I am still working on this problem. I am thinking of something in form of this: besides PID have a mechanism to increase PWM, or even just send 1 to enable line, until the motor is in motion, then PID takes over.

Another solution could be mechanical. Greasing the gears with high quality teflon grease spray that they use in model cars and helicopters has worked great for me.

The ROSRider board is 76mm x 80mm. I am trying to get it manufactured in the 100s. But I can ship singular quantities, that I build at home for now.

Best Regards,
Can