Conversation
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
|
|
||
| # Normal start and connect | ||
| unitree_app = dimos() | ||
| > Returns static PER APP UUID inline for agent to save in memory |
There was a problem hiding this comment.
if doing apps can stay in Py and not depend on memorizing random long strings, use python namespacing, something like
dimos.apps.myapp = dimos()you can refer to
dimos.apps.myapp any time
or you can
dimos.ls() or dimos.apps.myapp.ls()
|
|
||
| # Add a additional module that autoconnects dynamically, Returns failed topics that cant find connections | ||
| unitree_app.run(yolo_detector_module) | ||
|
|
There was a problem hiding this comment.
avoid random long strings like UUID and matching, instead of app stuff, deal with actual python objects,
most of above can be replaced by:
go2 = dimos.deploy(blueprints.unitree_g2)then you could do
dimos.deploy(yolo_detector_module)or (idk if needed - are apps namespaced or not? do apps talk to each other?):
go2.deploy(yolo_detector_module)
| unitree_app.run(yolo_detector_module) | ||
|
|
||
| print(app.get_skills()) | ||
| unitree_app.run_skill("observe")() |
There was a problem hiding this comment.
yes I get the angle, idea behind blueprints was that they behave same as modules on some level. so a blueprint has RPCs, skills, inputs, outputs, and can be treated as such by autoconnect, autoconnect doesn't need to know it's a set of modules. caller of skills or RPCs doesn't need to know either. so yes I agree with this, but
I'm not sure if we should be differentiating between skills and RPCs but we can.
either way, don't invent a new function calling API with
unitree_app.run_skill("observe")()python has a perfect api for "calling functions" - it's called functions
go2.observe()if blueprint (deployed or not!) behaves as a module on the outside you should have all the same helpers
print(go2.inputs)
print(go2.rpcs)
print(go2.skills)
go2.patro()
| unitree_app.run_skill("observe")() | ||
| > returns string observation | ||
|
|
||
| unitree_app.run_skill("relative_move")(distance=1m) |
There was a problem hiding this comment.
go2.relative_move(1.0)
| > Returns latest UUID | ||
| unitree_app_2 = dimos(uuid) | ||
| unitree_app_2.run("openclaw-agent") | ||
| ``` |
There was a problem hiding this comment.
yup let's not give opportunity to anyone to forget UUIDs
dimos.ls()
> [go2]or can have a namespace if you want, oneliner to access
dimos.apps.go2 = dimos.deploy(blueprints.go2)in other script
dimos.apps.go2...
|
|
||
| app.run(yolo_detection_module) | ||
|
|
||
| app.remapping(/video, /color_image) |
There was a problem hiding this comment.
don't create another remapping API, blueprints offer this, make sure you are using the same code, potentially fix the API
| dimos ls | ||
| > App ID | blueprint name | time_started | time running | active/inactive | ||
| > xxxx | bla1 | ||
| > xxxx |
There was a problem hiding this comment.
don't use strings, always return actual objects that we can interact with
for deployed in dimos.ls():
print(deployed)
deployed.stop()etc
for nice cli strings override __repr__ or __str__
|
|
||
| ### Key properties of Applications: | ||
|
|
||
| 1. **Composition**: An Application can compose multiple blueprints + individual modules. e.g. one blueprint + five standalone modules, or two blueprints together. |
There was a problem hiding this comment.
that's what blueprint can do already
|
|
||
| 1. **Composition**: An Application can compose multiple blueprints + individual modules. e.g. one blueprint + five standalone modules, or two blueprints together. | ||
|
|
||
| 2. **Long-running**: Applications persist and you can hot-add modules to a running application as you debug/iterate. |
There was a problem hiding this comment.
Paul is adding this to blueprints right now
|
|
||
| 4. **Transport & Remapping**: Applications should be able to do transport mapping and remappings, similar to how blueprints do it today. (Remapping at application level is a future pass.) | ||
|
|
||
| 5. **Relationship to Blueprints**: Blueprints are templates / "run files" that people define. Applications are live instances that consume blueprints. As you construct applications, they can functionally replace blueprints in many cases, but blueprints remain the portable, shareable unit. |
There was a problem hiding this comment.
Paul does return an object when you deploy a blueprint, use that object, that's your app. I'd still call it "deployed blueprint" but we can call it apps, idk if confusing to have 2 names for activated/deactivated entity
|
|
||
| 2. **Long-running**: Applications persist and you can hot-add modules to a running application as you debug/iterate. | ||
|
|
||
| 4. **Transport & Remapping**: Applications should be able to do transport mapping and remappings, similar to how blueprints do it today. (Remapping at application level is a future pass.) |
leshy
left a comment
leshy
left a comment
There was a problem hiding this comment.
Basically don't use strings ever, and are apps isolated namespaces or not? if not IMO those are 99% deployed blueprints still
This seems to me to be 99% of what Paul is working on right now with "module start/stop" so coordinate with him imo
IMO this is just lifecycle logistics, and this API needs way more work in terms of actual usage of the robot.
how does one write patrol as a oneliner? how does one sit beside a couch? how does one write a simple oneliner person follow? I think these are the real questions to solve here
Problem
Closes DIM-XXX
Solution
Breaking Changes
How to Test
Contributor License Agreement