| ... | ... | @@ -12,6 +12,8 @@ This page is designed to document the design choices made while developing the c |
|
|
|
* 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 put a deadlock while connecting the robot (after the handshake), this is done so we enforce waiting for the robot initialization.
|
|
|
|
* We have chosen to start a thread after the robot is connected, this thread is listening for messages from the robot.
|
|
|
|
* We have chosen to start a thread after the robot is connected, this thread is listening for messages from the robot.
|
|
|
|
* The communication with the robot is done using x, y and z variables. OpenTCS works with the name of this point. So we got a little problem here. To solve this we parse the x, y and z variables with the sent queue list. However this only contains the points which the robot has traveled. Which means we cannot update the robot's location if it traveled to a point which is not yet defined in the sent queue.
|
|
|
|
The problem here lies with both OpenTCS as with us. We cannot get a proper list with all the available points from our warehouse. If we had this we could parse it so we can translate an x, y and z value to a point. This results in the bug that the OpenTCS map has an initial position. This means that you have to place the robot on this precise location in real life as well. This means that you cannot place your robot randomly in your warehouse, because OpenTCS cannot process this.
|
|
|
|
|
|
|
|
[home](https://git.fhict.nl/I312980/move-it/wikis/home) |
|
|
\ No newline at end of file |
