Absolute position reglation in firmware

[schodet]

Hello,

I finally made progress to my new regulation method for the LEGO firmware.

This new algorithm controls one motor so that its position matches the position set by the user. At any time, even when the motor is moving, the set position can be changed, and the control algorithm will move the motor towards the new position.

Compared to original speed regulation, absolute position regulation offers the following advantages:

* position consign can be changed at any time,
* target position is held automatically,
* motor can slow down before the target position is reached,
* can be used remotely with precise movements,
* smooth transition between acceleration, full speed and deceleration,
* regulated synchronized mode.

I made a page documenting the change here, with a short tutorial, examples and the NXC API.

I made a binary (version 1.29i-813df11) so that you can test it. If you want to see what changed in firmware code, you can see change logs on gitweb or clone the git repository. The change is on a wip branch in my repository, but I will push it to the master branch in the following days if no grave regression or API problem is found.

Nicolas.

[mattallen37]

Cool, sounds like EXACTLY what I have been wanting. I really hope this gets implemented into NXC.

Edit: I just flashed one of my NXT's with the FW, and used the "posreg.h" file, and it works SUPER well. Thanks SO much. John, please add this to the official NXC stuff.
BTW, is the FW based off of the original FW? or is it based off of a FW enhanced by John? Never-mind, the answer is no.

[mattallen37]

You posted the following:

"TODO: document how to wait for a movement to be finished."

How about a function that returns how far from the target the motor is? If it returns a zero, then it is at its target. I think it would be the same as comparing the "MotorTachoCount" to the last requested position.

[h-g-t]

Looks interesting but does it follow the same controlled pattern when slowing down? I mean a movement analogous to the NXT-G ramp up-ramp down sequence?

Forgive my lack of comprehension but I am confused by your graph, since all examples seem to end up at the same speed, even when the speed is being limited.

[spillerrec]

The vertical axis the the current position of the motor and the horizontal axis is the time in seconds. So you will need to guess the speed by looking at how far it has moved in relation to the time.

[h-g-t]

I see, thanks.

[HaWe]

Hello,
I finally made progress to my new regulation method for the LEGO firmware.
This new algorithm controls one motor so that its position matches the position set by the user. At any time, even when the motor is moving, the set position can be changed, and the control algorithm will move the motor towards the new position.

Great idea! I appreciate this very much! (I actually posted this to the wishlist to NXC already more than 1 year ago!)

[schodet]

Cool, sounds like EXACTLY what I have been wanting. I really hope this gets implemented into NXC.
Edit: I just flashed one of my NXT's with the FW, and used the "posreg.h" file, and it works SUPER well. Thanks SO much. John, please add this to the official NXC stuff.
BTW, is the FW based off of the original FW? or is it based off of a FW enhanced by John? Never-mind, the answer is no.

Nice you liked it

This is based on the original FW, but I am slowly merging enhanced FW feature as needed.

"TODO: document how to wait for a movement to be finished."
How about a function that returns how far from the target the motor is? If it returns a zero, then it is at its target. I think it would be the same as comparing the "MotorTachoCount" to the last requested position.

This can be done, but it is not always sufficient. The motor can be off by one or two degree depending on how well your PID coefficients are tuned.

[schodet]

Looks interesting but does it follow the same controlled pattern when slowing down? I mean a movement analogous to the NXT-G ramp up-ramp down sequence?
Forgive my lack of comprehension but I am confused by your graph, since all examples seem to end up at the same speed, even when the speed is being limited.

The vertical axis the the current position of the motor and the horizontal axis is the time in seconds. So you will need to guess the speed by looking at how far it has moved in relation to the time.

Exactly, on the graph you can see the slowing down when the position approaches the target position.

[mattallen37]

Nice you liked it

This is based on the original FW, but I am slowly merging enhanced FW feature as needed.

That is good, but wouldn't it be better for John to add your single function to his tried and proven FW, than for you to add his countless modifications to your single one? I need RS-485 support, as well as the math (bitwise operators, sin, and cosin), among other things.

This can be done, but it is not always sufficient. The motor can be off by one or two degree depending on how well your PID coefficients are tuned.

Well, I understand, but if it must be EXACTLY on the position, what difference will there be in making another function? I would just use a range to find out if it is at the right place. Something like the following:

Code: Select all

if(  MotorTachoCount (OUT_A)>=(TargetPosition-Threshold)  &&  MotorTachoCount (OUT_A)<=(TargetPosition+Threshold)  )

It will check the position compared to the target position, + or - the threshold. Basically, if the target was 180, and the threshold was 5, the "if" statement would be true if the MotorTachoCount was in the range of 175-185.