The motor is set to forward() until the touch sensor is pressed. Then it should rotate to a certain number of degrees.

The problem is the latter part, rotating a certain number of degrees: Sometimes it rotates much less degrees than it should, sometimes it rotates in the wrong direction (causing sever damage...) right through the sensor...

As mention before: with lejos 0.5.0 a very similar code ran without any problem (well the jittery motors aside:-))

Thanks so much in advance for your help!

EDIT: I took last evenings version which ran on 0.5.0. Here too the same error occurs: the Movement for -115 Degress (times the gear ratio) has stopped after ca -20 degrees. If I run it again, chances are that it will drive in the + direction again right through the touch sensor. Ouch, help, please!

I have tested the following calibration methods:1) Homing of a complex geared mechanism via touch sensor in 0.5.02) Homing of motor + basic limiter via stall detection in 0.6.0

In each case I used resetTachoCount, and then movement based on rotateTo methods. It seems to work ok. Some in-exact-ness in rotation forward vs back in case (2), hard to tell yet if its mechanics or the code.For (1) - couldn't get stall detection to stop motors in time when driving a complex mechanism with high gear reduction.

I'll post some examples when I get home.

Some advice from personal struggles (sorry if this seems like trivial stuff to all but me ):* Try to work out stall detection threshold - see if it can be effective in your case* Add isStalled checks to your calibration loop* Don't use "forward" method to begin rotation during calibration. Use rotate(angle, true) - this way your motor will stop before it does too much damage* Do initial tests at low motor speed, and via ssh - you will have enough time to kill/ctrl-c the program, before it does too much damage.

When run, the touch sensor stops having any effect after a few touches. The motor NEVER rewinds for -720. But stops shortly and then turns forward again (sometimes stopping after a few turns and restarting).

And Andy, yes, switching to rotateTo instead of rotate totally solves the issue!

And also not resetting tacho when using rotate also seems to work! Like in here:

// already touching sensor, but could be "over-pressing" due to previous run not stopping in time and having been aborted // first get lost, and then do calibration anyway if ( readTouchBoolean() ) { gripMotor.rotateTo(ROTATE_GRIP_MIDWAY); }

so you are not calling "isStalled" but wait for the motor to stop because it IS stalled, right?

Will isStalled be true if the motor is not stalled entirely but is just going against hard resistance?

For Homing the "hand" of my robot i simply use a technical solution by using a gear with clutch (http://www.bricklink.com/catalogItem.asp?P=60c01). I wonder if I can also replace it by code that uses stall detection. But I fear slipping of gears or breaking stuff.

So is it possible to stop the motor as soon it goes "very hard" but not 100% stalled?

I would be happy to learn more. I think the docs do not completely introduce the concepts here;-)

From my understanding isStalled() works by comparing the lag between actual position and intended position of the motor. If difference persists too long - isStalled is set. You can try to fine tune it to minimum workable values for your mechanism.I thought of using getPosition vs getTachoCount and writing my own function to detect various degrees of motor being "stalled", but I don't think you can at getPosition via public API yet.

Clutch gear didn't work for my grip due to high torque, and for radar looked like it would "loose" calibration after a while

Previous example was from my grip mechanism, where stall detection didn't fire most of the time (with 0.5.0)Will have to go back and try to fine-tune it again.

Here's a draft of calibration via stall detection, I've been using for a basic radar (ultrasonic sensor directly connected to ev3 large motor).From my testing this approach is far less scary then it looks. From appearances doesn't seem to take any longer then touch-sensor based calibration.

this thread has slept a long while:-) Now we have Lejos 0.8.1 beta - and I am working on a new EV3 model. Here I use three of the big EV3 motors - each of these has to be initialized in its home position. Since I have only two touch sensors, it is time for me now to dive really into stall detection and use that for initialization.

A lot of work I think has gone in the motor code of Lejos EV3, so I am unsure if there were changes regarding stall detection. Is there maybe sample code or a recommendation how "nowadays" motors can be calibrated with stall detection? I am looking for some of guidance or best practises since I fear to destroy my motors while learning:-)

Any help or advice is greatly appreciated! Do you think stall detection is a totally OK way of initializing a robot (in regards of potential damage to the motors?)

If all you want to do is zero the initial motor position you may want to use an NXTMotor first, this will let you set a very low power value which will allow the motor to stall more easily. Once you have the zero position close the NXTMotor and open the port as a regulated motor to allow position regulation to be used.

Yes, to find and zero the initial motor position gently by stalling is the goal.

Looking at the API for NXTMptor I cannot see references to a isStalled or any other stalling detection. How would you detect the robot has reached the zero position then? Is isMoving() the method to poll?

So I would setPower to smallest Value that gets the motor actually moving. Then poll isMoving until this returns no?

No you can't use isMoving either as all this reports is if you have asked it to move (NXTmotor is a very simple interface to the motor it has no sort of intelligence at all), so you simply need to check the tacho count and wait until it has not changed for some length of time. The key is that unlike the regulated motor NXTMotor will not make any attempt to keep the motor moving when it hits some sort of resistance so with a lowish power it is very easy to stall the motor.

Btw: will the NXTMotor class keep its name? I am a little confused regarding the nxt prefix in the ev3 classes. I guess the effort might not be worth breaking existing code bases. Or that you only adapt class names when you actually update the internals too