Thoughts on MiR?

We bought a MiR for a customer last year, and I spent some time integrating it. I also met another engineer that integrated one in his plant.

Before I spill all my thoughts out in the open, has anyone else had experience with these?

Firstly, they're not designed for an industrial environment. Secondly, it's a programmer's nightmare.

Thirdly, they're not safe.

(1) The only two interfaces are RESTful and Modbus TCP. REST is only going to be useful for server and web applications. And Modbus is sporadic and handicapped. I was able to write my own logic for Allen-Bradley to interface with Modbus**, but couldn't get certain data registers to read, couldn't write registers in bulk, and had to slow my cyclic message rates to once every 5 seconds. Any faster, and the Modbus would lock up on the MiR and only a reboot would bring them back up. Eventually, I found rates that wouldn't brick the Modbus. They've been working well, albeit slowly.

I sure wish there was EtherNet/IP...

(2) The web interface is pretty. But not designed for usability. And there is no alternative interface.

Want to make a program? Click a menu button. Then click another menu button. Then another button, then another. Okay. You have the first command in place. Now scroll to the next command, rinse and repeat.

(3) Do you like nested IF/THEN loops? Then you'll LOVE MiR. That's your only option for 'complex logic'. There is no boolean expression.

(4) Want to view your MiR data (registers) on the web interface? There is no 'read only' field. Only a Read/Write field. You can add a button to show you a register's value. But that button MUST have an action assigned that also writes a preset value to that register. (facepalm). You'd better have a register that continuously rewrites itself, in that case. Which... you can't cyclically do unless you have an external device writing to that register... which leads me to the next point:

(5) There are no background tasks. You get tasks (programs), and they're able to call other tasks. But you can't run any tasks in parallel. All tasks and program commands are sequential-only.

(6) Mission buttons (aka tasks) are all the same color. Seems pretty basic, but when I have 5 missions on a dashboard, I'd love to color-code them.

(7) When moving from point A to B, the robot has a set number of recursions it will run before it gives up. Is something in the way? Too bad. There's no audible alert. It'll just sit and wait until it expends its retry allotment. And then the task pauses with an error.

Note, there are 'try/catch' program elements... I haven't used this yet, but it may help here.

(8) like recycling code? Great! We can use subroutines!. Like to see where you're at in that subroutine? Too bad! You can only see the top-level program's status.

(9) Want to pass arguments into a subroutine? For example:

Call PickAndDrop(PickStation, DropStation)

where PickStation and DropStation are PLC registers.

You're going to be disappointed. You can't pass arguments into a subroutine.

"Okay. Fine", you say, "I'm a skilled programmer. I know ways around this. Let's try global instead of local data:

(10) Want to move a variable (register) from one register to another

Set [PLC Register B] to [PLC Register A]

Simple, right? Too bad this logic isn't available.

Okay, how about this?

Set [someVariable] to [PLC Register A]
Set [PLC Register B] to [someVariable]

Nope. Can't do that either.

(11) Want to monitor a register? You can do this:

Wait [PLC Register A] = 5

Want to make it a little more useful?

WAIT [PLC Register A] = [PLC Register B]

OR

IF [PLC Register A] != [PLC Register B]

OR

WHILE [PLC Register A] <= [PLC Register B]

Oh... snap. Not possible.

(11) You can add user groups. They're pretty easy to setup. Want to have an alert to an operator show in the web interface? Great!

PROMPT ["some message"], [User Group]
PROMPT ["another message"], [Maintenance Group]

Want a message to show for everyone? Prepare to be disappointed. Only one user group can see the message.

(12) SLAM is not dependable. It does a decent job with odometry (localization with the internal sensors), but it does a subpar job in keeping localized.

(13) Poor SLAM means poor docking. Poor docking means your'e likely to miss your charger contacts. Which means you'll have (1) errors that stop production and (2) a dead robot in a few hours.

**The next few are regarding ROEQ more than MiR... **

We have a ROEQ lifting dock attached to the MiR. In order to dock, the lifter must be in a lifted condition. The robot then approaches the dock, locates it with the VL marker (a bent metal plate easily distinguished with the area scanners), aligns, and pulls in.

(1) The robot poorly aligns with the dock. Even after following the calibration procedures, the robot is often offset by an inch or more as it docks. This means that the items it picks up shift slightly every time you pick/drop, and eventually can walk off the edge of the robot, or hit the dock in such a way that they get pushed off the robot and onto the floor.

(2) Upon undocking, the area scanners are disabled. This means the robot doesn't look behind it or to its sides while undocking. It'll plow right into anything in is path.

(3) remember that SLAM isn't great? Well, add a dock into the mix and you have BIG problems. Since area scanners are bypassed while docking, a poor SLAM localization means that about every 20th dock results in the robot mis-locating the VL marker, and it plows right into the dock. Your precious cargo is now on the floor, BTW.

** If anyone is interested in this logic, PM me. I'm happy to share. But I still can't recommend using it.

On a positive note:

(1) the speaker is very loud.

(2) The lights are pretty.

(3) The GUI is nice.