LEGO is not moving straight!!

[ragrover]

I am using NXT2 and programming it using MATLAB RWTH Toolbox. The problem I am facing is that I am unable to make the robot move straight,it is slightly deviating from its path. I tried it on a smooth surface too but still the same issue. Here is the code

h=COM_OpenNXT(); % Assigns a handle to NXT
COM_SetDefaultNXT(h); % Sets the handle as default for all future function calls
OpenSwitch(SENSOR_1); %Opens the touch Sensor
mA=NXTMotor('AB','Power',50);
mA.SendToNXT();

[hassenplug]

The firmware has functions to make the motors move the same distance using PID functions. The call you're making, only sets the motor power, without trying to trying to synchronize them.

You should look to see if there are any parameters, or other functions that include synchronizing them.

Steve

[circuitmage]

The assumption being that all motors are equal?

I would suggest that if you see anomalous behavior, there should be a reason...an opportunity for investigation.

It would be interesting to sample 100 motors match 2 that work identical. But it would be more time effective to use another method, such as suggested above. I would guess even 2 "matched" motors would deviate over time.

This is a fundamental concept that must be tackled before more interesting (room mapping robot?) applications can be implemented.

[HaWe]

unless both motors /motor axles are not synched in any way the vehicle is NEVER going straight.
(Also by synching they actually are not going exactly straight, but greatly much more straight.)

You may try it by any embedded API functions (similar to the Lego FW functions which Steve had mentioned) or you may synch them by your own (e.g., monitoring each single motor encoder and reduce the pwm power or switch the faster motor to coast if the encoder value is >1° bigger than the other one).

There will be simple methods to achieve this (like the one I mentioned) and there surely are smarter ones (like setting up your own PID controller) - but there will be no way to do it absolutely without.

The reasons why this is so begin with mechanical friction, slip, and grip, furthermore alignment inaccuracy, then fluctuation of pwm voltage/power output and electromechanical motor coupling, and ends up with quantum mechanics.
For navigation, localization, and room-mapping robots, "identical motors" never are a necessary condition (where "identical" actually can not exist at all), but concepts like motor synchronization, odometrical monitoring, and sensor fusion by statistic a/o stochastic filtering.

I'm quite sure that the RWTH Aachen Toollbox for MATLAB is featuring smart motor control for synchronization. Maybe you wish to contact Linus Atorf who did much work for the RWTH Toolbox.

http://www.mindstorms.rwth-aachen.de/
[email protected]

[circuitmage]

Quantum Motors...now there's a concept for robots.

[HaWe]

not quantum motors.
quantum effects ;)
and I think you know: it should mean just the "lower end" of all faults and disturbances
(- but finally it's true: motor/driving action is just the result of coincidences and probabilities).