I figure it would be good to move this out of the shout box and into the forum so it's saved for posterity.

Quick summary of what's been discussed so far on the shout box. It would be great to have some way to configure parameters of a particular instance of a service. For example, com port, pin assignments, min, max and rest positions. Some configuration can already be done in the .myrobotlab file but we need to find the documentation on that.

It also would be good to disconnect the joint position and the servo position. For example my jaw open 0% might be a servo value of 20 and my jaw open 100% might be servo abgle of 40. In the current system my min and rest value would be 20 and my max value would be 40. It would be cool to have something that mapped 0->100 to 20->40. So higher level software could say position mouth to 30% open and the jaw servo would get a position value of 26. This could even handle cases where the servo values for min/max are reversed; open = 20 and closed = 40. In this case the servo position would be 34.

Drew

GroG

10 years 9 months ago

Thanks for posting DRogge !

All great ideas...   I especially like the re-mapping values ...   this is already done for OpenCV data 

In OpenCV - a lot of position information used to be returned in pixels, and of course this would break when resolution changed.   Now positions (by default) are changed to a float value so any location at any resolution can be described as a percent.

It would be fairly easy to make a servo.movePercent(0.30) - which could use config to re-map

A little about the .myrobotlab directory

Potentially, this is where "user" data is stored - basically user defined configuration.  The configuration needs work.  Some service probably require more information to be serialized, and some descriptions of serializations are invalid.

On a good day - you can serialize a servo - I had a Servo named servo1 and when I did a System->Save MRL attempt to go to each service and save its values (or some of them) as cofig... 

so a servo1.xml appears in the .myrobotlab directory

it looks like this

<servo>
   <name>servo1</name>
   <allowDisplay>true</allowDisplay>
   <position>91</position>
   <positionMin>0</positionMin>
   <positionMax>180</positionMax>
</servo>
 
- when MRL starts again - it will load the file, right now I can see the controllers name has not been serialized - which if we use config like this probably should be.
 
In short, I believe "configuration" is a real pain.  I hate applications which don't work in some degree because missing configuration.  There's even a motto in software engineering .. "Convention over Configuration"..   It's a good motto :)
 
The BEST situation is when there is smart hardware...  Smart hardware can tell software what it is, and what its doing - this make Plug Play work.  Unfortunately, most easily available robotic hardware at this point is just not that smart.  For example, when MRL is plugged into an Arduino - the Arduino can not tell MRL what board type it is, how many pins it has, and what version of firmware it has.  If it could, many of configuration values you have to change manually could be done automatically.
 
I try to remedy this by creating "versions" and board type identifiers in the sketch that gets loaded into the Arduino - right now its not finished, but I prefer the idea of the user only having to select a serial port, and MRL connects, determines whether the sketch is a compatible version, what board type it is, and what libraries are needed  - versus a bunch of manual configuration.  The challenging part is that this has to be built :)

DRogge

10 years 9 months ago

Convention over configuration is great. There always needs to be reasonable default values.

One thing to consider is inheritance of services. For example if the Hand service is to be shared amoung various robots, the config would have to know if I'm configing for InMoov or someother robot which could have different settings.

I'm in NO WAY suggesting this as an example but if you look at the .Xdefaults file on a linux box you'll see that you can either config, say, ALL font point sizes, just those for a particular widget or just of a particular app. Gets complicated real fast.

One thing I noticed with regards to board type, it looks like the drivers on windows often list the name of the device.

Contextual defauls - Ya ! - that's why I made mrl DNA - Description of Neighboring Automata
Its in its infancy, but so far seems to be working pretty well.  InMoov 2.0 has it - and it sets all the default pins, limits and rest positions .. also since its acts on the services very early (before they start) - you are given the opportunity to tweak almost all of it, if needed.

Suggestion Box