RotateMotorPID simultaneously: 3 motors, 3 different targets

[HaWe]

thank you for your reply!

I tried 32, 64, 96 now for p,i,d.

the positioning error of RotateMotorPID is still too big, and the behaviour after manual corrections is unpredictable...

I have to use MotorRotationCount, I must be able to make intermediate manual corrections, and I don't want to have to handle different counters additionally.

Has anybody written an own pid controller which works more precisely and more predictable?

[afanofosc]

I do not understand why you think you have to use MotorRotationCount instead of MotorTachoCount. Have you even tried just replacing any reference to MotorRotationCount with MotorTachoCount to see what happens? Or even just comparing the two values to see if they differ in a way that might explain the behavior you are seeing when you make manual corrections?

John Hansen

[HaWe]

ok, persuaded, I'll try it tomorrow replacing one by the other...!

edit:
though it would be nice to have a functon about which I actually know how it works!

[HaWe]

I tried this exchanging all "MotorRotation*" by "MotorTacho*" but it would have turned over almost all joints within a handful of seconds approaching completely wrong targets.
It has been doing that in such a short time that I could only prevent my robot being completely distroyed by immediately pushing the "EmergencyStop" button and so I had no time to observe any values shown on the display.

No, I honestly I have no time to debug any incapsulated firmware malfunctions, it simply has to work as it should (probably it's made for children's toy applications and even good enough for that, but not for advanced requirements).

I'll drop that RotateMotorPID project .

I think it's better to open a new thread about customized PID regulation, maybe we can make it better by ourselves than messing around with those Lego firmware (mal-)functions.

[afanofosc]

Doc,

If you do something blindly then more than likely you will run into things that hurt you. Why not do what I asked and output the value of MotorTachoCount to the LCD and compare it to MotorRotationCount so that you understand the value that the firmware is using internally whenever you tell it to rotate to a specific tachometer limit.

Also, you could fairly easily write a modified version of the RotateMotor function that ramps up and ramps down that might more fully suit your needs. Something like what I wrote the other day in just a few minutes:

ex_ramping.nxc

(3.77 KiB) Downloaded 212 times

John Hansen

[HaWe]

I don't want to dig into the tachocount and rotationcount materia: it's far too opaque and obscured what could happen or might happen or should happen and actually doesn't happen. Also the IOmaps are a book with seven seals to me (that's why I never use e.g., SetOutput). I'm using only RotationCount, that's fine to me. Trying an advanced firmware function (RotateMotorPID) was a try, but it shows again: the firmware is made for a small part of applications under certain preconditions, but if something non-scheduled is happening (intermediate manual (un-)adjustment) then the function falls out of kilter. So I actually expect the firmware only to do simple things (and then to do them correctly and predictable under all circumstances), and anything advanced can be done by advanced functions written down in C header files.

Ramping is highly problematic because the torque at the end is often extremly strong, I need almost all the motor power even at the end to approach the target (although there is a high risk for overshooting) - but otherwise the motor will have too little power in a closer spacing to the target, it will have not enough power for the last several degrees to turn and so will die a wretched death shortly before the finish.

Having a nice and understandable C code is much more my work area. Having such a clearly adjustable and transparent working C-coded PID controller which will oscillate at the end and will adjust it's own power up or down and forward or back by closer and even closer approximation should do it better than the stuff which has been programmed by Lego toy programmers.

[linusa]

Has anybody written an own pid controller which works more precisely and more predictable?

It's actually a PD controller, but it could easily be extended to PID. It's precise and works with 3 motors and different targets simultaneously. Interfaces have been adapted by other developers for Python, .net and for Mathematica. Thousands of students around the world (literally!) have been using the program in their university courses, so it's considered stable. http://www.mindstorms.rwth-aachen.de/tr ... torControl
To repeat the features here:

• Precise motor movements to any position (accurate to ± 1 degree in 90% of the time)
• Smooth braking / soft stop
• Anti-stall-protection (motor doesn't get stuck during deceleration)
• Smooth acceleration (soft start) optional
• Synchronized driving (for two-wheeled driving robots) supported
• Controls all three motors independently
• Movements/commands can be cancelled at all times
• Motors and sensors can be monitored at all times (as usual)
• End of movement can be detected

The program can be used from within NXC, too. Sourcecode is licensed under the GPLv3 and available here: http://www.mindstorms.rwth-aachen.de/tr ... torControl

If you need to strip down code size or need help, just ask.

I don't want to dig into the tachocount and rotationcount materia: it's far too opaque and obscured what could happen or might happen or should happen and actually doesn't happen. Also the IOmaps are a book with seven seals to me (that's why I never use e.g., SetOutput).
...
I'm using only RotationCount, that's fine to me.

SetOutput is a convenient wrapper for IOMaps, and it's not too low level (I personally don't like writing to IOMaps manually, too). It can be learned, it's very powerful, and it's simple and easy. I can really really recommend SetOutput, as it operates the motors on the firmware level, so you don't have too much abstraction. Here's an NXC file which demonstrate the use and provides some helper functions: http://www.mindstorms.rwth-aachen.de/tr ... ctions.nxc


The 3 counters of the NXT work as follows:

TachoCount is used in conjunction with TachoLimit. The TachoCount will run towards the TachoLimit, when you've set the limit. It also keeps track of the movement and detects "errors". If you move a motor by hand, but don't reset the TachoCount, the next movement with a TachoLimit will correct and reverse the movement you did by hand.

RotationCount: This has absolutely no side effects, use it at free will, reset whenever you want.

BlockTachoCount is used for synchronized driving. The firmware keeps track of the difference between two motors with this, it seems. It's best to reset this counter before each new movement with synced driving.

[HaWe]

If you move a motor by hand, but don't reset the TachoCount, the next movement with a TachoLimit will correct and reverse the movement you did by hand.

thx for this explanation! As I described before, I observed this "malcorrection"-behavior also when using "MotorRotationCount" together with RotateMotorPID().
So RotateMotorPID must call (or refer to) MotorTachoCount internally, otherwise it wouldn't misconduct due to manual corrections.

But because of this RotateMotorPID malfunction I can't use RotateMotorPID at all.

I agree that SetOutput might be powerful, but it's bad not to have any C code if one wants to transport NXC code to any other C platform (what's actually my intention). A standard C header file (e.g. like "motors.h" for all higher level functions) would be much more better, because it's simply portable to any other platform by #include. This is why I like to work with C code: the "core" is a world-wide standard, and all additional features are accessable by header files and just have to be added or to be exchanged according to the specific hardware platform (like hardware-specific "stdio.h").
Also I always like to read the code I am working with, I don't like "obscured black boxes".

Thank you also for your links. But could you please copy and paste the "pure" source code of all functions? It's better to read them here when having any questions.

But actually better use not this thread for a reply but the other one which is about "custom PID controller",
this thread here is about RotateMotorPID which don't work correctly.

[linusa]

If you move a motor by hand, but don't reset the TachoCount, the next movement with a TachoLimit will correct and reverse the movement you did by hand.

thx for this explanation! As I described before, I observed this "malcorrection"-behavior also when using "MotorRotationCount" together with RotateMotorPID().
So RotateMotorPID must call (or refer to) MotorTachoCount internally, otherwise it wouldn't misconduct due to manual corrections.

But because of this RotateMotorPID malfunction I can't use RotateMotorPID at all.

It's not specific to RotateMotorPID, it's how the firmware handles the "drive to a certain tacholimit" feature. I've been posting a link with my explanation of this "auto correction" in several mindstorms forums for years, btw.: http://www.mindstorms.rwth-aachen.de/do ... ing.html#7

Anyway, the workaround is simple: Reset TachoCount to 0 before each new movement, and the error correction is disabled. You can ALWAYS emulate your own counter by reading TachoCount before the reset and keeping track of it on your own, or by using the counter RotationCount (which is free of side effects).

Thank you also for your links. But could you please copy and paste the "pure" source code of all functions? It's better to read them here when having any questions.

No. If you want to paste code here, do so. You can do an anonymous SVN checkout on all the files, use this URL: http://www.mindstorms.rwth-aachen.de/subversion/trunk/tools/MotorControl/ . You can also use that URL to do raw browsing.

For syntax highlighted browsing, use: http://www.mindstorms.rwth-aachen.de/tr ... torControl

To get all files in a zip, download the toolbox http://www.mindstorms.rwth-aachen.de/do ... Tv4.06.zip and go to the MotorControl subfolder.

[HaWe]

No.(...)You can do an anonymous SVN checkout on all the files, use this URL: http://www.mindstorms.rwth-aachen.de/su ... orControl/ . You can also use that URL to do raw browsing.

In the "custom PID control" thread I needed only the PID controller code, not the whole chunk of motor control code, a link to the whole RWTH library is not very helpful. But this thread isn't about that anyway.

You can ALWAYS emulate your own counter...(or) by using the counter RotationCount (which is free of side effects).

no, it's not free of side effects (as I described before): I only was using RotationCount but also had issues with memory effects of RotateMotorPID!

(the RotateMotorPID function has been dropped meanwhile - I won't use it any longer.)