Mindboards

Hi,

I am looking for a way to detect a motor that is stalled. Well not really stalled, that would be easy. I want to detect when a motor is experiencing a large counterforce so that I can shut down the motor (or program) to prevent damaging my drive train and motor. Btw, the motor is using regulated speed.

An example, suppose a robot that drives around and hits something that prevents it to drive any further. Then the wheels start slipping, thus increasing the forces on the drive train and motor. I would like to detect this to be able to stop the motor.
In case you are wondering, I do already have a Us-sensor and a touch sensor mounted to detect (possible) collisions.

I am using robotC, but solutions made in another inveronment are also welcome.

I know some people consider NXT-G to be somewhat inferior to other languages but so far I haven't really needed anything else (although I'd like to learn NXC). Brian Davis posted a block on NXTLog that should help some. While it won't work in RobotC (of course ) it should still give you an idea of what the code structure should/might look like.

aswin0 wrote:I am using robotC, but solutions made in another inveronment are also welcome.

I have no idea about ROBOTC, but I know that there are two registers in the Standard (and Enhanced) NXT Firmware that you can use (via direct commands or directly from NXC). Once speed regulation is enabled, the internal "real" power value will be set by a controller to match the setpoint power you specified. This internal "real" power is called "ActualSpeed". So if there is no friction or load on the motors, ActualSpeed should pretty much be the same as Power. But as soon as the motor is stalled, the ActualSpeed (which should've been called "ActualPower" anyway) will increas. Once the firmware can't keep up with the friction, and the the motor's speed drops below the setpoint (i.e. when ActualSpeed reaches a value of 100 and the motor is still too slow), the so-called Overload bit will be set. This is a good indicator for stall-situations...

But the coolest method will be to detect a change in speed that you didn't cause (or that you couldn't foresee). Because sometimes during a stall condition, wheels will start spinning faster (when they're slipping), or differently (jittering / bucking).

Hi aswin0,
This could be difficult. My first thought is to evaluate the motor's speed (as someone else suggested). With regulated speed, the system will adjust the power as needed to keep the speed generally constant. If the wheels slip easily no speed change will be detected -probably even without regulated speed.
How about a method that's partly mechanical? Consider something in the gear train that "pops up" and triggers a touch sensor when the load gets high enough. This could be as simple as leaving one end of the NXT motor free, For normal torque the motor rests on a support. If torque is increased the motor swings up to press a touch sensor.

By the way, the NXT motors have an internal mechanical clutch to protect them from overload. Edit: Opps. My mistake. There is no mechanical clutch in these.

Dave

dad-and-adam wrote:By the way, the NXT motors have an internal mechanical clutch to protect them from overload.

Hmm, I find that interesting. I set my NXT to power a NXT motor at 100% power once and then slowed it down with my hands. I could completely stall the motor with a bit of force. And as far as I know, there isn't any clutch inside. It does have a PTC or thermistor of sorts that will heat up and cut down the available current if you keep the motor stalled for about 2 seconds.

Fortunately, as nxtreme said, they don't. If they were to have internal mechanical clutches, then it would have to be before the encoder, so a very high RPM one.

As far as I know, the only Lego motor that can keep running when the output is stopped, is the clear "ice-cube" motor. The only reason for that though, is because almost all of them have a split motor gear (all three of mine were split when I got them).

That's always a problem to me.
what about a seperate task wich polls the encoder values every e.g. 100ms? If the absolute difference between both readings is repeatedly close to zero while the motor is running it's probably stalling...

Doc,

I really like your "out of The box" thinking with your suggestion of a mechanical solution. I can imagine such a solution where one uses a differential to subtract the speed of the motor axis from the speed of an independent wheel axis. If the two are different do to slippage or grinding gears then the body of the differential will start to turn. This could drive a lever that actuates the touch sensor. There are some practical issues that prevent me from doing so. Otherwise it would make a neat solution.

RobotC does give me access to te PWM level of the Motors. This enables me to detect u sudden rise (or drop) in the amount of power going to the motors. This could be the first step in detecting a stall situation. The second step would be to distinguish a situation of intended acceleration from one of increasing resistance. If I can do this as well I think I'm close to a solution.

The reason I have the need of such a solution is not only to protect my hardware. I do rely partly on odometry in mu project and slipping wheels or a grinding gear train do corrupt odometry information. (please no discussion on odometry here)

dad-and-adam wrote:
By the way, the NXT motors have an internal mechanical clutch to protect them from overload.

Opps. My mistake. The NXT motors do not have a mechanical clucth in them. -It's my brain that slips when overloaded

Thanks for pointing out my error.

Dave

dad-and-adam wrote:It's my brain that slips when overloaded

Yes, my brain does that too !

dad-and-adam wrote:Opps. My mistake. The NXT motors do not have a mechanical clucth in them.

Well, the PTC that protects the motor from overload could almost be though of as an electronic clutch. I can understand the mix up . For those of you who haven't already seen the internals of a NXT's motor, check out Philo's great website.