According to an intensive discussion between Rastaxe and me we arrived at the conclusion of stating the first two message exchanges between the Executive Layer and the Behavioural layer.
The relate to the communication of a command for debugging the Maneuvering subsystem and the command for getting the robot's internal state.
I'll describe them in this post.
Recall: messages are exchanged over channels implemented as unix domain sockets. We use the channel name as the socket name and sockets are created in the /tmp folder of the filesystem
So for example the channel name "maneuver" is translated to the ud socket "/tmp/maneuver".
=== Manuever debug ===
Channel name: maneuverdebug
Socket: /tmp/maneuverdebug
Request: debug lmotorflg lmotorrpm rmotorflg rmotorrpm rudderflg rudderangle boomflg boomangle
Response: no response (fire and forget)
Example: debug 1 1000 0 0 1 60 0 0
Note: A command to test single parts of the maneuver system. The request is sent and no answer has to be expected.
=== Status ===
Channel name: system
Socket: /tmp/system
Request: status
Response: { lat=12.345, lon=12.345, goal_lat=12.345, goal_lon=12.345, speed=0.5, head=35.5, stream_x=1.55, stream_y=1.55, battery=11.8, state='move', health='ok', sail=true}
Note: A command to request the robot state which is a lua map of name=value parameters as shown in the example response above. lat and lon represent the current robot position. goal_lat and goal_lon the target locations when the robot is moving to waypoint. speed and head are self explanatory. stream_x and stream_y represent the speed of the water streaming. state should represent the type of maneuvering the robot is supposed to be using.
Should we change the field name to maneuver, perhaps?
Please waiting for the next commands feel free to comment on that,
Greetings.
Iscriviti a:
Commenti sul post (Atom)
Ciao Marco, It will be better if we have one more field 'Robot ID' to the status message. This will ease the handling of the Status message at Database side.
RispondiEliminaCheers
This morning me and rastaxe performed the first tests on the communication between the executive and the behavioural layers.
RispondiEliminaWe tested the maneuver degbu command and the monitor status command in both ways: from a batch mission script and through the sending of the command over a TCP connection.
Things look to be fine after very few adjustments that are already commited to the code repository.
By the way we installed also the Lua runtime packaged by me in a .deb package onto S. Anna's Titan platform and everything went pretty smooth.
For executing the executive layer on the TITAN now it's sufficient to log into the platform and cd to /home/arcom/executive.
RispondiEliminaThere one can launch the executive.lua script. Pay attention that this could fail if there are no behavioural servers running.
To run the simulated behaviours one could start from the executive directory the lua script simulator/Simulator.lua.
This simulator contains currently a simulator of the manuever behaviour, the communication bahaviour and the system behaviour.
In particular the comm behaviour is reachable from the network at the port 3457 and is supposed to be the bridge for sending commands over the air to the executive layer.
Questo commento è stato eliminato dall'autore.
RispondiEliminaAt the end of today's meeting we agreed upon the following:
RispondiElimina1) The status message will carry also information on the physical parameters like water stream, instant or average wind intensity, battery level. In other words all the parameters that can be sensed easily and continuosly by the robot on it own. I expect a new specification on the parameter names to be released by ghibli or rastaxe.
2) The next feature to be implemented is the configuration of the robots and the relative configuration management commands. We agreed that a configuration file will be stored in the form of a properties file together with the mission at bootstrap. Then, everytime the executive layer updates these parameters, a specific notification of change will be send to the "system" behaviour which can in turn reload the parameters it needs. At the end of this post is a specification of the change notification whilst the executive layer command for updating the parameters will be described in our internal wiki site for the moment.
=== Parameter change notification ===
Channel name: system
Socket: /tmp/system
Request: update params
Note: A command to notify the system of changes in the parameters. The request is sent and no answer has to be expected.
Ok, here follows the new params for the status message.
RispondiEliminaWind:
wind_inst -> instant wind strength
wind_avg -> average wind strength
wind_dir -> wind's direction
Sensors:
sens_flag -> flag to state if the probe and the sensors are busy
sens_ready -> which sensors have data ready
We have 6 sensors and 1 probe. The sensor's flag is 1 if it's analyzing and the probe's flag is 1 if it's lowering. Here follow the meaning of the bit at a low level:
Flag: Bit 0 -> Probe busy
Bit 1 -> Sensor 1 busy
Bit 2 -> Sensor 2 busy
Bit 3 -> Sensor 3 busy
Bit 4 -> Sensor 4 busy
Bit 5 -> Oil slicks sensor busy
Bit 6 -> Physical sensor busy
Data: Bit 0 -> Sensor 1 data ready
Bit 1 -> Sensor 2 data ready
Bit 2 -> Sensor 3 data ready
Bit 3 -> Sensor 4 data ready
Bit 4 -> Oil slicks sensor data ready
Bit 5 -> Physical sensor data ready
In order to have a compact representation of this data we can represent the bit's value in hexadecimal, so the flag field start from 00 to 7F and the data field from 00 to 3F.
Here follows an example of the new status message:
{ lat=12.345, lon=12.345, goal_lat=12.345, goal_lon=12.345,
speed=0.5, head=35.5, stream_x=1.55, stream_y=1.55,
wind_inst=1.55, wind_avg=1, wind_dir=10,
sens_flag = 7F, sens_ready = 3F,
battery=11.8, state='move', health='ok', sail=true}
Errata Corridge: JSON wants hexadecimal values in this way 0x... , so a possible status messages is:
RispondiElimina{ lat=12.345, lon=12.345, goal_lat=12.345, goal_lon=12.345,
speed=0.5, head=35.5, stream_x=1.55, stream_y=1.55,
wind_inst=1.55, wind_avg=1, wind_dir=10,
sens_flag = 0x7F, sens_ready = 0x3F,
battery=11.8, state='move', health='ok', sail=true}
Fair winds!!
Proposal for "station keep" behavioural command:
RispondiElimina=== Station keep request ===
Channel name: maneuver
Socket: /tmp/maneuver
Request: keep lat lon time tolerance
Response: an empty {} when time is elapsed or {err='msg'} if an error occurs
Note: Requests the behavioural layer to keep the position lat lon for the given amount of time (seconds) with a maximum distance of tolerance (in meters).
Example: keep 45.3245 10.4567 60 2