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

Misty Community Forum

Exact `EventCondition`s for IMU subscriptions

hi, i can’t for the life of me figure out what the exact event conditions are for IMU subscriptions. can someone please direct me to documentation on where i can find this info?

additionally, if you have all event conditions you guys use in command center, that would be super useful as well.

thanks,
adam

Thanks for posting this here @adam.cushner!

It sounds like you’re interested in filtering IMU event messages to get back data just from a specific property. If that’s the case, I believe we don’t actually do this in the Sensor Data section of the Command Center. My understanding is that when you check a box for IMU data, the web tool sets up a single subscription for IMU events, and in the callback function that handles those event messages, we determine which boxes are checked and populate those boxes with values.

You can, however, specify a ReturnProperty in the subscribe message you send when you open a WebSocket connection. For IMU events, the return property can be any of the properties in an IMU event message – yaw, roll, pitch, xAcceleration, etc. Use this to indicate that a message should only include values for a specific property (instead of returning all the property values). You can also specify EventConditions that filter out unwanted messages, e.g. "only send a message when the value of yaw is greater than 90".

Here’s an example of a subscribe message that would only have the robot send data back for the yaw property, and only when yaw is greater than 90:

var subscribeMsg = {
  "Operation": "subscribe",
  "Type": "IMU",
  "DebounceMs": 1000,
  "EventName": eventName,
  "Message": "",
  "ReturnProperty": "yaw",
  "EventConditions": [
    {
    "Property": "yaw",
    "Inequality": ">",
    "Value": 90
    }
  ]
};

When you write a JavaScript skill that runs on the robot, you can actually set up multiple return properties and property tests for the same event listener. You need to use the misty.AddReturnProperty() method to add return the values for each property you want data for (we typically do this at the same time we register for IMU event messages). In the callback function, we can access those values in the data.AdditionalResults array. The values for each return property are indexed in this array in the same order in which they were added.

As an example, here’s how you’d register an event listener that prints the value of the roll and yaw properties as a debug message:

function getIMU() {

    // Add return properties for each property you want data from. In
    // this example, we return values for yaw and roll.
    misty.AddReturnProperty("getIMU", "yaw");
    misty.AddReturnProperty("getIMU", "roll");

    // Register a listener for IMU events.
    misty.RegisterEvent("getIMU", "IMU", 1000, false /*<-change to true to stream data, instead of just getting it back once*/);
}
function _getIMU(data) {
    // Return properties you add come back in the data.AdditionalResults
    // array, indexed in the same order in which they were added.
    var currentYaw = data.AdditionalResults[0]; // current yaw value
    var currentRoll = data.AdditionalResults[1]; // current roll value

    // Stores the return values to Misty's local storage, to ensure
    // the data is available to other event callback functions.
    misty.Set("currentYaw", currentYaw.toString()); // Stores yaw
    misty.Set("currentRoll", currentRoll.toString()); // Stores roll

    // Prints debug message with yaw & roll values
    misty.Debug("currentYaw = " + misty.Get("currentYaw")); // prints yaw
    misty.Debug("currentRoll = " + misty.Get("currentRoll")); // prints roll
}

getIMU();

I’m not sure what your setup is, so let us know if you have more questions. The best place to find information about using Misty’s WebSocket connections is in the Getting Data from Misty section of the developer docs, though there is likely much that can be done to improve these. We’re eager to hear feedback, especially when you can’t find information you’re looking for!

thanks for the detailed response!

one detail is that command center does do individual subscriptions as you can see here.

the main problem is that i don’t know how to create an event condition that says something like “sensorName=yaw” or “sensorType=yaw”, i’m just not sure what to do to say only filter on that particular sensor.

additionally, i’ve been over those docs numerous times, the thing it’s missing, especially in the reference API info, is all the things about event conditions and their fields.

other additionally, i’m using my own python REST API which does support multiple event conditions and will soon support multiple return values as well.

looking forward to trying out, and thanks again for the detailed response.
adam

one other thing, other subscriptions do support using EventConditions to get what i’m talking about, such as Touch which uses sensorPosition=ChinLeft e.g., or others like ActuatorPosition that uses sensorId=ahp, e.g.

one detail is that command center does do individual subscriptions

Thanks for sharing this! Filing in my “today I learned” notebook :smile:

the main problem is that i don’t know how to create an event condition that says something like “sensorName=yaw” or “sensorType=yaw”, i’m just not sure what to do to say only filter on that particular sensor.

For each event type, you can apply event conditions on any of the properties returned in the message object:

// Sample IMU Event
{
    "eventName": "IMU",
    "message": {
        // You can apply event conditions on these properties:
        "created": "2019-01-09T21:47:53.7607457Z",
        "expiry": "2019-01-09T21:47:54.1607457Z",
        "pitch":11.193,
        "pitchVelocity": 0.057,
        "roll": 2.468,
        "rollVelocity": -0.1,
        "sensorId": "imu",
        "sensorName": null,
        "xAcceleration": 0.75,
        "yAcceleration": 0.73,
        "yaw": 2.004,
        "yawVelocity": 0.096,
        "zAcceleration": 9.80
    },
    "type":"IMU"
}

For IMU event messages, the value for sensorName and sensorId is always the same, as every IMU message comes from the same IMU sensor. So, if you just want the yaw value from the IMU sensor, you’d specify yaw as the ReturnProperty when you subscribe, instead of applying an event condition.

As you noted, this works a bit differently from other event types (like ActuatorPosition, TimeOfFlight, TouchSensor, etc.). Those event types stream messages from all sensors in a related group, but each message comes from a different sensor. Setting up a general subscription to these event types can result in a pretty messy stream of data – which is where using an event condition to filter messages by SensorName or SensorId is helpful. (When you don’t apply event conditions on these subscriptions, you may run into some tricky situations where all of the sensors are “competing” to send messages simultaneously, and one sensor “wins”/sends data more frequently than the others, as @cp_sridhar noted in this post).

additionally, i’ve been over those docs numerous times, the thing it’s missing, especially in the reference API info, is all the things about event conditions and their fields.

Thanks for this feedback. More detailed information about possible sensorId and sensorType values would definitely be useful, along with better descriptions of how to use event conditions on all of the fields in each message for an event type. I’ve added this to our backlog :slightly_smiling_face:

other additionally, i’m using my own python REST API which does support multiple event conditions and will soon support multiple return values as well.

Nice – is this what you’ve been working on here? Still need to check it out!

ah, thank you @johnathan! this makes total sense! IMU literally is one sensor with a bunch of different values coming off it, whereas the others are grouped. cool. return property definitely makes a lot of sense here.

and, i’ve definitely noticed that “competition” when subscribing to actuator position, for example.

also, yes, the link you have to the misty rest api is correct. it’s pretty solid, i use it all the time so whenever i encounter something, i just fix it. (which has become less and less these days - a good sign).

thank you!
adam

2 Likes