Question Unity as a platform to control medical devices

Hi there,

I am wondering if anyone has any expericnes with using Unity as a platform to control a medical device and had to deal with regulatory and risk management of using Unity e.g. Unity controlling a robot that is attached to a human for a medical reason.

I would be glad to hear from experts esp. those in the human-robot interaction field.
Cheers,
HM

 

You need to be more specific, what kind of robot equipement.

Surely you don't want to use for surgery type of equipment, where life is at stake.
No one will guarantee safety.

But Unity was successfully used as an interface in various of industries.

 

Thank you. It is not yet surgery but it is more of medical treatment either remote or in person using a robot. My question is whether people have used Unity to actually control a robot to do medical procedures or treatment (less invasive than surgery). And if so, have they gone through regulatory and safety-related checks e.g. MDR (medical device regulation), or similar regulatory bodies?

I know people use Unity to control their robots or other devices. The question is: has anyone sold a medical device that only uses Unity as its platform?

 

You know, there's a small problem:
https://unity.com/legal/as-terms

Now, this is related to asset store and unity itself does not have such clause.

However, as a rule of the thumb I would not use unity to implement any system that can cause bodily harm, destruction or kill somebody if it malfunctions.

The risk is too high.

Also, read about this:
https://en.wikipedia.org/wiki/Therac-25

 

Unity has an consulting site that comes close at least:
https://www.unity.de/en/industry-solutions/medical-technology/development-of-medical-devices/

When it comes to robots, the requirements are strict but you can differ between firmware and the controller. During my master thesis at a start up company we were working on a robot controlling/programming system that was web-app based (and which we delivered to real customers). Definitely not "safer" than Unity.
However besides caged-off large robots, we used so called collaborative robots. Those have force sensors integrated which are realtime coded in the firmware that ensure that the robot cannot apply a harmful force.
Then the controlling software does not need to fulfil just as strict requirements. It was not for medicinal purpose, but those setups were at least allowed to run in "touching range" of humans (hence "collaborative").
There are collaborative robots for medicinal purpose out there but naturally they come with a price tag.

However if you plan to develop your own device/robot for this, then you'll have to fulfill said safety regulations (which is very hard if you don't have millions to spare). Controlling the servos of such a device very directly through Unity would most likely not be aproved. Probably not even Arduino (which is realtime at least, but has the stigma of being for hobbyists).

 

Many thanks, everyone for the detailed and great information here. So the logical way of doing it is to develop the game in Unity and build another e.g. Software that controls the robot while using the game outside the Unity engine in that Software.

 

Usually for robots you have microcontrollers driving the electronic components, on the low end side something like esp32's, raspberry pi's, or a variety of embedded boards, which you wouldn't use Unity for. You could use Unity for a management console on a computer that communicates to the microcontrollers over wireless (wifi, bluetooth, radio, satellite)

But you could also use react/angular or whatever other tech if it's just a UI management console, you'd use Unity if you wanted to have game like assets and gameplay. Or a game that integrates with your robot/custom hardware somehow.

 

Yeah, I strongly recommend only using Unity as a client side interface to talk to the devices. Design the actual devices using microcontrollers. I don't even run an operating system in embedded designs. A low cost microcontroller running natively compiled code directly on metal is the most reliable solution.