Misty Community Forum

2019.11.05 System Update

Greetings, Misty developers!

We’re excited to announce Misty’s next system update. Among other changes, this update adds endpoints to Misty’s REST API for temporarily disabling functionality that uses Misty’s 820 processor. You can use these endpoints to free up memory on the 820 for tasks that require a lot of processing power (like simultaneous localization and mapping).

Additionally, we’ve given Misty a new default behavior such that she ignores all commands when you touch the handle on the back of the head. Put differently, Misty now “goes limp” when you pick her up, so you can carry her without damaging her motors (or risk getting injured yourself) – even when she’s in the middle of running a skill.

Be sure to read the full list of changes below, and reply to this thread if you have questions or concerns. Thanks, as always, for being one of Misty’s first developers. Your feedback shapes future of robotics development platforms, and we can’t wait to hear what you think!

Installing the Update

Misty receives software upgrades as over-the-air (OTA) system updates. This update will be available within the next 24-48 hours (the precise timing varies by region).

Misty automatically checks for new updates each time she boots up. As long as her battery has enough charge, she automatically installs any updates that are available. If your robot doesn’t start to install this update the next time she boots up:

  • Check that Misty is connected to power or sitting on her wireless charging station.
  • Try connecting Misty to the Command Center to make sure she’s connected your Wi-Fi network.

If Misty is charging and connected to the internet, you can check whether the update is available in your region by connecting Misty to the Command Center and looking at the System Updates section.

Note: Misty reboots once during a system update. All commands except Halt and Stop are disabled while Misty is updating. If Misty starts installing an update while charging, do not remove the power source until the update is finished and Misty’s eyes are fully open.

If you have issues with a system update or need technical assistance for other reasons, for the quickest response you can:

  • Post a message to the Support category here in the Community forums.
  • Contact the Misty support team through the chat embedded in this site, or by emailing support@mistyrobotics.com.

Release Contents

Note: This system update is only available for Misty II robots. Misty I robots will not be updated with this release. If you are a field trial developer with a Misty II prototype, you can find the firmware and software version numbers for your robot in the Field Trial section of the Community Forums.

  • Misty II - Updates
    • Window IoT Core OS version: 10.0.17134 or higher - No updates
    • Android OS: (8.1) - No updates
    • Robot Version:
    • MC Version:
    • RT Version:
    • Sensory Services App Version: 1.5.3
  • Web Based Tools - Updates
    • Major changes listed below
  • Misty JavaScript (VSC Extension): 1.0.1 - No updates
  • Misty App - No updates

New Features

  • By default, Misty now ignores all commands she receives while her CapTouch_Scruff sensor is active. This sensor is located in the handle on the back of Misty’s head, and the intent of this behavior is to prevent Misty from moving in ways that could damage her (or the human holding her) if she’s picked up while running a skill. This behavior does not cancel any running skills. It only causes Misty to ignore commands those skills invoke. When the scruff touch sensor is released, Misty again executes any new commands she receives.
  • Misty’s REST API now includes operations for disabling (and re-enabling) the camera, audio, and simultaneous localization and mapping (SLAM) services that use Misty’s 820 processor. Disabling a service prevents the system from running commands belonging to that service, which frees up memory for activities that require a lot of processing power (such as mapping or tracking). As an example of how to use this functionality, you might disable Misty’s camera and audio services before you start mapping or tracking to improve the performance of the SLAM service. To see which commands belongs to Misty’s audio, camera, and SLAM services, see the reference documentation for each new operation:
    • DisableAudioService
    • DisableCameraService
    • DisableSlamService
    • EnableAudioService
    • EnableCameraService
    • EnableSlamService
    • GetAudioServiceEnabled
    • GetCameraServiceEnabled
    • GetSlamServiceEnabled

Bug Fixes & Improvements

Misty II


  • Fixed bug that had decreased Misty’s max arm movement speed to about half of what it was prior to her 2019.10.08 release.

Web Based Tools

Command Center

API Explorer

  • Added missing descriptions for several commands, and improved other descriptions to match what is published in the developer documentation.

Known Issues

New known issues with this release are listed below. For the full list of issues we’re actively tracking, see the Known Issues section of the Community forums.

  • Calling the misty.CancelSkill("<SkillID>") method cancels the skill from which the command was called, as well as the skill passed in for the first argument.
  • In a few rare cases, we’ve seen Misty take pictures with her RGB camera that are fully black or underexposed. We’re still investigating the issue, and if you come across this behavior, please let us know. Learning about your experience could help us find the root-cause.

Thank you for the update!

My team has found that today the arms have a bit of a bounce-back when they reach their topmost and bottommost positions. This could just be our Misty, but maybe someone else has noticed it?

Thanks @madeleine.duke – I’ll ask the team about this today. Is it safe to assume you didn’t notice this behavior before Misty installed this update?

No problem! Yes, it seems to be new since this update - we’ve been working on the dancing mission for our HRI study and we didn’t see this before today (although possibly it’s just been exaggerated with the new speed?).

what are the metrics that are used to evaluate “performance” in your statement?

intuitively I might guess that more memory or CPU time allows the map to be built more quickly or localization to converge more quickly, but does it affect correctness or reliability?

After chatting with the team, it sounds like the overshoot you’re noticing is expected behavior. It is likely to be more pronounced when moving the arms at higher speeds – which is probably why you didn’t notice it before Misty took this update (which includes a fix for a bug that had decreased the max velocities of Misty’s arms.) We are planning improvements that will reduce overshoot in the future, but not they’re not likely to be released soon. That may change if we get a lot of feedback asking for this from the community, so be sure to add it to the Wishlist category :slight_smile:

Excellent question. I’ll ask those closer to Misty’s SLAM and other Android services and see if I can provide you with some more useful specifics.

SLAM is inherently very expensive (as in we can’t process all the data we get from the sensor). By stopping some of the other services SLAM will get more memory (which means maps can be a little larger before stopping), and more CPU and I/O resources. Also, due to Android having a terrible scheduler (or a least a scheduler optimized for phones not robots), having fewer services means less contention on resources.

Honestly though, most SLAM performance issues right now are due to a bug in the Android 8.1 OS USB stack that we’ve been tracking which can cause severe latency spikes on the sensor stream. We’re working on an OS update to address this.

I wish there was an easier way for me to know if I have the latest update. Some of my robot software version numbers don’t match what’s in this post but they’re pretty close. I checked command center and I seem to be up to date.

Would it be possible to add the System update name to the misty software data? For example you can add a row in the app that says System Update Version and the value would be 2019.11.05. (if this is the naming scheme the team plans to keep using moving forward.)

What do you mean they don’t match? Can you post the versions? If the first 3 numbers of the version of the SensoryServices, RT and MC Firmware don’t match that of the Robot Version, you can do a targeted update to try to force an update and see if there are any errors. I assume you have a production robot, otherwise there may be some incompatibility.

1 Like

I hope that after this week’s release your version numbers match those published in the 11.20 release notes :slight_smile: You can also check the Release History section of the documentation to get the version numbers for the current release. If your robot has successfully installed the update, I would expect the version numbers to match exactly what’s published (instead of just being close). If that’s not the case, you may need to trigger component updates like Vlad suggested , or we published incorrect version numbers. Either way we’d want to dig in and see what’s going on.

I do sort of like the idea of exposing a name for each release in the robot’s device info. I’d encourage you to share that idea in the Wishlist category so that other community members can vote on it!

I’ve been chatting with our team about this. It turns out we recently modified an element of how the robot generates the version # for RobotVersion. For the 11.05 release, RobotVersion should be We failed to catch that for this release announcement, and until today, none of Misty’s developers have pointed out the discrepancy. I’ve updated this release announcement accordingly – thanks for catching this and helping us improve our processes!

1 Like

Robot Version:
Sensory Services Version: 1.6.2
Windows OS Version: 10.0.17763.253

My robot version is higher than this!

Looks like you’re up-to-date. Those match the 11.20 release :robot:

1 Like