Is there a way I can read data from Misty’s drive encoders accurately enough to tell, for example, how many degrees the robot turned? I’ve found that reading the left and right velocity drive encoder data directly doesn’t always match what happened in the real world.
Thanks @michaelrod for checking with us, great question!
The encoder data may not always match due to things like slippage on the floor. I’m curious to know in your testing how match does it not match? Is the data significantly different?
What should match is the IMU data -> Misty Docs | Sensor & Skill Data Types
In fact we verify the turn by using the IMU data itself.
Take a look there and see whether what data you get from there matches with your turn and you have what you need.
Thanks, Justin. Specifically, when turning, the drive encoders aren’t actually off by much on a hard flat surface (~15%), but that can vary greatly if the surface is a soft carpet or the border between two surface types, e.g. ceramic tile and hardwood flooring. What I’ve done to maximize the accuracy is to measure only one drive encoder at a time…for example when turning clockwise (i.e. when left velocity > 0 and right velocity < 0), I read only the right drive encoder.
Your suggestion of using the IMU data, specifically yaw in the case of turns, should work well. I can use the drive encoders to simply check if Misty is turning, which way, and a rough estimate of how much, and then use the yaw data to confirm the exact turn in degrees.
Thanks for your help.
Heya @michaelrod ,
Because of the track mechanics/dynamics, the rear-going track always turns faster than the front-going track in any pivot turn (where both tracks are expected to turn at the same speed but in different directions). We are working on accounting for this to make our own pivot turns more accurate. This would partly explain why you are seeing very different values between the two tracks. Then, as @Woo pointed out, the slip is also going to cause different readings each time you make the same move. Pivot turns are even worse because the track has to “scrape” across the floor. This can sometimes cause the track to bind to the floor a bit and then break free, which causes a bit of overshoot. This makes reading encoders for turns wildly unreliable. So, very much agree with the plan to use encoders only to make sure you’re turning and use the IMU for the primary feedback in any move that requires a change of heading (exactly what we are doing).
Sounds like you’re trying to implement your own drive monitoring system! Exciting! Something to be aware of is that the time it takes to get information from the sensor level to the level at which the skill is working, make a decision, then turn around and get a command down to the hardware level doing the movements adds just enough time that you can overshoot your goal. In addition, the robot’s mass means it will move just a bit after the stop command actually reaches the motors. This drift is more pronounced with larger velocities of the robot and with straighter moves, but can still be something to watch for in slower pivot turns. May or may not be problems for you, but just telling you to keep them in mind.
We have built in API commands for turning to specific headings and driving specific distances that will let you make more precise moves without having to worry about this timing problem. These commands use the IMU for turns and will currently go to within 2 degrees of the heading you request (we will be pushing that to a much finer precision here soon). Just making sure you’re aware of that as a fallback in case you can’t get your moves to be as precise as you need.
Thanks, @steven! Yes, you’re right…the project I’m currently working on requires a decent drive monitoring system to function well and I’m using all the relevant sensor data I can get my hands on to help get as precise measurements as possible. The information you provided about the track slippage, robot momentum, and turn overshooting will help with my next steps…thanks for that! I’ll certainly be using the built-in API commands you mentioned for more precise turns in a later phase of my Misty work as well…I’m glad that finer precision is available.