ROBOTC.net forums
http://www.robotc.net/forums/

alternative to bFloatDuringInactiveMotorPWM needed
http://www.robotc.net/forums/viewtopic.php?f=1&t=784
Page 1 of 3

Author:  Ford Prefect [ Mon Oct 06, 2008 12:19 pm ]
Post subject:  alternative to bFloatDuringInactiveMotorPWM needed

@developers
hello,
the use of
Code:
bFloatDuringInactiveMotorPWM

is very unconvenient and above this works faulty (as reported).

A better way to use the motor floating vs. hold/brake mode is like it's used by NQC:
Here you can use both commands alternatively to stop a motor movement.
in a sort of adaped syntax it's like
Code:
motor(1)=stop; // hold/ brake mode
// or
motor(1)=floating; // floating mode

It was fine if you can implement this in a similar way, maybe by
motor(1)=0; // means: hold/brake
motor(1)=101; // (or any value > 100 or <-101) means: floating

Author:  Jeff McBride [ Mon Oct 06, 2008 12:41 pm ]
Post subject:  Re: alternative to bFloatDuringInactiveMotorPWM needed

I agree that the current model is annoying. We need to be able to set the break/float property on a motor by motor basis. I'm not real keen on the idea of having a "special" power value for it. I would rather have a parallel array:

bool motorFloatWhenStopped[]

Author:  Ford Prefect [ Mon Oct 06, 2008 12:48 pm ]
Post subject:  Re: alternative to bFloatDuringInactiveMotorPWM needed

hi Jeff,
I'm not a friend of HundredMillionNineThousandAndOne different system variables, so even really appreciating your appreciazation I personally would more appreciate a direct value assignement. ;-)

Why handle 2 command lines and an extra variable for stop-and-hold vs. stop-and-float instead of 1?

Author:  Jeff McBride [ Mon Oct 06, 2008 1:49 pm ]
Post subject:  Re: alternative to bFloatDuringInactiveMotorPWM needed

Ford Prefect wrote:
hi Jeff,
I'm not a friend of HundredMillionNineThousandAndOne different system variables, so even really appreciating your appreciazation I personally would more appreciate a direct value assignement. ;-)

Why handle 2 command lines and an extra variable for stop-and-hold vs. stop-and-float instead of 1?


I aggree that there are too many global variables. I would prefer that there just be a single motor[] array of structures that had multiple fields instead of parallel arrays but I don't see that happening any time soon.

However, I have a serious philosophical problem with overloading values with "special" values, particularily when it means that might change significantly based overflow. Currently values out of range are ignored (clipped) at some point below the program. Add in a "special" value and of a sudden, motor[A] = 101 does a float-stop but motor[A] = -101 keeps moving? As I said, I don't particularily like the idea.

On a side note:
I should post some of the sample code that I give my students when I'm teaching style and commenting. I realize that everybody has their own style but I am a strong believer that the readiblity and maintainability of code is just as important as the behavior of the code.

Author:  Ford Prefect [ Mon Oct 06, 2008 2:19 pm ]
Post subject:  Re: alternative to bFloatDuringInactiveMotorPWM needed

no, I guess you misunderstood me.

you can write commands like
motor(1)=stop; // where stop is a enum=0;
and
motor(1)=floating ; // where floating is any a unused enum,
may be floating can be defined as 101 or 0xFF
and any value >100 or < (-100) does exactly the same:

it sets the former moving motor into the floating state,
just like stop command (=0) sets the motor to the holding/brakestate.

(Sorry for my poor English)

Author:  mightor [ Mon Oct 06, 2008 3:53 pm ]
Post subject:  Re: alternative to bFloatDuringInactiveMotorPWM needed

Ford,

Yeah, but how would you set up the motor to float after it is done with the nMotorEncoderTarget target :) My guess is your system would cease to be useful there and you'd still need another way to set this.

Regards,
Xander

Author:  Ford Prefect [ Mon Oct 06, 2008 4:03 pm ]
Post subject:  Re: alternative to bFloatDuringInactiveMotorPWM needed

I never use nmotorencodtshdgftzdi ;-)
it's as useful as a hole in the head

but where's the problem?

Code:
int target= 1000;
while (target!=nMotorEncoder[1])
  {
    if (abs(nMotorEncoder[1]-target)>20) {speed=100;}  // anpassen fuer optimales Fahr-
    else speed=40;                                         // und Bremsverhalten
    if (target > nMotorEncoder[1]) {motor[1]=speed; }
    else
    if (target < nMotorEncoder[1]) {motor[1]=-speed; }
    else motor[1]=0;
  }
  motor[1]=0;


instead of motor[1]=0; (brake) you may use motor[1]=floating;

Author:  Jeff McBride [ Mon Oct 06, 2008 4:04 pm ]
Post subject:  Re: alternative to bFloatDuringInactiveMotorPWM needed

mightor wrote:
Yeah, but how would you set up the motor to float after it is done with the nMotorEncoderTarget target :)


Exactly. There are a lot of ways for the power level of a motor to go to 0. The break/float behavior needs to be an independant setting.

Author:  Ford Prefect [ Mon Oct 06, 2008 4:10 pm ]
Post subject:  Re: alternative to bFloatDuringInactiveMotorPWM needed

okokokok,
I am beaten.
Image

Author:  Jeff McBride [ Mon Oct 06, 2008 4:14 pm ]
Post subject:  Re: alternative to bFloatDuringInactiveMotorPWM needed

Ford Prefect wrote:
Code:
int target= 1000;
while (target!=nMotorEncoder[1])
  {
    if (abs(nMotorEncoder[1]-target)>20) {speed=100;}  // anpassen fuer optimales Fahr-
    else speed=40;                                         // und Bremsverhalten
    if (target > nMotorEncoder[1]) {motor[1]=speed; }
    else
    if (target < nMotorEncoder[1]) {motor[1]=-speed; }
else motor[1]=0;
  }
  motor[1]=0;


Since the driver natively supports managing target, it is very inefficient to do it yourself. It also hard to read and difficult to maintain. The following code gives the same effective behavior but is more efficient and easier to read and maintain:

Code:
    ...
    nMotorEncoder[1] = 0;
    nMotorEncoderTarget[1] = 1000;
    motor[1] = 100;
    ...


Meanwhile you can go off and perform other tasks. If you really want to wait for it to complete, just add this:
Code:
    while (nMotorEncoder[1] != 0)
        wait10Msec(1);

Author:  mightor [ Mon Oct 06, 2008 4:17 pm ]
Post subject:  Re: alternative to bFloatDuringInactiveMotorPWM needed

I use it *all* the time. It is very handy if you know exactly how many rotations it takes for your robot to turn 90 degrees on its axis. Also very handy if you use dead reckoning and know that in order to move the robot so that it can turn on the crossing of your line maze it has to move 7.5 cms from where it first detected it.

Your method requires the rest of the robot to wait, using the nMotorEncoderTarget method allows you to go on and do other stuff. You have the choice of waiting for the motor to be done by checking its state. Your method removes this freedom and that is never a good thing.

You can't break this functionality for the sake of saving a variable. If you set the motor's behaviour to brake or to float when it no longer receives a command to move then by simply setting the motor's speed to 0, you achieve the same result.

Xander

How's this for a hole in the head? Taken last night, about half an hour after I smashed my head off the sharp edge of a shelf. I think I came up with at least 10 new deities to curse at that moment.
Attachment:
Image085-small.jpg
Image085-small.jpg [ 79.05 KiB | Viewed 7556 times ]

Author:  Ford Prefect [ Mon Oct 06, 2008 4:22 pm ]
Post subject:  Re: alternative to bFloatDuringInactiveMotorPWM needed

@Jeff:
Quote:
Since the driver natively supports managing target, it is very inefficient to do it yourself.

I think my code is better, because of four reasons:
1) I know what my code does.
2) No other platform knows sth like nmotorencododuihfdhpffff
3) I don't have to wait cause I pack it into a seperate task
4) the Vogons will come anyway

@mightor:
Quote:
How's this for a hole in the head?

ok, nice hole. And what is it for? ;-)

PS: ceterum censeo: RobotC esse ad ANSI C developandum

PS2: nice chat :mrgreen:

Author:  mightor [ Mon Oct 06, 2008 4:24 pm ]
Post subject:  Re: alternative to bFloatDuringInactiveMotorPWM needed

If too much pressure builds up, my skull will crack. This is allow some of the excess hot air to escape.

edit: as for features unique to RobotC, that is what we love about it :)
Xander

Author:  Ford Prefect [ Mon Oct 06, 2008 4:30 pm ]
Post subject:  Re: alternative to bFloatDuringInactiveMotorPWM needed

and the reason why I hate it is actually because of the same reason :twisted:

PS: does your hole allow the magic smoke to escape off your head?

Author:  mightor [ Mon Oct 06, 2008 4:32 pm ]
Post subject:  Re: alternative to bFloatDuringInactiveMotorPWM needed

Well, there is always nxtOSEK if you're into low level functionality :) You'll have fun writing interrupt handlers, etc :)

Regards,
Xander

Page 1 of 3 All times are UTC - 5 hours [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/