In my workshops I get asked regularly, what the turn option of the default steering block means (see the image).
Obviously, if the turn option is set to 0, the robot is moving forward. A positive value is turning right, a negative is turning left. So far, so good.
I looked in the source code and found a programming scheme I tried to visualize. A large comment within the code describes the process as follows:
- Speed [-100 .. +100] is move forward or move backwards Turn ratio [-200 .. +200] is how tight you turn and to what direction you turn
- 0 value is moving straight forward
- Negative values turns to the left
- Positive values turns to the right
- Value -100 stops the left motor
- Value +100 stops the right motor
- Values less than -100 makes the left motor run the opposite direction of the right motor (Spin)
- Values greater than +100 makes the right motor run the opposite direction of the left motor (Spin)
So the turn ration is multiplied by 2, because as a user we can just put -100 <-> 100 in there. I then used this code to calculate some values:
for (var i = -100; i == 100; i++) {
turn = i * 2;
if (turn >= 0) {
motorB = speed;
motorD = speed - turn;
} else {
motorB = turn + speed;
motorD = speed;
}
}
If I visualize those values, I get the following image for speed 100:
That's fine. You can see the real turn value (the ones we as a user can set) and the calculated speeds for two (virtual) motors B and D. I tried this with the educator model and it works perfectly well.
But when I use the same code for another speed value (33), I get motor outputs that are too high in my opinion:
The Motors will have values over +100/-100. Is there a threshold in the code and the motor outputs will be cropped?
Did someone else dig into this? Did I made a mistake?
P.S.: I love such things. If someone is interested in doing more if this, just ping me. :)