Introduce and implement `Start`, `Stop` and `Pause` messages

[Minoru]

we must create messages like "Start" (with robot parameters), "Pause" and "Stop" and implement them.

I don't particularly understand why should we send robot his parameters on Start. Can't he read them from the config by himself?

[SmirnoffYM]

Hm, i think we discussed this before. Yes, he can read his parameters from config, but why? Modelling system already do this. We mustn't do the same work twice.

[Minoru]

Why re-doing some work scares you so much? We already decided that the bot is an autonomous entity. We also have all the code in place (Manager::loadConfiguration). Implementing Start message at robot side should be trivial.

[SmirnoffYM]

I think it is irrational. However, when I implemented loading environment profile, I've implemented random generation of the start position for the corresponding object (see environment profile format). So your proposal won't work with the environment application, i.e. we must send generated start position to the app or don't generate start position in the simulator and do this in the app.

[SmirnoffYM]

Hm. But we can read in the simulator only launch command and port number from both profiles. And other parameters leave to be read by the robot and environment applications. What do you think?

[Minoru]

Simulator also needs to know intersection type, color and "is flying" parameter.

If we do as you say, how would simulator know initial position and orientation of the robots and objects? Should he know them at all? Should robots/objects send their initial parameters using existing protocol (i.e. should they fire a few messages at startup informing simulator of theirs initial parameters, and then just proceed as usual)?

I like that approach better, but we need to answer the forementioned questions.

[SmirnoffYM]

Each robot and all objects (they are controlled by the single app) will be initialized after sending "init" message from their apps to the simulator.

[Minoru]

I think we should keep all the initialization in one piece. If we implement Init message, some part of parameters would be submitted by agents while other would be read from the config. Why not simply read everything from the config?

[SmirnoffYM]

So what do you propose?

Why not simply read everything from the config?

And what do we do with generated start position for environment?

[Minoru]

Environment is quite different matter. First of all, I don't yet see how to fit them nicely into existing protocol. Second, we can make an exception for them and use move and turn to initialize them.

I don't think we should introduce kludgyness into the systems just to make env. objects initialization look nice.

[SmirnoffYM]

First of all, you must add envobject-specific messages (each envobject have unique id, remember?)

we can make an exception for them and use move and turn to initialize them.

Hm, it's an idea. Okay. But move and turn must be environment-specific, as I say before.

[SmirnoffYM]

So, I propose:

• Start message must be empty
• Don't change reading robot's profile
• Reading environment profile perform by each app (simulator and environment) and send "move" message (with corresponding coordinates) to simulator from environment if start coords must be randomly generated.

[Minoru]

But move and turn must be environment-specific, as I say before.

Why introduce two new messages if we can simply modify existing ones? We can add envObjID field that would be 0 for robots and non-zero for environment objects.

[SmirnoffYM]

Okay, no problem.

[Minoru]

I've just pushed commits that introduce start, pause and stop messages, so you can start working on GUI buttons and support in hub.

One more question regarding messages for environment objects: are move and turn the only ones that should be available to environment objects controller program? I figured out that change size and change color may be needed as well. What do you think?

[SmirnoffYM]

I've just pushed commits that introduce start, pause and stop messages, so you can start working on GUI buttons and support in hub.

Hub is developed by Vlad, so tell him about this messages.

I figured out that change size and change color may be needed as well. What do you think?

Let discuss it in Wednesday.

[Minoru]

start, pause and stop is in the master now, though there's still no support in hub module.

[Minoru]

One more question regarding messages for environment objects: are move and turn the only ones that should be available to environment objects controller program? I figured out that change size and change color may be needed as well. What do you think?

Let discuss it in Wednesday.

Does anyone remember our resolution on that? Because I don't, but I need it in order to implement environment-specific messages.

[SmirnoffYM]

At this time "change size" and "change color" aren't needed.