6 ms·

I don't want to be that guy but did they invent bluetooth for ai? Like what is MHS actually? I read it twice and still don't get it

storywatch 20d ago
More like MCP for robotics. IMO they are better off getting the robots to use existing human UIs than trying to get hardware manufacturers to play ball.
- tolugenius 20d ago
  Oh I see, yeah I guess this assumes manufacturers will just adopt this standard universally. Clears things a bit!
- written-beyond 20d ago
  That 2 trillion dollar valuation ain't gonna make itself.
- cookiengineer 20d ago
  What is the difference of MHS to MCP when it comes to features? The whole text reads like everything is just a gRPC call that could've also been implemented with an MCP based wrapper.
sheauwn 20d ago
It seems more like a basic instruction set, that will then be translated to something actionable for each different device. Seems like most of the work then will be in developing the drivers for whatever devices you want the LLM to access.
- ctoth 20d ago
  Yes, it turns the hardware driver problem into a translation problem (translate the hardware manual/datasheet into this protocol.) Guess what's really good/quick at translating things?
  - lefra 19d ago
    "Translating the datasheet into protocol <X>", is the essence of writing a hardware driver. Also my experience with hardware is that the datasheet is often incomplete or misleading. Most of the time is spend fiddling with the hardware to understand exactly what needs to be done, in what order, and sometimes with what delay between commands, to make the damn thing work reliably in the way you want.
tuvix 20d ago
In the context of lab hardware there’s a ton of proprietary software and barriers to automating things. I think this is less about how to communicate, and more guaranteeing that “yes, this piece of hardware can interface with an agent” and is meant to do so. Kind of like using MCP vs letting your agent make raw HTTP requests
numpad0 20d ago
It's hard to make LLMs read the manual for an invented language and have them improvise on the spot(1-shot). An established language or a command set that can be included in the training set to be used off top of their head is a lot more reliable and efficient. The caveat is that actual utility of this particular command set isn't clear yet. Or how many LLM labs will find it worthwhile.
heisenzombie 20d ago
There are MANY packages in this space: Labs love to invent their own versions powered by the hubris of grad students. Anyway a random sampling of some I’ve come across is: - EPICS - TANGO - Bluesky (not that one) - QCodes - Sardana - yaq The general problem is (1) i have a heterogeneous mix of hardware that speaks a bunch of different protocols from SCPI serial commands to VISA over USB, to bizarre proprietary things and (2) I want to be able to talk to it from one central computer and (3) ideally have some level of standardisation or abstraction so I can express an experiment like move <stage> from <x> to <y> in <n> steps and at each step fire <laser> and measure <signal> while logging <temperature>. Anthropic seem to be creating the n+1 version of those packages and presumably doing some harness work to make Claude good at using it.

storywatch 20d ago

More like MCP for robotics. IMO they are better off getting the robots to use existing human UIs than trying to get hardware manufacturers to play ball.

tolugenius 20d ago
Oh I see, yeah I guess this assumes manufacturers will just adopt this standard universally. Clears things a bit!
written-beyond 20d ago
That 2 trillion dollar valuation ain't gonna make itself.
cookiengineer 20d ago
What is the difference of MHS to MCP when it comes to features? The whole text reads like everything is just a gRPC call that could've also been implemented with an MCP based wrapper.

sheauwn 20d ago

It seems more like a basic instruction set, that will then be translated to something actionable for each different device. Seems like most of the work then will be in developing the drivers for whatever devices you want the LLM to access.

ctoth 20d ago
Yes, it turns the hardware driver problem into a translation problem (translate the hardware manual/datasheet into this protocol.) Guess what's really good/quick at translating things?
- lefra 19d ago
  "Translating the datasheet into protocol <X>", is the essence of writing a hardware driver. Also my experience with hardware is that the datasheet is often incomplete or misleading. Most of the time is spend fiddling with the hardware to understand exactly what needs to be done, in what order, and sometimes with what delay between commands, to make the damn thing work reliably in the way you want.

tuvix 20d ago

In the context of lab hardware there’s a ton of proprietary software and barriers to automating things. I think this is less about how to communicate, and more guaranteeing that “yes, this piece of hardware can interface with an agent” and is meant to do so. Kind of like using MCP vs letting your agent make raw HTTP requests

numpad0 20d ago

It's hard to make LLMs read the manual for an invented language and have them improvise on the spot(1-shot). An established language or a command set that can be included in the training set to be used off top of their head is a lot more reliable and efficient. The caveat is that actual utility of this particular command set isn't clear yet. Or how many LLM labs will find it worthwhile.

heisenzombie 20d ago

There are MANY packages in this space: Labs love to invent their own versions powered by the hubris of grad students. Anyway a random sampling of some I’ve come across is: - EPICS - TANGO - Bluesky (not that one) - QCodes - Sardana - yaq The general problem is (1) i have a heterogeneous mix of hardware that speaks a bunch of different protocols from SCPI serial commands to VISA over USB, to bizarre proprietary things and (2) I want to be able to talk to it from one central computer and (3) ideally have some level of standardisation or abstraction so I can express an experiment like move <stage> from <x> to <y> in <n> steps and at each step fire <laser> and measure <signal> while logging <temperature>. Anthropic seem to be creating the n+1 version of those packages and presumably doing some harness work to make Claude good at using it.