Direction datastream

[adegroote]

Please consider the following patch request.

The idea is to be able to pass explicitly the direction of datastream and modifier at the builder level. If it is not passed explicitly, we use the default direction (i.e. out for sensor and in for actuator).

Why do we need that ? In a near future, I would like to develop 'ExternalSensor' / 'ExternalActuator' (naming is not definitive), i.e. actuator which gets input from 'a robotic architecture' (such as ROS, YARP, ...) and output data for a specialized simulator (using 'hla', 'socket' or 'whatever' protocol) (and the inverse thing for sensor). So we need basically both input and output for them. For normal Sensor / Actuator, this set of commits should not change anything.

Please comment.

[severin-lemaignan]

Could you give a more concrete example of what an 'External Actuator' may be?

The thing is: if you have an actuator called ExternalMotor, I expect something like:

motor = ExternalMotor()

# whatever special method to connect to your external component
motor.outputmodel('ros', '/my/topic')
# the regular 'input' stream you would have for a Motor
motor.add_stream('yarp')

Why do you something besides an added method to connect to your external component?

[adegroote]

My first use are integrated with jsbsim http://jsbsim.sourceforge.net/, basically two actuators:

• one direct engine control (input motor control -> output motor control through HLA)
• one yaw, pitch, roll, thrust control (input y, p, r, t -> output motor control through HLA).

I can, of course, create specific methods to expose that, but I don't really see the point, as in the end, it is only datastreams and modifier connections (in any case, I can implement outputmodel as add_stream with the "correct" "opposite" direction). And I still need to pass properly this information from builder to core Morse.

Is your objection about the builder interface? Or about the general mechanisms (i.e. you want some completely different implementations for the connection with other simulators) ?

[severin-lemaignan]

(i.e. you want some completely different implementations for the connection with other simulators) ?

Well, this is indeed is fair point to raise :-)

[adegroote]

Can you develop a bit ? :D

[severin-lemaignan]

well :-) We were discussing at several occasion that it would make sense to let MORSE interface with more specialized simulators when the need arise. Maybe this is the right time to craft a nice API extensions for that. (and maybe your approach with in/out parameters fits well!)

[adegroote]

Main ideas are exposed in http://homepages.laas.fr/~adegroot/morse2017.pdf.

Exchanges between Morse and specialized simulator is a two (or more) datastreams communication, for example, for JSBSIM, the input (from JSBSIM point of view) can be some engines control and the output pose of the system (and maybe speed) (that will be handled by the teleport actuator at the Morse level). Other examples includes Matlab (input control, output force/torque (or pose)), external physics engine, ...) . External sensors make sense too, with some "pose input" and whatever makes sense in output ....The main "middleware" for communication between simulator is HLA for the moment, but it may change (DIS, specific stuff, future distributed simulation protocol). That is the general idea for internal mechanisms. I don't think much about the user interface yet, as we need something really working before.

[adegroote]

Will you have time to discuss the idea / pull request or should I merge it / continue this stuff ?

[severin-lemaignan]

I won't have much time (I quit today EPFL and move to UK in the coming weeks) for in-depth discussion, but my main concern is: I don't want the Builder API to become bloated because it (very effectively) defeats the sense of 'MORSE has been built with users in mind, ie it is intuitive and does not (in principle) require to keep an eye on the documentation all the time'.

The builder API is already (too) large and I'm a bit wary to make it even more complex by expanding existing methods with more options ('in/out' for the datastream). Even with sane default values, it really make the whole thing more complex for the end-user.

On the other hand, we don't want to 'freeze' MORSE: it must evolve and cover new needs.

So I would suggest something like having a strict core API that remains as stable and as simple as possible, and domain-specific/application-specific advanced features that are available from special imports: from morse.builder.externalsimulator import externalsensor, externalactuator or something of the like.

What would go the the core API is subject to discussion, and we could have a system of REP a la ROS to manage that.

Any thought?

[adegroote]

On 10/Jul - 00:07, Séverin Lemaignan wrote:

I won't have much time (I quit today EPFL and move to UK in the coming weeks) for in-depth discussion, but my main concern is: I don't want the Builder API to become bloated because it (very effectively) defeats the sense of 'MORSE has been built with users in mind, ie it is intuitive and does not (in principle) require to keep an eye on the documentation all the time'.

The builder API is already (too) large and I'm a bit wary to make it even more complex by expanding existing methods with more options ('in/out' for the datastream). Even with sane default values, it really make the whole thing more complex for the end-user.

Well, the direction already existed for datastreams configuration (but was unused). Through, for normal users (which use only sensors / actuators), nothing at all changes. Previous builder script continues to work. Nothing has to be changed in the documentation for 'normal' users (whatever it means).

Through, I agree the builder API is quite large nowadays, through I don't have real idea about how to improve this point. Being able to configure all details of the simulation needs a relatively large API.

On the other hand, we don't want to 'freeze' MORSE: it must evolve and cover new needs.

So I would suggest something like having a strict core API that remains as stable and as simple as possible, and domain-specific/application-specific advanced features that are available from special imports: from morse.builder.externalsimulator import externalsensor, externalactuator or something of the like.

Well, why not. For the moment, the morse-jsbsim node is developed in a separated repository anyway. Through, I don't want to have to redevelop a whole communication / integration system while the datastream stuff covers about all the needs.

Moreover, who decide what is 'basic and stable' and what is 'advanced specific' ? Can we move all human broken stuff out of 'base Morse' ? :D

What would go the the core API is subject to discussion, and we could have a system of REP a la ROS to manage that.

Well, for any change of the core API, I create a pull-request for discussion (and even in this case, it ends generally by merging without real discussion). I don't see how having REP improves the system at all and who will really discuss it. It will just add 3 months to any core change (time to write the document, wait for discussion, ...).

[severin-lemaignan]

[this discussion should take place on morse-dev] Well, these days you definitely are the maintainer and lead dev of MORSE, and I believe in "the ones who do are the ones who decide" :-) My only point is: let's try to keep a simple, core API, so that newcomers are not scared away by a complexity which is also normal to have (this may just end up being a matter of organizing well the documentation, btw!)

[adegroote]

On 10/Jul - 02:53, Séverin Lemaignan wrote:

[this discussion should take place on morse-dev]

Which part of the discussion exactly ? Project management through MEP ? The design of multi-simulation stuff ? The extension of builder API ?

[severin-lemaignan]

@adegroote [this discussion should take place on morse-dev] -> [this discussion should have taken place on morse-dev]

[adegroote]

If they are no other objection, I will merge stuff in the current state. There is ton of times before 1.4 release to discuss / rework / improve builder API.

[adegroote]

Merged