Hi All,
Is there a way to tune the wheels speed so that the robot is able to move in a straight line instead of constantly turning (gyration radius is about 3 meters)? This happens when using all in-built programs.
Thanks for your help
Dcccccccccccccccccccccccc
Hi dccc, hello Community,
same here! my brand-new Thymio acts like dccc described it.
However, while the robot is resting (no wheel movement at all), i can see in aseba studio, that the variable "motor.left.speed" jumps between "-1" and "-5", while "motor.right.speed" stays at "0" all the time.
Is there a calibration procedure that one can execute?
Thank you for support
Thanks for your answer
I have checked that indeed at idel the var motor.left.speed is always fluctuating between -3 and 0. This means of course that Thymio believes that the left wheel does not rotates fast enough and compensates for it, which therefore makes it turn right. This is either a hardward defect (in which case we would love to hear about how to get it fixed), or a firmware issue. Could someone familiar with either of the two tell us a bit more about this point?
Thanks in advance !
Dccc
What you see is perfectly normal and not a problem of your robot.
The wheel speed sensing is based on the back-EMF of the motor, and when the motor is not moving, the back EMF is strictly equal to 0 both in theory and in the real world. What you see with a speed fluctuating between 8 and -8 is in fact the power supply noise.
If you look at the thymio electronic, the only way to sense the back emf is to connect one terminal of the motor winding to iteratively GND (0V) and then VBat (between 3.4-5.1V).
You can have a look at the code doing this here.
So depending of the motor rotation direction, we do:
1) Measure BackEMF either from GND or Vbat, depending of the motor rotation direction: STATE_VIND1
2) Measure the other one, because the motor can have changed it's direction since last measurement: STATE_VIND2
3) mesure Vbat (since it can change between 3.4 -> 5.1): STATE_VBAT
At step 3 we correct the motor's Vbat-connected backEMF with Vbat measured at step (3) so we can cancel the Vbat offset of the measurement.
What you see is a little voltage fluctuation between step (1) or (2) and step (3) on Vbat. Thus the offset is not strictly canceled.
FYI: a value of "5" mean 16mV, which is quite low since when the robot is connected to the computer VBAT is in fact connected to the USB power supply, thus what you see is the noise generated by your computer.
Many thanks for your answer. This however does not explain why the reported speed of the other motor is 0, without fluctuations
Now the practical question is how to adjust the bias correction, since I wish to make my robot go straight. Since the remaining bias seems pretty constant, there should be a way to determine it, for instance by taking temporal averages.
Of course one can correct it in a program, but I would really like to be able to leave my child programming without these complications.
Thanks again for your help.
I think here we have a fundamental problem about how robots works. So let me tell you a basic property of robots:
- Robots *NEVER* go straight.
You can have the "perfect" calibration procedure and the most expensive motor, it won't go straight. You have to live with it. Robotic is hard.
BTW, did you try once to walk with your eyes closed ? Did you go straight ?
Think about it. BTW, it's the same with a car (although I don't recommend to do it …)
So when you say "(…) but I would really like to be able to leave my child programming without these complications." I disagree. This is not a complication, it's the real world.
I do not expect it to go perfectly straight (my Roomba does not do it either), but more straight that it does now, which should not be that hard.
Assume that I know that my robot needs 2.54 (on average) less speed on a wheel than on an other
I could of course program something like [schematically, I did not look up the precise function name]
set.wheel.speed.right.calibrated(x,bias=0){
set.wheel.speed.right(x+bias)
}
set.wheels.speed.left.calibrated(0,bias=-2.54){
set.wheel.speed.left(x+bias)
}
and I do understand the pedagogical value of the experience, but aren't real-life robot calibrated? I mean to say, wouldn't it be possible to store the real-life bias somewhere in the firmware or by overloading e.g. the set.wheel.speed.left functions?
BTW it is too early to introduce my child to these real-life complications. He enjoys very much the feedback from the proximity sensors to his actions, (that was a brilliant idea) and basic programming with the visual interface.
The point is that the visual interface does not allow easily (for a child) a fine setting of the motor speed values. This is why I would suggest that one could enter the average bias somewhere in the settings of the visual programming interface and that the real values sent to the robot would be corrected. This would keep the kids happier while leaving the full complexity of the robot experience to the more grown-ups.
Thanks for the time to take to enlighten me.
Hello,
As of now the only solution if you want to go straight in an open loop, is to program both motors with different speeds that you find by trying.
I can add your idea of entering a bias in VPL to the wishlist and we will discuss it with the main developer; however I would like to add something.
As said above, no robots go straight, but indeed some can be more precise than others with expensive motors and calibration etc. In the case of Thymio II, as it is a low cost robot we can see more variation in the wheel speeds. This in our opinion is really a minor problem for learning robotics. Robots are not automatons that operate in open loop (i.e. without perceiving anything about the world); they have sensors, they can react.
This sensory-motor loop is a key concept in robotics, and in many devices and systems that we use everyday. An "intelligent" robot reacts to the world surrounding it. Our goal when teaching robotics is to teach exactly this: how a machine can use information about the world surrounding it to solve the task we want.
We think it's the wrong approach to make a very precise robot that can not adapt or acts blindly, thus we don't think the first step of learning robotics is to program behaviours like "go straight for 4 seconds, then turn left 90°, then go straight 2 seconds" to reach a target, and only then move on to sensors as if they were complicated. This is an automatons's behaviour.
Our philosophy is to have a reactive robot; to program things like "move, turn right if there is something on the left, turn left if there is something on the right, stop when the target is detected" to have an adaptive, robust behaviour even with low-price, not-so-precise hardware. The first step towards learning robotics could be, for example: "move forward until an obstacle is detected".
Everything in Thymio II and Aseba is designed with this philosophy in mind: many sensors, low-cost hardware, event-based programming, event-action pairs in VPL, robust robots that can handle shocks and falls without getting broken.
I hope that now you understand better our philosophy, and why we do not consider making the robot go perfectly straight a priority.
Hi,
yes my thymio acts like your, but you can give motor.left.traget or motor.right.target other values, I have tested values (200, 205), the result was ok for me. thymio unfortunately no ordometer and the wheels can slip on surfaces. A calibration procedure is difficult. At a slower speed, it works better.
Michael Kany
From firmware V.8 you can calibrate your motor to make Thymio go straight.
How to calibrate Thymio's motors
