| ... | ... | @@ -6,12 +6,19 @@ 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. 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.
|
|
|
|
* 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 robot will drive to the desired goal and sends it's actual position back to OpenTCS. Since OpenTCS only allows to drive from point to point, we created a parse method. This method searches for the closes point based on the given x an y values from the robot.
|
|
|
|
|
|
|
|
## 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.
|
|
|
|
* 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
|
|
|
|
* Since the battery state of the robot did not return proper values, we decided to not implement all the necessities which are needed to process the battery state. We only implemented displaying the robot's battery percentages. In the future there still needs to be a method which creates a Transport order if a robot's percentages is too low. This order has to send the robot to a charge location.
|
|
|
|
* If you try to enable the adapter in the OpenTCS kernel and it returns an error the checkbox does not get unchecked. We think this is a bug generated by Swing, because all the required variables are changed to `false` but somehow the GUI does not update.
|
|
|
|
* Because OpenTCS uses polling to found out which robot is able to process which specific task, the command line is spammed. The reason for this is that our communication adapter prints whether or not a robot is able to process a specific task. However OpenTCS keeps asking the same robot over and over again if it is able to load bolts even though the robot is only able to weld.
|
|
|
|
* Since we had a limited time frame we were not able to dive into every single method of the communication adapter. We commented in the Javadoc which methods we did not use or which we think are not used.
|
|
|
|
* In OpenTCS you are able to abort a Transport order. However if you do this we did not implement the proper method to handle this yet. Therefore the robot is not able to accept new incoming Transport orders, because it's state is set to `Executing`. If you want to solve this issue you have to implement a method called `abortAssignedOrder` which is called in the `VehicleController`.
|
|
|
|
* 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.
|
|
|
|
|
|
|
|
[home](https://git.fhict.nl/I312980/move-it/wikis/home) |
|
|
\ No newline at end of file |
