3% to 7.5% error in ME encoder feedback control

#1

I tested the feedback control with :

  _RMotor.setPulsePos(9);_
  LMotor.setPulsePos(9);

  RMotor.setRatio(39.267);
  LMotor.setRatio(39.267);

  //  RMotor.setPosPid(1.8, 0, 1.2); // set PID_pos. P I D
  //  LMotor.setPosPid(1.8, 0, 1.2);
  //  RMotor.setSpeedPid(0.18, 0, 0); // set
  //  LMotor.setSpeedPid(0.18, 0, 0);

  RMotor.setPosPid(1.8, 0, 1.2); // set PID_pos. P I D
  LMotor.setPosPid(1.8, 0, 1.2);
  RMotor.setSpeedPid(0.18, 0, 0); // set
  LMotor.setSpeedPid(0.18, 0, 0);

 RMotor.setMotionMode(PID_MODE);
 LMotor.setMotionMode(PID_MODE);

in loop()

RMotor.move(target, pwr / 100.0 * 255.0);
do {
  RMotor.loop();
}  while ( !RMotor.isTarPosReached());

Results:

junk

Any suggestion. I guess I can generate a trend line and insert some adjustment, but it will really be a hack.

I read thru other posts regarding issues on the encoders calculation, not much that I can find. Besides, many posts seem to be just closed without a solution…

#2

more info:

  • I use 6 AA envelope rechargeable batteries.
  • during test, I had the robot raised from a platform, removed the tread to allow a free-load run.
  • well I have it connected to my computer at all times during testing.
  • in-between each measurement, I make sure the motor came to a full stop.
  • reset encoder RMotor.setPulsePos(0);
#3

What you call a hack basically is calibration and control and what you did (with that table and the errors) is some sort of sensitivity analysis. There are some very nice mathematical solutions to tackle this issue. If you are really interested you should look into control engineering.

I see you are using PID control. I’m not familiar with this “standard” PID. Did you write it yourself or take it from somewhere? Because this is where part of the solution could be.

I don’t have a ME encoder so can’t help you with a quick solution. But the behaviour you are seeing is expected of a “cheap” and simple module like this.

Sorry not sorry with this non solution answer

Good Luck!

#4

To Makeblock support:

  • if you may provide some documentation on your motor PID controller with some explanation, or even analysis data, it will be really beneficial for those who attempt to modify your controller in order to increase the accuracy.
  • to be able to to modify your PID controller will be far better than having others to add on more adjustment on top of it.

To Atonbom:
While my background is not in ME, I tried to educate myself in creating PID. Thus with only minimal understanding what and the requirement in creating PID controller, my PID controller experience has been mostly for line tracking with color sensor, and wall tracking with time of flight.

Makeblock has already had PID controller for the their encoder motor implemented in their library. The controller I mentioned in my post earlier is provided by makeblock for its own blockly environment for the exactly the same Ranger physical configuration. I call my analysis work a hack because Makeblock’s own implementation should have taken care of the proper adjustment for exactly the same configuration for it is sold for - the Ranger. Especially when it targets students in middle schools, or anyone who prefers your blockly environment.

I understand that we cannot expect too much from these low cost motors… Nevertheless, the ranger bot does cost US$150. I do not expect perfect, but having almost 4-5% error for simple one rotation is a bit too much even for blockly users. This is why I called my further analysis getting the trend line, etc., a hack solution. Not saying that the analysis itself is a hack. The ultimate solution is to add in ability to modify their existing controller, if possible.

#5

You make some good points and indeed some additional information/documentation would be nice. But even then there will never be a perfect solution that works for everyone in this case. Things like this are mostly hardware related and due to relatively cheap parts (in this case the dc motor with encoder) the variance among these devices is/could be big. The error you found seems quite linear and the best thing to do is calibrate for that. This is not a hack this is just the way it works. Yes the PID controller can always be configured better but if you have a consistent error you should just correct/calibrate for that

You will also notice when batteries run low that everything will be off. Have you btw tested with normal batteries? Rechargeable batteries tend to have less power compared to “normal” ones, maybe you will see some results.

To give a personal example of an issue like this: In one of my classes we had to program a Boe-Bot. And even when everyone was running the same code with a fresh set of batteries all the bots would behave a little different. It’s annoying and frustrating I know but this is where theory and reality meet. (Cheap) Robotics issues are in my experience 75% hardware related and the other 25% is software and science.

Also what kind of encoder motors does you Ranger have? magnetic or optical? At what speed are you testing right now? Higher speeds tend to have a larger error because the encoder can’t keep up, this is especially the case with optical encoders. Easy explanation: the encoder wheel has 12 holes for instance and the IR sensor(often it’s IR or other type of light sensor) measure every 2ms but the motor is so fast that it passes the sensor every 1,75ms. And well… It’s obvious that the sensor will miss some “holes” and measures less than expected. And here I fully agree with you if something like this is the case it would be nice if it’s documented somewhere.
My teacher let us figure this out on our own at Uni and it took us the entire afternoon… Well it’s definetley something I will never forget.

#6

To Makeblock support:

  • it will also be helpful if I can get the current or voltage levels so that it can allow users to insert enhanced PID controller, as Makeblock PID controller does not do it. That can definitely be the cause of the big error margin.

The error margin unfortunately is not linear, it ranges from 7.5% (with .5 rotation) to 2.5% (with 256 rotations). Again, user can work on to enhance your PID… but without access to the motor current or battery voltage, the solution will never be a robust one. If your current motor driver cannot give you such information, I truly think MB needs to come up with an alternative to give users a choice the alternative to buy; especially for someone who are looking to migrate off from LEGO Mindstorms. Their motor PID controller produces much more robust result as it takes the motor current into consideration.

To AntonBom -
yea… we are ultimately inline with the same ideas in technical aspect.

Again, I use the word “hack” in the context of “measurement taken right out of the default Ranger bot which Makeblock advertised”.

Take the LEGO Mindstorms motor and their firmware as a comparison; as MakeBlock sells it Ranger targeting the similar age group. The mindstorms PID Controller works quite nicely - with negligible error margin. Now, with this Ranger, I am just testing it with exact build right out of the box - even without load. If the product is targeted for the younger crowd ( I mean age 10 -13), the PID controller will need to be more accurate with the basic robot configuration “given to customers”.

Now, of course, if one changes the configuration (the robot), that’s when we should expect more variance. That’s when the lesson of learning PID controller comes in. But, the current error margin is from exact the same build out of what they advertise simply should only be about 1%. Why? It is because Makeblock should have at least tested their PID Controller with the basic build - the Ranger and should have been targeted with smaller error margin.

Now, if it is the battery running low, the makeblock library should have encountered for that too. Looking at their codes, it does not look like they do. That’s probably the reason why it is off so much! They should fix it.

#7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.