Robot Not a Dev? Buy Now
Not a Dev?

Misty Community Forum

Do my time-of-flight sensors need cleaning?

@johnathan, the number of the right front sensor stays at 8.7m, and it never changes. Do you think this could be fixed by cleaning?

It’s a good practice to clean Misty’s time-of-flight sensors on a regular schedule, but we’d need more information to determine whether that’s causing your readings. Misty’s time-of-flights are pretty powerful sensors and are highly sensitive to environmental factors like floor surface type, glare, and angle of approach.

I hope you don’t mind that I’ve split your response from the Known Issue topic into a new dev support thread. We’re actively tracking ToF issues in order to improve the developer experience over the next few weeks. When you have time, your answers to the following questions will help us determine the root cause of the issue:

  1. What type of floor(s) are you working on?
  2. Describe the lighting in the room (i.e. windows, time of day, room lighting)
  3. How are you sending drive commands (app, command center, APIs)?
  4. Have you done a visual inspection of ToF covers (for scratches, dust, etc.)?
  5. Does the problem persist across power cycles?
  6. Have you tried disabling / modifying Misty’s base hazard settings? If so, does that solve the problem?

You can also send an email to support@mistyrobotics.com with the following attachments:

  • Diagnostic Report
  • Pictures of the environment(s) where you are encountering the issue
  • Video and/or screenshots of ToF sensor data from the Command Center

Note that the contents of this email may be distributed across the support & engineering teams for troubleshooting

In a few rare cases we’ve also seen connection issues with the ToF sensors, which can be resolved by removing some of Misty’s base panels and checking that the ToF connection is secure. (We can provide detailed instructions on how to do this if that seems to be the issue with your robot.)

I have tried to put Misty on different surfaces, like table (smooth white surface) and carpet (dark grayish color) using room lighting during day (cloudy recently). I tried to place the obstacles around it. The other ToF are changing numbers as the position of the obstacles change, but the right front one stays at 8.7m. I’ve tested it with both command center and Rest API. The issue persists across power cycles.

Though I have not done #4 and #6.

Thanks for the quick follow-up. When you connect Misty to the Command Center and check the time-of-flight readings in the Sensor Data section, which “status code” do you see for that front-right sensor?

A reading of 8.7 meter suggests you’re using very old firmware. That value indicates the TOF is in some error state (In this case “Wrap Target Fail” ). Are you running a Misty 2? It would likely be beneficial in troubleshooting to update to the latest firmware, depending on which robot you have.

Having said that, doing #4 (a visual inspection) would help, because if there was a big enough spec of dust or a hair or a scratch on the cover or the sensor, that could be enough to cause this problem.

@steven We are using Misty 2. I tried system update before, and it did not work, so I did the target update instead.

I tried the system update just now, and it fails with the following message in console:

"System updates started, please wait. Your robot may restart multiple times during this process.
VM14:1 GET http://192.168.1.213/api/system/updates 503 (Ignoring request, robot is updating.)
(anonymous) @ VM14:1
FetchClient.GetCommand @ fetchClient.js:57
checkSystemUpdatesAvailable @ commandcenter.js:538
fetchClient.js:69 Get Response Error: undefined
"

never mind. seems the update is done. but now a lot of the sensors stopped working:

As you can see, only the Front and Back returns data.

And it’s getting worse. Misty displays a message: “Hardwre heartbeat failures. Restart robot and contact support if issues continue”. I’ve tried restarting twice:

Thanks for this update. Could you send an email to support@mistyrobotics.com with a Diagnostic Report attached? That will give us access to your robot’s log files, and we can dig into next steps for troubleshooting from there.

I cannot download the log file. In the console, it says:
“Running and retrieving diagnostic. This could take a minute or two.
VM743:1 GET http://192.168.1.213/api/logs?Date=2019/12/3 409 (The handle with which this oplock was associated has been closed. The oplock is now broken. (Exception from HRESULT: 0x80070323))
(anonymous) @ VM743:1
FetchClient.GetCommand @ fetchClient.js:57
(anonymous) @ diagnostic.js:71
setTimeout (async)
(anonymous) @ diagnostic.js:67
GetLogs @ diagnostic.js:65
setTimeout (async)
(anonymous) @ diagnostic.js:25
dispatch @ jquery.min.js:2
y.handle @ jquery.min.js:2
fetchClient.js:69 Get Response Error: undefined
4diagnostic.js:81 Logs received
diagnostic.js:177 Creating and downloading report …
diagnostic.js:81 Logs received
diagnostic.js:103 result: {heartbeat Enabled: {…}, imu State: {…}, rt Temperature: {…}, mc Temperature: {…}, toF Range Right: {…}, …}
diagnostic.js:81 Logs received”

I do see the result from the console. Is it fine to attach the result to the email?

Yes, that should work. We’ll do some investigating to see if we can find what’s causing those errors.

Another quick question: When you scroll to the bottom of the Command Center web page, what information do you see in the footer? (It should display a timestamp with yesterday’s date, like this):

yes, i see “Last Updated: 12/2/2019 5:47:04 PM”

Thanks! I’ve just received & replied to your email.

@fishbb @johnathan I bet the problem is that the robot updated the head but not the lower level firmware. That is exactly the behavior I would expect if that happened. I think what we need to do is:

  1. Go into command center, open up the console (CTL-SHFT-I) on windows, not sure what it is on Mac. Then click on the button at the top that says “Get All Device Info”. You should get back a message in the console that shows device information. There is an arrow next to hardware, and in there you should see RT and MC boards and the version numbers for both. Then a bit further down you should see version numbers for the head. If you can get a screen shot and show us that would help. If they aren’t in match then we’ve found the problem.

  2. IF they aren’t in match, then we need to do another targeted update of any of the things that don’t match the software version. When you do the targeted update, watch the display on the robot and see if it says its successful or if it fails.

Try that first and lets see what happens. We can keep working from there.

1 Like

@fishbb Let us know what the results are when you have a chance to check your robot’s firmware versions as @steven has described. We’re eager to get your robot back on track as quick as we can :slight_smile: