Output module: counters, rotations, overshooting...

[mrblp]

Hello all,

I did not use my NXT for a while now but since 2012 I thought it would be a nice thing to do it again. So I started with a very simple task: Motor rotation. Well - it is not really easy.

Good news: Simply running motors endless works with NXT-G and nxc as I expect it: regulated, synchronised or just powering.

But to rotate the motor for an angle is a bit tricky. In NXT-G there are a lot of modes which are working. But a overshooting rotation results in a shorted next rotation. Even when the program is stopped and started again! The brick has to be switched off to reset the rotation measurement system.

And that is not only resetting the counter values. I did look in the firmware code and it is really funny at this point. I did not get the structure - which values are reset when? I am not even shure about the software engineers knowing that...

OK, in nxc I had a lot trouble. First point there is no (direct) command to let a motor rotate regulated to a specified position. I used SetOutput to get to this and it works - mostley.

Specially I do not understand again when the counters will be reset. I used "Coast" and "Yield" to get the motor modules inclusive the counters reset. This does not work for the "RotateMotor" command which I do not understand again.

First: Does anyone here really understand the output module? Could you please help me understanding the philosophy of the counter resetting system?

Second: Is the firmware module output reliable? Or should we take another look to it - I now someone already did that...

Thank you for your answers.

Bye,
banty

[h-g-t]

In NXC I use - ResetRotationCount(OUT_B); which zeroes the counter ready for the next movement.

The movement of the motors is continually tracked so that if it overshoots slightly on one movement it will try to correct it on the next.

One problem which caught me out is that any uncontrolled movements, such as turning the motor by hand, or rotation of the wheels when a vehicle rolls on after the motor is set to coast are also tracked! If you want to minimise such movements you should use brake.

This means that the NXT will correct any such movements before carrying out the next programmed move.

My programs reset the rotation counter before any movements to try and keep it acting the way I want.

To get the motor a specific angle just use - RotateMotor(OUT_A, 75, 45); which moves the motor attached to Port A forward 45 degrees at 75% power. To change the direction use -45.

[mrblp]

Hello,

In NXC I use - ResetRotationCount(OUT_B); which zeroes the counter ready for the next movement.

Thank you very much! This helped me

I thought this counter counts the wheel rotations. But reading the documentation exactly my mind: "Resets program-relative position counter.". This one should be reset at every start of a program - as NXT-G is doing this. And starting any motor action should call ResetBlockTachoCount().

I thought the main counter for regulation and controlling the movement is TachoCount. In the LEGO documentation this one is described as "Resets internal movement counters, cancels current goal, and resets internal error-correction system." But it seems only to influence the regulation while running.

To get the motor a specific angle just use - RotateMotor(OUT_A, 75, 45); which moves the motor attached to Port A forward 45 degrees at 75% power. To change the direction use -45.

You are right. What I mean is this one is not regulated as OnFwdReg(OUT_BC, 70, OUT_REGMODE_SPEED); is. I made a macro with the SetOutput()-command to achieve this. In this context I played a lot with all those motor commands and came to the problems I described above...

Bye,
banty

[afanofosc]

RotateMotor does use regulation but it uses the sync regulation mode rather than the speed regulation mode. That is so that two motors can be synchronized. I can change the API to use the speed regulation mode if you only use a single motor and sync mode if you use multiple motors. You can't use both modes at the same time.

John Hansen

[afanofosc]

The enhanced firmware supports a new position regulation mode designed by Nicolas Schodet. Have you looked into this mode?

John Hansen

[mrblp]

Hello John

Thank you for your reply. It would be a great idea to make it sync regulated with two motors and speed regulated with one motor. Not sure if this breaks some existing programs. And I am wondering I am the first person missing this mode?

And - no, I still did not try Nicolas new motor positioning code. I did not update my version of the firmware yet - but I am really glad you put the firmware source code in the repository

I will give it a try and I will tell you.

Bye banty

[mrblp]

Hello there,

Some time later, a lot of tries to get the ... motor module run as I want to.

Well, I can concentrate to one special case that does not work: The OUT_OPTIONS_RAMPDOWNTOLIMIT thing does not work. And I found out that this one is not a feature of the standard firmware. So it is added in the enhanced firmware... It is not declared as enhancement in the doxygen help.

Shame on me I still did not try the v1.31 enhanced firmware. So it may work as intended with that one. Previous versions do not work. The OUT_OPTIONS_RAMPDOWNTOLIMIT option manipulates the internal rotation counters in a way you cannot reset anymore. The behaviour of the output module will be a bit unpredictable after using this option. The only way I found is to switch of the NXT. Just stopping the program and restarting does not help.

Next steps:
- I will ignore the OutOptionsField. Let us see if I get all the functions run for the "OUT_REGULATION_SPEED" mode.
- I will give the v1.31 a try when I got the other part to work.

Bye - marvin

[mcsummation]

Well, I can concentrate to one special case that does not work: The OUT_OPTIONS_RAMPDOWNTOLIMIT thing does not work. And I found out that this one is not a feature of the standard firmware. So it is added in the enhanced firmware... It is not declared as enhancement in the doxygen help.

John found that the ramp down doesn't work in some cases. He's still looking at why it does not. However, he found that if you specify OUT_REGMODE_IDLE and not OUT_REGMODE_SPEED that it does. (These are in the SetOutput RegModeField parameter.) Do you think this applies to what you are seeing? With OUT_REGMODE_SPEED specified, the rampdown does not happen. It is still moving "at speed" when the limit is reached.

[linusa]

But a overshooting rotation results in a shorted next rotation. Even when the program is stopped and started again! The brick has to be switched off to reset the rotation measurement system.

This is strange, in my experience, starting a new RXE program does clear this internal "error memory". We used to start an empty NXT-G program on our bricks to get this result. We also found out that the counter you have to reset is the "TachoCount" counter, (not the RotationCount or BlockTachoCount ones). I've tried to explain exactly how this error-correction mechanism works here: http://www.mindstorms.rwth-aachen.de/do ... ing.html#7

If you're interested in how one can overcome all such problems, you could have a look at how MotorControl works: http://www.mindstorms.rwth-aachen.de/tr ... torControl . Most SetOutput parameters are used in here: http://www.mindstorms.rwth-aachen.de/tr ... ctions.nxc . The algorithm how precise and smooth braking can be reached is described and implemented in here: http://www.mindstorms.rwth-aachen.de/tr ... erCore.nxc

[afanofosc]

It turns out that the OUT_OPTION_RAMPDOWNTOLIMIT option is, in fact, implemented. I was thinking of the OUT_OPTION_HOLDATLIMIT option which is definitely not implemented. If you set the OutputOptions field for an output to OUT_OPTION_RAMPDOWNTOLIMIT then, in theory, it should ramp down from whatever speed you specified when you set the tachometer limit once it reaches 80% of the limit down to zero for the remainder of the limit. It has not been tested widely so it may be buggy.

John Hansen