Robot Engage Blog Buy Now
Blog

Misty Community Forum

Moving Misty in a straight line and back

I need some help in understand Misty’s behavior. I wrote a kindergarten skill to move Misty forward 1m and then back 1 m. Here is the code…

misty.DriveHeading(0, 1, 4000, false, postPauseMs=4000);
misty.DriveHeading(0, 1, 4000, true, postPauseMs=4000);

I run this skill a few times and the behavior is different each time. Rarely, will it come back to the spot is started from. It does follow a straight line always. Sometimes it moves forward but never comes back. The room is clear of any obstacles. Any thoughts? what should I be doing differently?

Sanjay

PS: I am running the latest updates from earlier in teh week.

Here is some additional data that may help – The Back TOF sensor is showing signalfail and a .387m reading. Misty does better if I disable the all hazards.

Hi Sanjay,

Thanks for sharing your post. If you don’t mind, I have a few follow-up questions that could help us troubleshoot:

  1. Did you get a chance to test this skill before Misty took the latest update? If so, did she behave any differently?
  2. Are you seeing any error messages on Misty’s display (a “Hardware Heartbeat Failure” message, or something similar?)
  3. What type of floor(s) are you working on?
  4. Describe the lighting in the room (i.e. windows, time of day, room lighting)
  5. Have you done a visual inspection of ToF covers (for scratches, dust, etc.)?

That your skill performs as expected when you disable hazards would indicate you’re getting false positives that prevent Misty from backing up. The SignalFail status code is fairly innocuous, and isn’t likely to be the culprit; that status code indicates the sensor isn’t getting enough “pings” back to get a valid reading, which typically happens when an obstacle is too small or too far away. My understanding is that SignalFail code in and of itself doesn’t trigger the hazards system.

Misty’s time-of-flight sensors are powerful hardware but do perform differently depending on Misty’s environment. (I know from reading other threads that you’ve been testing in a few locations. :slight_smile: ) Debris like dust or pet hair can also accrue on the sensor covers, which could interfere with getting accurate readings. It’s a good practice to regularly clean the ToF sensor covers by blowing them clean with low-pressure compressed air.

The “sweet spot” for accurate ToF readings is within ~1.2 meters of the robot; as distance values get larger, the readings become less reliable. That said, certain environmental conditions can trigger false positives in the hazard system, even when obstacles are well outside the 1.2 meter range. We are working to provide more tools and better educational materials to support developers who want to understand the sensors better and dig in when they’re not behaving as expected. Some of this information should appear in the forums within the next few days.

To try and pin down the reading that’s preventing Misty from moving, you might do the following:

  • Try connecting Misty to the Command Center and subscribing to time-of-flight data before you run the code you shared above. Make sure Misty’s hazard system is set to its default settings. Watch the readings as your robot drives, and if Misty doesn’t move as expected, check to see if the distance readings are accurate.
  • You could also try running the skill while streaming event messages from the HazardNotification WebSocket connection. When Misty doesn’t drive, this message would tell you exactly which hazard state caused her to ignore the locomotion command. A quick way to stream HazardNotification data is by using a tool like Simple Websocket Client.

That is correct on the range sensors. SignalFail by its nature can’t be a range hazard in front of it.

1 Like

@guptahome100 I’d be interested in knowing…if you sit the robot still on the floor and watch the rear sensor…do you see the values jumping around a lot? Does the status ever read RangeValid while the distance is less than the hazard threshold (default 150 mm)? I am trying to understand if there is a lot of noise on that sensor. You might have to watch it for 5 or so minutes just to understand how it is behaving.

1 Like

Jonathan,

Thanks for the detailed reply. Here are the answers…

  1. The behavior did not change after the software update.
  2. No error messages on console.
  3. Hardwood and carpet. No change. Also, the behavior is a bit random in that it moves forward 1m but how much it goes back is statistical in nature.
  4. LED Lighting, 5000K, ceiling. Not overly bright.

On the back TOF sensor, the reading seems to be fine and steady – for example, I just ran the skill, it moved forward 1m and then tried backing, but stopped. It shows I am .99m from the wall…

I set up Hazard notifications… The one triggering is TOF_DownBackRight (I used code from Misty Docs | Event Types).

sitting still on the floor the back sensor reading is still and accurate.

Sitting still on the floor, what is the back right edge value doing? Is it bouncing up and down a lot? Is the status showing something other than rangeValid? Anything seem suspicious about it? Do all the sensors do it, or just the one?

It (Down Back Right) seems to be steady around .03 but then I noticed that it jumped to .25 and recovered quickly… But I can not see that again. The value seems steady, but the hazard is getting triggered. I noticed BTW, the hazard kicks in before it moves forward, but gets cleared…

With the robot sitting, the hazard notifications come and get cleared. So that seems to be the cause of the issue. Not sure what is triggering it though – the TOF sensor seems to be steady – just when I write this i see a .1 reading

Any further thoughts on how to rectify the issue? If not I plan to turn off the hazards and just be careful.

A few of us have been working on a troubleshooting guide with steps to remove Misty’s track covers and make sure the ToF sensor connections are seated correctly. This is rare, but not impossible, and if you’re comfortable disassembling your robot’s base (you just need a screwdriver), it is worth giving a shot.

That information will be posted to the forums eventually. It’s not ready yet – still in draft form – but I will email the instructions to you privately in a few moments.

sure… not an issue. I did that with the front sensor last time. I have been thinking that there may be a need for some filtering/smoothing of the TOF data. Based on what I see, the bad readings come infrequently and only for a fleeting moment – they do not even register on command center always.

@guptahome100 can you send me your most recent logs? I feel like the behavior changed since we saw them last time (last time you couldn’t drive forward).

yes, they did. Remember, I got new hardware… I will send the logs in a bit. Seems like a noise issue to me on the sensor. A low pass filter should be able to fix it.

I have experimented with LPF on the ToF data, but I’ve been hesitating to push it out to the user because it results in a slower response to an actual edge condition. If we did that we would have to cap the drive speed to a [slightly] lower speed to ensure it won’t drive off a tabletop or stairs.

Having said that, it is still on the table, but we’ll have to get Product to sign off on it as it does affect everyone’s robot’s top speed…unless I can convince the right people here to make it an adjustable feature. We’ll see.

Let me know if I need to voice it to the appropriate leads. It depends on the sampling speed etc. Just curious - is it in STM part? It is just a nuisance at the end since Misty can not get to where it needs to go everytime. Maybe there is a way to restart the old skill from where it was interrupted when the hazard kicked in…

I will say that this problem of it not consistently driving is the #1 priority for me at the moment. I’m spending every available minute working on it. We are looking into everything from the electrical system on up to FW and above. We’ll get it working.

I do agree with Johnathon that you should go ahead and try reseating the connector, just in case.

Right now the move (at the FW level) cancels entirely once a hazard triggers. I think it might be worth investigating a slight tweak of your idea, and instead of cancelling the move in a hazard, I could just pause it, to be restarted once the hazard clears (if it does). This would result in a momentary blip in the move in the case of false hazards, but the move would finish still. That and the LPF could be pretty effective in removing a majority of these false hazards. I’ll spend time this weekend thinking about how to implement this and then I’ll have a meeting with the necessary people at work on Monday.

1 Like

I agree with your proposal Steven. I am sure, we will be able to get it working. I like the pause concept a lot. Does not compromise safety and also lets the tasks get completed.