Object Storage

One file per object

An object is its picture: one .png at the top of the object directory, named after the object.

<configuration directory>/objects/
├── screw-m6.png
└── bracket.png

which the application publishes as

system/objects = ["bracket", "screw-m6"]

There is no second listing, because there is nothing else to list - the object id and the picture are the same thing. A detector is built around exactly one picture, so a second view of an object has nowhere to go: an object that has to be recognised at two orientations is two objects, screw-m6-front and screw-m6-tilted, searched for in turn.

Anything that is not a .png file at the top of the directory is skipped, subdirectories included.

Only lower case .png is listed. .PNG is ignored deliberately: matching case-insensitively would let screw.png and screw.PNG collapse into one entry, and the listing would no longer say which file a name refers to.

Getting objects onto the device

Either teach them from the camera with create-object, or upload .png files into the application’s configuration directory in the layout above.

The configuration directory and its default templates folder are created at startup, so there is somewhere to upload into straight after installing.

Changing the directory

system/object-dir names the directory in use. It is read-only, and system/set-object-dir is the only thing that changes it:

system/set-object-dir/input/object-dir = production-parts
write system/set-object-dir/execute

The method validates first and publishes object-dir, objects and templates together, so a rejected call leaves all three exactly as they were and the listings always describe the directory actually in use. The choice is saved, so it survives a restart.

The directory must already exist inside the configuration directory. It is deliberately not created for you: the default is created at startup, so a missing one means a typo, and silently creating an empty folder would hide it.

The Data Layer does not enforce read-only on an application’s own nodes, so a client that writes system/object-dir directly will change the value shown. It will not change which directory the application reads, and the listings will then describe a different folder than the node claims. Use set-object-dir.

Path rules

object-dir and object-id are both interpreted relative to the configuration directory. Absolute paths, and any path climbing out with .., are refused with status -2. The application can therefore only read and write templates inside its own configuration area, whatever a client asks for.

When changes are noticed

system/objects and system/objects are refreshed at startup, when set-object-dir switches directory, and when create-object saves a template.

Files added or removed by other means - an upload, an SSH session - are picked up at the next one of those, or at the next restart. Each refresh also makes every module rebuild its detector, so a template removed from disk stops being findable.