Motor Issue and NXC

[HaWe]

oh, I see, but if it's too tricky even for you, then I'm afraid we'll probably have to abandon all hope ...
BTW, as I assumed some posts above this:
does RototateMotorPID() do a better job?

[hassenplug]

oh, I see, but if it's too tricky even for you, then I'm afraid we'll probably have to abandon all hope ...

The other problem, if John modifies his enhanced firmware to "work correctly" then there would be a major functional difference between that, and the standard firmware. So, a program would actually cause a robot to do different things, and that wouldn't really be good.

Steve

[HaWe]

Well,
that depends, I would say.
If something's working faulty (like the Encoder Target Approximization as you observed), who would have any benefit of the faulty functions? (e.g. rotating 300 instead of 400 degrees as it should).
A similar issue it's regarding 16bits reading of I2C device registers (LFW lets you only read 15 bits, the EFW all 16, CMIIW).

Actually everyone who wants to use the faulty function may use the LFW anyway.
2 ways for a compromise:
1) a "100% compatibility checkbox" in the EFW preferences (use 100% faulty Lego functions/use John's enhanced corrected functions) // <<== that would be really sophisticated, don't you think? ;)
2) a built-in workaround for a re-encoded RotateMotorEx/PID which uses John's workaround code implicitely which he posted above.

But I'm still curious:
does RototateMotorPID() do a better job than RototateMotorEx() or not?

[afanofosc]

RotateMotorPID and RotateMotorEx both wind up in the same place. They just have different input parameters or default values for various inputs to the Output module IOMap. In both cases the synchronized control of two motors moving at different speeds/directions (i.e., when you use a non-zero turn percent) does not work well at the firmware level.

John Hansen

[HaWe]

could it be then a better approach to start both motor functions seperately - shortly behind each other?

- or do you think you can implement your chunk of code you posted above into a new function
RotateMotorEnh()
which will do a better job?

[linusa]

Steve,

as others pointed out already, the problem you're having originates in the firmware's motor control algorithm. It's a problem of values != 0 for the TurnRatio / turnpct parameter. Such unreproducable results lead to the decision to hide this feature from the users of our MATLAB toolbox.

Now, you say synchronization is not important for you in this case. This is great news. You've basically two options, one of them was posted by John already:
1.) You put two calls to RotateMotor or RotateMotorEx into their own tasks, respectively. That way those blocking functions will be executed simultaneously. John added a helper-function using some "SetOutput magic" to keep holding the brakes...

2.) If for some reason you don't like multi-threading (i.e. multiple tasks) in your NXC app, you can also solve this problem with more "SetOutput magic". Use a SetOutput command for each motor to set the power and start the movement. These commands won't block. The next millisecond the motors are turning, and you can enter a loop, closely monitoring the motor positions. Once you've reached the encoder target, you can "jam in the breakes", by using the function "HoldAtPosition" that John posted.
This might make the exit condition of your loop maybe a tiny little more complex (only exit once BOTH motors have come to a safe and precise stop), but the concept is simple. This is essentially recoding two RotateMotor functions in one loop.

[hassenplug]

1.) You put two calls to RotateMotor or RotateMotorEx into their own tasks

2.) SetOutput command for each motor to set the power and start the movement.

I've messed with both of these. I didn't want to do #2, because I suspect the firmware can actually stop the motors more accurately. That's kind of funny, given that I'm talking about how the firmware is not accurately driving the motors.

The code John posted is exactly what I needed, and it is working very well. The turns are looking very good.

If something's working faulty (like the Encoder Target Approximization as you observed), who would have any benefit of the faulty functions? (e.g. rotating 300 instead of 400 degrees as it should).

In most cases, users just want the robot to "turn some". If the distance is not correct, they can change the turn value, or the distance the robot is driving.

In my case, I actually want to use this software on several robots, and they all need to act the same.

This may sound strange, but most people will complain more if John's firmware does not act the same (turn the same) as the LEGO firmware, than they'll complain about the standard firmware that does not run correctly.

Steve

[HaWe]

Code: Select all

This may sound strange, but most people will complain more if John's firmware does not act the same (turn the same) as the LEGO firmware, than they'll complain about the standard firmware that does not run correctly.

I see your point, but I don't agree - finally nobody who complaines about any enhanced and corrected function is forbidden to use the original Lego FW.

To be more specific:
If anybody (e.g. I) writes a program code for a robot using a C-like language, then he (or I) may expect that it works identical on all platforms (e.g., NXT, the fischertechnic TX controller or a VEX or an arduino), or identically on the same platform with similar languages (e.g., NXC and RobotC or nxtOSEK - only an example, I'm not trying to do this in reality) . This is because C is the universal language and C programs work identically (or should do it) on all platforms- if the firmware causes mistakes they have to erased / eliminated.

So the goal is to allow the code to work "universally correctly" (in your issue: turn correctly on the spot, motor left +400°° / motor right -400°), and not to conservate the mistakes /preserve errors that it always works faulty the same way only because one had once a faulty Lego firmware version.

[hassenplug]

If anybody (e.g. I) writes a program code for a robot using a C-like language, then he (or I) may expect that it works identical on all platforms (e.g., NXT, the fischertechnic TX controller or a VEX or an arduino), or identically on the same platform with similar languages (e.g., NXC and RobotC or nxtOSEK - only an example, I'm not trying to do this in reality) . This is because C is the universal language and C programs work identically (or should do it) on all platforms- if the firmware causes mistakes they have to erased / eliminated.

So the goal is to allow the code to work "universally correctly" (in your issue: turn correctly on the spot, motor left +400°° / motor right -400°), and not to conservate the mistakes /preserve errors that it always works faulty the same way only because one had once a faulty Lego firmware version.

I'm not trying to disagree, but I'm not sure who's point you're trying to argue. I agree that a C language should work identically on all platforms. In a very simple case, that means NXC (one language) should work the same on both the standard firmware, and John's Enhanced firmware.

Second, I'm not sure "universally correctly" is an option. I think this discussion questions if EF should be "universal" OR "correct".

There ARE mistakes in the standard firmware. WE have little or no power to change that. Asking that those changes be removed in EF, would mean NXC is no longer universal with different firmwares.

Steve

[HaWe]

no Steve, that's not the point.
You can't demand that any C language and all optional fw versions should be compatible to all or any FAULTY firmware versions only because they once have been released by the original manufacturer.
If the program tells the motor to turn 400° it has to turn 400° and nothing else.
A firmware which lets a motor turn only 300 degrees or whatever where 400 degrees are demanded by the program is simply not working correctly.

Imagine, you observed that the Lego fw calculates 1+1=3. What you now demand is that NXC always has to calculate 1+1=3 forever based on ANY fw version (e.g., the EFW) just for compatibility reasons...!?!

You will not honestly try to tell me that that Lego fw misbehaviour should be made to a standard behaviour for all NXC programs forever in the future no matter on what fw they are based on ?!?