NXC: MotorOverload always returns false

Discussion specific to NXT-G, NXC, NBC, RobotC, Lejos, and more.
Post Reply
avcampos
Posts: 4
Joined: 07 Oct 2013, 23:43

NXC: MotorOverload always returns false

Post by avcampos »

Hi all!

I'm programming a robot that has limited travel on one of its articulations. I don't require precision on its position, just that it stops the motor as soon as it hits the limit.

NXC has the MotorOverLoad function, which appears to do exactly what I want... however, it always returns "false" even if the motor is completely stalled! Digging a bit, I found that MotorOverload is actually a shortcut for one of the fields of GetOutput (like "GetOutput(OUT_A, OverloadField)"). Checking the field's documentation, I see that, for it to work, I need to set the motor according to numerous parametres... but, after setting them, I can't get the motor to actually run!

This is what I wrote to get the motor running, while hopefully enabling MotorOverload:

Code: Select all

SetOutput(
	OUT_C,
	RunStateField, OUT_RUNSTATE_RUNNING,
	OutputModeField, OUT_MODE_MOTORON + OUT_MODE_REGULATED,
	RegModeField, OUT_REGMODE_SPEED,
	PowerField, power_C * d);
If I use the normal "OnFwd" instead, the motor is never stopped:

Code: Select all

if(MotorOverload(OUT_C))
	Stop(OUT_C);
What could I be doing wrong? Thanks in advance!
afanofosc
Site Admin
Posts: 1256
Joined: 26 Sep 2010, 19:36
Location: Nashville, TN
Contact:

Re: NXC: MotorOverload always returns false

Post by afanofosc »

You can use OnFwdReg with the OUT_REGMODE_SPEED regmode constant

http://bricxcc.sourceforge.net/nbc/nxcd ... ff41f147f5

This API function will run the motor with all the required parameters for the overload field to potentially be non-zero. Make sure you use a power level < 100. Then hold onto the axle so that is slows significantly for a long enough period of time that your call to MotorOverlad would catch a point in time where the speed regulation was unable to maintain the set speed (e.g., 75) even at its highest power levels. That should return a non-zero value in that case.

Have a look at the OnFwdReg macros in NXTDEFS.h to see how you could use SetOutput to do the same thing.

Code: Select all

#define OnFwdRegEx(ports, pwr, regmode, reset) setout ports, Power, pwr, OutputMode, OUT_MODE_MOTORON+OUT_MODE_REGULATED+OUT_MODE_BRAKE, RegMode, regmode, RunState, OUT_RUNSTATE_RUNNING, TachoLimit, 0, UpdateFlags, UF_UPDATE_TACHO_LIMIT+UF_UPDATE_MODE+UF_UPDATE_SPEED+reset
In your code you were missing the update flags which is crucial to telling the firmware which fields were updated by the call. Otherwise it waits for a subsequent SetOutput which sets those update flags and does nothing.

John Hansen
Multi-platform LEGO MINDSTORMS programming
http://bricxcc.sourceforge.net/
pepijndevos
Posts: 175
Joined: 28 Dec 2011, 13:07
Location: Gelderland, Netherlands
Contact:

Re: NXC: MotorOverload always returns false

Post by pepijndevos »

Actually, I have some code for this laying around: http://studl.es/2012/03/explorer-robot-without-sensors/
-- Pepijn
http://studl.es Mindstorms Building Instructions
avcampos
Posts: 4
Joined: 07 Oct 2013, 23:43

Re: NXC: MotorOverload always returns false

Post by avcampos »

Thanks for your answers! Indeed, using OnFwdReg was the key... I had no idea that, for SetOutut to enable the GetOutput fields I had to also set update flags! I really spent too much time with the RCX before moving to the NXT...

Anyway, I ended up not using MotorOverLoad, as I noticed the motor spent some time trying to overcome its limit before giving up; and, since the motor is to move in short bursts, this time is considerable. So I went instead for MotorActualSpeed, which gives up earlier:

Code: Select all

if(abs(MotorActualSpeed(OUT_C)) > 75)
{
	Off(OUT_C);
	stall_C = sign(MotorActualSpeed(OUT_C)); //Won't try moving in this direction next time
}
pepijndevos wrote:Actually, I have some code for this laying around: http://studl.es/2012/03/explorer-robot-without-sensors/
That's a very interesting solution to spare sensors! But I guess the obstacle detection accuracy would be very dependent on ground friction (false negatives) and inclination (false positives).
Post Reply

Who is online

Users browsing this forum: Semrush [Bot] and 13 guests