| ... | ... | @@ -6,14 +6,12 @@ This page is designed to document the design choices made while developing the c |
|
|
|
|
|
|
|
### MoveITVehicleCommAdapter.java
|
|
|
|
* This adapter connects with the robot. In order to connect with the robot, you have to go to OpenTCS Plantoverview and add two key value pairs at the Miscellaneous property of your robot. One has to be the key host with the IP-address of the robot and the second one has to be the key port with the port of the robot. If you connect a robot to OpenTCS it will search for those key value pairs, if it does not find them the robot is not able to be connected to OpenTCS.
|
|
|
|
* Every point in OpenTCS has to have a x and y value. These values are sent to the robot so it is able to travel to those coordinates.
|
|
|
|
* Every point in OpenTCS has to have a x and y value. These values are sent to the robot so it is able to travel to those coordinates. The communication with the robot is done using x, y and orientation variables. But these coordinates don't line up perfectly. We solve this by parsing the x, y and orientation variables with the sent queue list.
|
|
|
|
|
|
|
|
## 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/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.
|
|
|
|
* The communication with the robot is done using x, y and orientation 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 orientation 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 orientation 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 |
