Robot Not a Dev? Pre-order Now
Not a Dev?

Misty Community Forum

Can the TOF sensors be re-calibrated?

I’m working with Misty’s TOF sensors and noticed that they are showing a difference between what they report vs. reality. For example, if I place an flat object exactly 50cm in front of Misty, I get readings of 120 to 127 depending on the sensor reporting (e.g. toffc, toffl, or toffr). If those values are in centimeters, then it’s a big difference.

I also noticed that the TOF front right (“toffr”) sensor seems to be sending back about 10 times the amount of data than the center or left front sensors. Is this by design?


Welcome, Michael!

We’ve had some discussions about tis but I am not sure where those netted out. I will find out and report back (or someone else who is closer to it will)

Thanks for posting this here @michaelrod!

To answer your first question, there’s not currently a great way to recalibrate those sensors in the field, and I don’t have an answer as to why you’re seeing more frequent messages from the toffr sensor (though I’m pretty certain that’s not by design). But, assuming you’re working with an FEP prototype (let me know if that’s wrong), I’ve got a bit of information that might be useful!

First, Misty’s ToF sensors work best under electric, indoor lighting, when they’re detecting dark-colored objects in an environment that isn’t overly bright. You’ll typically see more errors in your data in bright lighting with brightly colored objects, like when you’re using Misty in a room with lots of sunshine and trying to detect the distance of a bright white wall with lots of glare. All of that’s just to say if you’re in a bright place, you’re more likely to see erroneous data.

Second, there’s an issue with FEP prototypes where the ToF apertures in the bump sensor covers can interfere with the ToF sensors, causing faulty readings. We’ve addressed that issue in the design for production units, but in your case you might try removing the front bump sensor covers and testing again to see if you get better values that way.

Also good to know: Distance values become less precise the further away Misty is from the object, with distances outside the ~1.2 meter range being too far away for the data to be very reliable. If you try bringing the object you’re detecting closer to Misty, do the readings get more precise?

And finally (promise), we’ve added a status field to the TimeOfFlight message in today’s system update. This field returns a code that can help you determine whether a measurement is valid, and if it’s not, it gives you a clue as to why. We just deployed that release earlier today, so it may not be available in your region for up to 48 hours. Once it is, I’d be interested to see what your status codes read :slight_smile:

I would like address “toffr” over population the callback. Well it is a bug in the current architecture. Since all the ToFs are subscribed by one event and each ToF update the event individually - > Even on a super low debounce only the last update reaches the skill which happens to be “toffr” in most cases.
Workaround: I normally create an event for each ToF and they work great!


Thanks, @Ben and @johnathan! Yes, I believe I’m working with a Misty II FEP prototype (is there a way I can tell for sure?). I’ve been doing the majority of my testing in an office which has a mix of both artificial and natural lighting. Now that I know the ToF sensors are more sensitive to bright light with brightly colored objects, I’ll try and keep the lighting consistent and avoid bright spots/objects when possible during development and calibrate (via my own code) against these optimum conditions.

Thanks also @johnathan for letting me know that the ToF aperatures in the bump sensors can get in the way of correct readings…I’ve noticed that occasionally and will remove the bump sensors when they’re not needed in development. Also that note on >1.2m distances for ToF readings is very helpful…I’ll just filter any data above that threshold since it’s not critical for what I’m working on anyway.

My Misty II prototype just updated this morning and I’ll immediately put the new status filed to good use…sounds perfect for what I’m working on now.

@cp_sridhar Thanks for letting me know why “toffr” is over-populating the callback…makes complete sense and I figured it was something like that after seeing how all the other ToF sensors were barely making it through “toffr”'s noise. I’ll update my code with the workaround you mentioned…thanks for that!

Just FYI after the latest ( update, it looks like the ToF sensor data is stuck showing the same distance for the Right Front, Center Front, and Left Front ToF sensors…showing 8.191 m, 1.091 m, and 8.191 m, respectively. I’ve tried power-cycling the robot and still get the same data. The back (toF_Back) and downward-facing sensors don’t seem to have this issue.

Strangely enough, the Command Center also no longer allows realtime manual driving EXCEPT for driving backwards. I’ll continue investigating, but do let me know if you’re seeing the same thing on your end.

1 Like

@michaelrod , can you tell us what the error codes for front TOFs are? Especially left and right. My guess is they are in an error state from not booting correctly. There is a chance if you power cycle it a few times you’ll be able to get them to come up.

As for the driving only backward, since those TOFs are in an error state, they are throwing a drive hazard, meaning the robot doesn’t want to drive forward because it can’t tell what is there. So the drive issue is related to the TOF issue.


Yup, you were absolutely right…error code 207 (WrapTargetFail) was being thrown by those 3 sensors. I power cycled again and the sensors are up and running fine. Thanks @steven !

@steven Sorry, I spoke too soon. There’s still something very off about the front ToF sensors after the update, at least in my prototype. Every time I power cycle, the front sensors seem to get stuck at some seemingly random value, sometimes all 3 around the same time, other times the right will get stuck and the left will flip between a real value and something else like 8.191 m. They’ll still send back a status of “0” but not update…they simply send back the same value each debounce cycle. Here’s a quick sample I just took:


This 8.05 meters is currently what is being cycled out of the robot and it doesn’t change, regardless of what’s in front of the robot.

Pretty strange…I’m available for debugging if you need.

@michaelrod could you grab a “diagnostic report” from your robot (instructions here on how to do this, it’s just a .zip with your robot’s log files and device information) and attach that downloaded .zip in an email to I’d like to get this in our ticketing system and have data to dig into and share with the team.

Our staff’s presence on the forums is likely to be spotty for the next few days with lots of folks out for the long weekend, but I’ll keep you posted here when I can get some debugging steps to share.

@johnathan No problem…just emailed the ZIP. So you can get an idea of what’s happening, here’s a quick view into my Sensor Data in the Command Center:


Notice the Right Front and Left Front sensors are stuck, but all other ToF sensors are reporting correctly.

@michaelrod, I have one robot here that has a bit of an issue getting those tof sensors sorted on powerup. I’ve been digging into the issue with it and will hopefully stabilize it soon. It does appear to only happen on the occasional robot and I’m as of yet unsure what conditions are required to get it into this state. I have the firmware written to try to autorecover these sensors in the case they stop responding, and I did note that after a few minutes of it staying powered, the robot with the problem was finally able to recover the sensors and it worked reliably from that point on. If you let it stay running for several minutes, does it recover?

@steven I’ve left this robot running for a couple of hours now since the last reboot and it looks like the right and left front sensors are still stuck on the same values you see on the image above. All the other sensors seem to be working correctly.

@michaelrod just to verify, previous to the update you just did, the sensors were returning values, just not accurate values. Is that correct?

@steven Yes, before the update the ToF sensors were returning values which were usable, although just didn’t seem to be matching the units (meters) that I was expecting. But the ToF sensors were working normally, including the two (front right and left) that are having issues now under the new update.

@michaelrod, we’re interested in finding out whether a) your sensors are regularly reporting values, and those values just happen to be the same unchanged distance values every time, or b) your sensors are only reporting values once, and they are not updating in the UI because you are not getting continuous data back from the sensors. Could you dig into this a bit more for us? You can check the above by following these steps:

  1. Connect Misty to the Command Center
  2. Check the boxes to subscribe to the ToF sensors that are reporting erroneous data
  3. Open up the web console in the Command Center browser window (if you’re using Chrome, the keyboard shortcut is * Ctrl + Shift + J (Windows/Linux) or Cmd + Option + J (Mac).
  4. Look for new messages from your ToF sensors. If the sensors are continuously reporting values, and those values are the same each time, you might see a red badge next to each message with an incrementing value, showing you’ve received a new message with exactly the same data as the previous message. If you’re not getting updated values, you’ll just see one message from the sensor in your console that shows the erroneous distance value reported in the UI.

Thanks @johnathan …I originally did this same thing multiple times to try to find out what was going on and to verify the issue overall. It was always reporting the same “stuck” data for both the front left and right sensors, and occasionally for the front center sensor as well.

I’ve had Misty turned off for a few days now and finally today, low and behold, when I did the same test as you listed above, the front left and right sensors are working normally! I can’t be certain that having the robot off for an extended period helped, but it was the only distinct factor between this test and the last.

If you don’t mind, I’m going to keep testing these front sensors over the next day or two to make sure the issue is truly gone or if it comes back after more extensive usage and I’ll get back to you here with the results.

Thanks for following up – and while it makes debugging a bit more difficult, I’m glad your sensors appear to be working as expected. :slightly_smiling_face: And please, do continue testing. I’ll keep an eye on this thread!

@johnathan So far I haven’t run into the issue again and I’ve been working with the robot for about 24 hours now, both in development and just general usage. I have no idea how the issue got solved apart from the robot being turned off and unplugged for a few days. I guess I’m at a loss here…happy that the issue is fixed and I can continue development work, but frustrated that I wasn’t able to help track down where the issue came from in the first place. If it does happen to pop up again, I’ll definitely update this thread.


I’ve noticed the issue creeping up again, this time with the back ToF sensor. All other ToF sensors are just fine. Restarting the robot doesn’t seem to help, like last time, but I haven’t tried turning Misty off for more than several hours to see if that helps again.

Here’s what I’ve seen this time around: The back ToF sensor will work for a small amount of time, usually just a minute or two, after a restart and then get “stuck” on some value and keep reporting only that value until I perform another restart. Here’s an example I just pulled out of the console:


Note the status is 0 like last time showing no apparent error, but the sensor will continuously report 0.384 meters until the next restart of the robot.