| ... | @@ -10,7 +10,7 @@ This page is designed to document the design choices made while developing the c |
... | @@ -10,7 +10,7 @@ This page is designed to document the design choices made while developing the c |
|
|
|
|
|
|
|
## Design choices
|
|
## 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 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/protocol).
|
|
* We have chosen to communicate with our [Protocol](https://git.fhict.nl/I312980/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.
|
|
* 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
|
|
## Limitations
|
| ... | | ... | |
