Ramp Up / Ramp Down

[mcsummation]

After much more experimentation, I decided the "two phase ramp down" wasn't doing anything useful. The single phase gets the motor speed down to something small enough that, when it slams on the brake, it simply stops.

However, I've got another problem now. I made a separate RampDown procedure to handle another case in my Odin code. The place it is used is:

Code: Select all

#define RampDownDistance 70
    // Back up to the long line.
    SetSensorColorFull(S3);
    ResetRotationCount(OUT_B);
    Wait(10);
    RampUp(OUT_B, 35, 180);
    until (1 == SensorValue(S3))
    {
        ContinueRun(OUT_B, 35);
        Yield();
    }
    fDistance1 = MotorRotationCount(OUT_B);
    SetSensorColorNone(S3);
    RampDown(OUT_B, RampDownDistance);

"Randomly", it will hang in the RampDown. I've been puting various amount of code in to determine exactly where the hang is located. I finally determined that the MotorRunState(output) sometimes goes to OUT_RUNSTATE_RUNNING, and, when it does, it never comes out. (The code in the routine I'm uploading looks for "idle" or "rampdown". "Rampdown" is the normal state until the end.)

The same code is in the RotateMotorRURD procedure and never hangs. Is it something in the

Code: Select all

void ContinueRun(byte output, char pwr)
{
    // If RampUp has completed, turn motor on.
    if (MotorRunState(output) == OUT_RUNSTATE_IDLE)
        OnFwd(output, pwr);
}

as opposed to the way the RotateMotorRURD code puts the motor into "run at a constant speed to an angle"?

[mrblp]

Hello there,

I should have read this thread before posting myself. I did very similar checks on motors in the last three weeks...

John, are you still examining the firmware? First I thought there seems to be a bug in the enhanced firmware option RAMPDOWNTOLIMIT since I never had any problems using the RAMPUP / RAMPDOWN. But I did it not check as intensive as mcsummation.

I will check the code posted and try to get to the solution...

Did anyone cross check the behavior of NXT-G?

Another question: How to check the RUNSTATE when using more than one motor? I only get "0" when reeding this one. The same question for the counters... Should we give nbc a try?

Bye marvin

[afanofosc]

My ramp down to limit option is Not Yet Implemented. I apologize for the confusion. Don't bother trying to use/test it.

I don't understand these questions:

How to check the RUNSTATE when using more than one motor? I only get "0" when reeding this one. The same question for the counters... Should we give nbc a try?

You can read counters and runstate or any of each motor output's fields using the Motor* functions which read only a single motor's values so never pass in something like OUT_AB or OUT_BC or OUT_ABC to one of these Motor* functions. The help says it has to be OUT_A, OUT_B, or OUt_C only.

http://bricxcc.sourceforge.net/nbc/nxcd ... c2c10.html
http://bricxcc.sourceforge.net/nbc/nxcd ... 45131.html

etc...

RAMPDOWN works fine except when you turn on OUT_REGMODE_SPEED and, technically, I think with this mode enabled RAMPDOWN is not designed to work at all but I am not certain about that. Speed regulation is supposed to keep the motors turning at a specified speed even when friction or some external force tries to speed up or slow down the motor. So it stands to reason that with this regulation mode turned on that the rampdown function would not work. But it is possible that the combination of these two options is buggy in the firmware.

John Hansen

[mrblp]

Hello,

My ramp down to limit option is Not Yet Implemented. I apologize for the confusion. Don't bother trying to use/test it.

Oh. OK, thank you for this hint. Found some code in firmware to support this feature so I thought it should be there... Sometimes it works...

I played again with firmware: When setting up PWM frequency to 16 kHz the motors are still well powered - and silent. Why are the PWMs of those systems often run with audible frequencies? I know if a pwm is set up to too high frequencies the the motors will get inefficient and the minimum power to run will get higher. This has to do with magnetic effects. But I cannot see this effects at 16 kHz.

I don't understand these questions:

How to check the RUNSTATE when using more than one motor? I only get "0" when reeding this one. The same question for the counters... Should we give nbc a try?

You can read counters and runstate or any of each motor output's fields using the Motor* functions which read only a single motor's values

Yes I know. When I setup my programs I use constants like MOTOR_DRIVE (OUT_CB) to abstract the real outputs. Or I use variables. All of those variants may directly be used with SetOutput - but neither of it with any of the Motor* functions. I have read NXTdefs.h so as I understand you put some code there to decide what to do at the setting functions. The idea is to make the same on the input (motor*) functions. I do not think this can be done in the compiler because the exact behavior is dependent on the robot setup. Not sure my idea is right...

RAMPDOWN works fine except when you turn on OUT_REGMODE_SPEED

OK, this may get a very philosophic discussion. To cut a long story short I will try NXT-G at some time and cross check. Will post this later on - I work with linux so I have to reboot for win...

Edit: Cross check with NXT-G: You can select this combination in the motor blocks but with regulation activated it does not work really. The system behaves unreliable and a bit unpredictable. When regulation switched off the it gets better but it seems the motor sometimes does not reach the position it should.

So it stands to reason that with this regulation mode turned on that the rampdown function would not work.

This is why I meant it may get philosophic You are right. The ramp down is a method to get smooth to an angle without overshooting. In my eyes speed regulation and ramp down are not like fire and ice. Technically spoken they are but when this is best practice - why not accept this conflict?

I'll be back in a few minutes...

Bye marvin

[mattallen37]

In regard to you question about PWM frequency, I have wondered that as well. Often H-Bridge/Motor setups are "rated" for a maximum of about 20kHz. 16 kHz might not be noticeable for someone older, but last I checked, I could still hear at least 19kHz (a couple years ago I could easily hear 20kHz).

It would be interesting if Philo did some of his famous motor tests (or someone else well equipped), but this time comparing 16kHz to the default (8kHz?). I would like to know the real difference in performance.

[HaWe]

.. but last I checked, I could still hear at least 19kHz (a couple years ago I could easily hear 20kHz).

...that decreases rapidly with age, matt, very rapidly...
;)

[mrblp]

Hi mat,

16 kHz might not be noticeable for someone older, but last I checked, I could still hear at least 19kHz

I am older - so I cannot tell you It is a question of the amplitude, too. Normally the ears need a higher amplitude at higher frequencies so 16 kHz should be at least more quiet than 8 kHz.

I do not have anything to measure the power and torque. The only thing is my feeling of my fingers and my eyes watching...

I can upload that firmware - but it is a special 1.29 enhanced version without on brick programming... If anyone wants it I can make the 1.31 version with different pwm frequencies.
You can do it by your own very easily. You only need the IAR toolchain installed and the source code repository of the 1.31 enhanced version on your disk.

Bye marvin

[mattallen37]

Right. 16kHz would probably be a lot better than 8 (or whatever the default is), even for someone that could still hear it.

Why don't you get in touch with John Hansen, and see if he will implement it into his EFW (as a user option)?

[mrblp]

Hi mat,

John has an instruction to set the pwm frequency - but it is not really implemented down to the details of the system.

My change is not a user selectable pwm frequency because I simply wanted to check the effect.

I do not think John wants to reactivate this instruction because the users are not interested. If there are a lot of people who want to change the pwm frequency - well - I will support John.

I had a lot of views on different parts of the firmware and I thought I could rework parts of it and send it to John. He knows what happened: I made some #define-switches to setup a very bare version (no OBP, no Datalogging, no Startup screen) at compile time and that was all. Any other project died because of the time. Ah, it all began when I got my second NXT with a changed display. This display had a bad contrast so I always wanted to add a display contrast setting. It is easy to change the contrast setting statically but it is a lot of work to change anything in the menu system. So in the end I have two firmware versions for my two NXT bricks

Bye marvin

[mattallen37]

That doesn't exactly make sense to me. Are you saying he did implement it, or he decided not to? As long as having it an option doesn't use up much of the resources, I don't see any reason not to make it an option for the few that might use it.

I would really like it if John would make two versions of all the EFW variations. One would be normal, and one would strip what you mentioned (OBP, Datalogging, and startup screens).