... | ... | @@ -10,7 +10,7 @@ This page is designed to document the design choices made while developing the c |
|
|
|
|
|
## Design choices
|
|
|
* We have chosen to go for a queue capacity of 2 for the robot. We have done this so the robot is always aware of the point it is traveling to and of the point it needs to go to after arriving. We have chosen to stay at 2 to limit the communication with the robot, since transport orders can be cancelled.
|
|
|
* We have chosen to communicate with our [Protocol](https://git.fhict.nl/I312980/move-it/wikis/design/communication-protocol).
|
|
|
* We have chosen to communicate with our [Protocol](https://git.mphslaats.com/fontys/move-it/wikis/design/communication-protocol).
|
|
|
* We chose to create a thread after connecting with the robot. The purpose of this thread is to listen for incoming messages from the robot and process them. The reason for this is so we do not have to poll for messages from the robot, but instead we can process them whenever we receive a message.
|
|
|
|
|
|
## Limitations
|
... | ... | @@ -22,4 +22,4 @@ This page is designed to document the design choices made while developing the c |
|
|
* ROS and OpenTCS have different states for the robot. We do send the state from the robot back to OpenTCS however we still need to parse it somewhere to meet the requirements of OpenTCS.
|
|
|
* Since the limited time frame we had we decided to go for a working product instead of the most secure product. Therefore we recommend to Implement secure sockets, this way our protocol cannot be spoofed.
|
|
|
|
|
|
[home](https://git.fhict.nl/I312980/move-it/wikis/home) |
|
|
\ No newline at end of file |
|
|
[home](https://git.mphslaats.com/fontys/move-it/wikis/home) |
|
|
\ No newline at end of file |