Functionality is from this pr

There are 3 UI elements which will save config.

save service config 
will save the current running service in its current state to a directory under data/config/{name}_config
You can change the name to anything you want.  I'd recommend not calling it the same name as your service, as that can lead to namespace pollution.

Runtime save config - will save all services in a flatten heirarchy

InMoov2 save config in equivalent to the save service config - but you can see what config exists and have options to start and release.

All config saved in any context is always saved under data/config A config directory is a python module.
You can start a module, by highlighting it and pressing the start button.

Requirements for this system

  • must allow easy, simple and fully self contained (e.g. everything needed in a directory) to allow simple managing and sharing of different configurations
  • all saving of config, starting or releasing needs to be using the same system regardless of the details of the config file structure
  • easy activation and managing through the UI
  • easy activation and managing through python
  • no "special tooling" for InMoov2

 

 

 

This is currently what I have which is generating initialization/configuration python files for InMoov2.
They are saved to a directory specified by the user.
They are grouped by peers, so all servo configuration for the head is in the i01_head.py file.

The export was done after the (start all servos) was pushed in the web ui.
All running peers of InMoov were exported, all non-running peers were not.

One of the pros of this is it is structured and handles the general case of exporting, there should be no difference in processing and output regardless of the service InMoov2 included.

Loading is simply done with an import in this case if you only wanted the head active the following would suffice.

from i01 import i01_head

And everything that was running that was running, which was part of the head is started with the appropriate configuration.

Ray.Edgley

3 years 7 months ago

Could this be done with other robot designs, for example a Spot robot dog.

Hypothetical (I'm sort of planning it :-)
If I had a Raspberry Pi
with a PCA9685 using the Adafruit16Cservodriver service connected to the Raspi service
and 12 servos then connected to the PCA9685 using the servo service
as well as a MPU6050 service connected to the Raspi service

Could we save then reload the Raspi config to gett all the attached services to load as well?

This could make configuring a robot dog easier :-)

 

Yes, 
that's the plan Ray.
The idea you made some sort of software launch with multiple services, and lots of different configuration.  The goal is to be able to "export" all that running state (whatever it is) into a set of files which you can, if you wish, tweak, replace, re-configure, copy, adjust, clone, morph etc.

It would support quick iterative changes and development with Python.

hairygael

3 years 6 months ago

Hello Grog,

I hadn't seen your post, and just discovered it now.

Thanks for the improvment on the export function, it will be super handy!

How will the export make the distinction on the head if some servos are connected to the left controller and some other servos to the right controller?

For exemple i01.head.rollNeck needs to be on port 12 of the right controller while i01.head.neck is connected to port 12 of the left controller.

Will the export be able also to set in the head.py if some servos are attached or not to the controller?

The controllers would be 1st level  peers to InMoov2 - 
and you could have a configuration "set" which is a directory of configuration which includes the "default" controllers you want - e.g. the neuroboard 2 or 3 arduinos and have it all connected the way you want...
this means there would be a 
i01_left & i01_right ... I guess i01_controller3 or whatever you want.

The nice part is they will be externally defined, and replaceable with raspi controller.
If someone wanted to replace them it would just take changes on the inside of those files, a user could even come up with their own files .. but a "configuration" set would be a directory of those details.

Its currently being generated from Configuration objects - 

https://github.com/MyRobotLab/myrobotlab/tree/grog-config-yaml/src/main…;

You can construct them yourself, or the service config can be saved/generated as well.

It doesn't need to be hand created, it can replace the ini files ...

Its our decision to potentially add the parts we want.

But there is still some work:
 

  • How should the files be organized? Should a single file can have many services ? Should a single directory have many files ?
  • How will the files be loaded ?  Should we offer service.load(someFile) - (this is what happens at the moment)
  • How should the order of configuration be loaded - how is that organized in a directory, or in the file itself ?
  • How should the attach phase work ?