EV3 motor regulation troubles

This is where you talk about the EV3 software itself, installation issues, and programming talk.

Moderators: roger, gloomyandy, skoehler

Re: EV3 motor regulation troubles

Postby cgapeart » Mon Dec 30, 2013 1:06 am

I have run into this same problem, while writing a lejos based codebase for the ev3 plott3r bonus model. After much thought, and code inspection, and digging into my engineering controls text books, I think I know what the issue is.

PID loops need to be tuned for the process they are controlling. The ev3classes library is using the NXT regulated motor class, and there is two sets of PID parameters, one for holding a position, and one for regular movement. The code shows that authors have gone through and tweaked the values a number of times, but the root cause of the problem here is that there is no one set of numbers that will work for all robots: You might be able to get a decent starting point, but really, if PID control is going to be used it has to be adjusted for the specific motor in the specific robot -- i.e. a large ev3 motor driving a wheel for a large robot will need very different parameters than a medium ev3 motor directly driving a lightweight arm.

There are literally thousands of papers on tuning PID parameters, but there are some straightforward rules to get a good starting point, and this is something that should probably be run for every motor on every robot if PID control is to be used.

First, the I and D parameters should be set to 0. Then, adjust the P parameter until the step response is reasonable without too much overshoot. If you measure the time it takes for the motor to reach the desired speed (or position), that becomes a feed into the I parameter: in general, you increase I to get rid of offset (P control will always settle on a value that is not quite the set point, until you add in I). Finally, the D parameter can be tweaked to balance acceleration against how much overshoot is used.

(check out the PID article on wikipedia for a reasonable overview of PID control and tuning. - http://en.wikipedia.org/wiki/PID_controller)

So, the long story short, the issue is that it is impossible to have a PID controller class with fixed PID values as written that will work properly for every motor and every robot. The base set up will work for some motors and robots well, and on others, there will be overshoot and other problems. I don't think that this is really a race condition for the most part: overshoot and oscillation are typical for a poorly tuned PID control loop. Certainly starving the PID control loop from updating often enough will cause a problem, but really there is plenty of power on this controller even running java for the threads to run. In the NXTRegulatedMotor class, The control loop thread is set at the highest priority, so it will tend to run properly unless the entire processor is at 100% cpu usage.

I don't know enough about how lejos works... yet. It looks like there is a decent reusable structure there, and I would like to figure out how easily I can write different regulation module, while using the same basic regulated motor interface. At the very least, I would like to make the PID values adjustable. Taking the next step, it would be possible to build in a self-tuning mechanism that could be used on a robot to adjust it's own parameters, and allow other types of regulation to replace the PID control. I believe that for the plott3r robot, for example, PID control is probably overkill: there isn't much inertia or load in the system, and so a simple power + tach count check should be enough to drive it at a reproducible speed.

Those are my 2 cents on the issue. I will post back if I come up with anything useful, but comments would be welcome.
cgapeart
New User
 
Posts: 3
Joined: Sun Dec 29, 2013 4:26 am

Re: EV3 motor regulation troubles

Postby gloomyandy » Mon Dec 30, 2013 6:00 am

Having spent many, many hours on this code over the years I wish you luck. Let us know how you get on. The environment and motors used in the EV3 are far from the perfect ones that much of the PID theory describes. Threads do no run at predictable times (particularly during the jitting process, try it and see, the actual times say a 5mS scheduled thread runs can vary by over 100mS at times), the motors have both stiction and backlash and have a relatively crude tachometer, add in that you often need them to run well and be controlled over a wide range of speeds including at or near maximum, and minimum speeds and you have a very nasty often non linear control problem. Oh and the Lego kernel modules have a number of race conditions in them that the current code takes steps to avoid. I'm not saying that you what you are trying to do is not possible, but I suspect that it will be harder than you think, particularly to produce a general solution. Modifying the code to use adjustable PID values is trivial so that part should be easy. Good luck with the rest...

I'm actually working on this code at the moment in an attempt to fix some of the more obvious issues on the EV3, so I look forward to seeing your results. I would recommend that you test your solution using the new medium motor as that has some particularly nasty characteristics (the large motors are by comparison well behaved). Having the motor hold position when subject to various impulse loads, and running it at low speeds seem to be easily testable problem areas.

Good luck

Andy
User avatar
gloomyandy
leJOS Team Member
 
Posts: 4174
Joined: Fri Sep 28, 2007 2:06 pm
Location: UK

Re: EV3 motor regulation troubles

Postby cgapeart » Mon Dec 30, 2013 6:02 pm

Andy, thanks for the reply there...

That is why I didn't want to rush in too quickly. I suspected that many hours had been spent and I didn't want to repeat experiments.

That being said, I still think that it is going to be impossible to find one set of PID parameters that is going to work for all motor types in all robots. However, from the point of view of developing a library set that can be shared and used quickly by a large number of users at different skill levels, clearly a starting point that doesn't require the user to know control theory is needed.

I don't want to sound too critical here: I have a lot of respect for the lejos project - I have only been looking at it for about a week now during the holidays, and I am impressed by what I see.

So far I haven't come up with a way to use the existing framework and tweak the behaviour without making a duplicate of the NXTRegulatedMotor class and editing in place. Perhaps I am trying to hard... Can I just create a TachoMotor object assigned to the port and use that directly from my program's main and related classes? I suppose what I am really asking is whether or not the lejos system is set up so that the ports are exclusively claimed as part of the class library and hardware stuff, or is that something that only happens if the class is explicitly pulled in? It looks like there is a lot of stuff in static initializers, and it has been a long time since I worked with Java and I am not sure I have the rules in mind straight about how java handles class static initializers. My best guess at the moment is that I can use the tacho motor directly, as long as I use it for all my motors and I don't use the lejos.robotics.Motor class (which would initialize all 4 motor ports during static initialization). However, that would only matter if the physical ports are exclusively claimed?
cgapeart
New User
 
Posts: 3
Joined: Sun Dec 29, 2013 4:26 am

Re: EV3 motor regulation troubles

Postby gloomyandy » Mon Dec 30, 2013 6:42 pm

Hi,
For any long term solution you may want to wait until I check in my reworking of the motor control side of things. This makes it much easier to deal with different sizes and types of motors while sharing a core regulator. However all of this is very new and will be a week or so before it is complete. This code will also move the main regulation loop out of Java and into a kernel module. I don't think there is any way to obtain required accuracy n timing while using Java for this code, at least not in a general way.

You can write your own regulation code even if you are using the leJOS regulated motors, you can even mix them on the same port if you want. You basically have two choices.
1. Do not reference the Motor class at all (which will prevent the creation of four motors associated with each port), this class is really there for backwards compatibility and should not be used by new code. Instead just create instance of NXTRegulatedMotor on the ports you want to use those on.
2. If you do reference Motor, or you want to use the leJOS class on the same port as your own motor control code simply call the suspendRegulation() method in the NXTRegulatedMotor instance associated with the port. This will stop the leJOS code from using the port.

You should then be able to create your own code either based on the leJOS regulator or otherwise to control the attached motor.

As I said good luck, and let us know how you get on.

Andy
User avatar
gloomyandy
leJOS Team Member
 
Posts: 4174
Joined: Fri Sep 28, 2007 2:06 pm
Location: UK

Re: EV3 motor regulation troubles

Postby cgapeart » Mon Dec 30, 2013 8:35 pm

I like the path you are taking, and I will wait for the new code before I go too far.

If you want help testing it, I would be happy to give it a shot. The plott3r robot makes nice graphs that can be used for tuning: If I turn on the paper drive at a constant rate and let that settle out, and then send commands to the other axis, I get a nice plot of what's going on. I will send you a PM with my email address - contact me if you are interested.

--Colin
cgapeart
New User
 
Posts: 3
Joined: Sun Dec 29, 2013 4:26 am

Previous

Return to EV3 Software

Who is online

Users browsing this forum: No registered users and 2 guests

more stuff