Why the speed of motor change direction when the data is over 100?

[jerry_dcjx]

this problem happens in the teleop part of our program. we use the omni wheels and are controling those wheels through a analog stick.

in the picture is our wheels controlling part.

when we try this program in high speed mode, the data will go out of range. normally, the data will be change to the max or min limit, but the real action of the robot shows that the program is actrully revert the speed value of the wheels when the analog stick is in the four corner.

why? i really think this is impossible, though.....

[mathterizer]

Jerry:

Math 'overflow' errors can cause a sign bit to switch. Things like that can happen depending on how numbers are stored and the math operations performed. I don't know what kind of safegauards LV has against this.

Data Representation is indicated by the colored wires.

• 'double 64-bit real' [~15 digit precision] (orange wire)
• I8 '8-bit signed integer' [-128 to +127] (blue wire)
• I16 '16-bit signed integer' [-32768 to +32767] (blue wire)

I8 and I16 are both blue wires so I don't know which you have in use here. You will need them to be i16....here's why:

If 'speed' is set to 100, and you think of joystick output as a percentage modifier on that, you are adding and subtracting values that can be [-100..+100] before co-ercing. The resulting number might go out of the I8 range of [-128 to +127]; thereby flipping the sign bit.

Something to try before you make code changes:

• See what happens at 'speed' = 60, 63, 64, 85
  • So the joystick output can reach 100% and it will be (100% of 63) - doubling that would be at max 126   - should be good
  • So the joystick output can reach 100% and it will be (100% of 64) - doubling that would be at max 128   - may see some issues [-128 is okay; +128 is NOT - it would bit flip to be a negative]
  • So the joystick output can reach 100% and it will be (100% of 85) - many more combinations of joystick output percentages would result in numbers outside the range [-128..+127]  - you'd see many more issues

When it flips to 'reverse' is the power about the same? or is it quite a bit slower, just in reverse? 

You can use the 'Funtions - NXT Programming - numeric - conversion' operators to enforce the data representations.

Another thing you might consider:

• Do your speed calculations require the local variable 'speed' to be a 'double 64-bit real' representation (orange wire)? You might try changing that local variable to an I8 '8-bit signed integer' representation (blue wire). Since it's domain is [-100..100] and within the I8 [-128..+127] Do this by right clicking on the variable and choose 'Representation'.

NOTE: I'm sharing this as a possibility based on my knowledge of computer science, in genreal. I dont know a lot about the specifics of LabVIEW in this regard. Perhaps a LabVIEW expert can chime in.

I look forward to hearing from you if my theory holds true

[jerry_dcjx]

Thanks, it works. I found that the data type in analog stick is all I8, so I change them all to I32, and the program works well.