During the last couple of weeks, I am working on implementing the vehicles needed for the offloading process. This week I worked on the Straddle Carrier implementation. The SC is the final component needed to get the offloading process working.
I started by analyzing the existing SC prototype code. It was different than I expected. In the original prototype there is a ScSimulator and a ScWorker. I expected the simulator to only have low level movement code and the worker to have the pathing and scheduling. It turns out that the ScSimulator has a lot more responsibilities.
| ScSimulator | ScWorker |
|---|---|
| Determine path between current and target position. | Decide when and which container to pick up / put down. |
| Smooth the initial path to have realistic looking turning angles. | |
| Visualize position by interpolating between points on the path. | |
| Manage claimed areas to keep collisions from happening. |
I could just move the ScSimulator code into my simulation system and the ScWorker in the TOS. However, this would go against my design goals. As one my design goals is to replicate the real-world boundaries of a TOS. In a real TOS the pathing is not hardcoded on the Straddle Carrier but is controlled by a TOS. The same goes for the area claim system. This system is used to keep vehicles from colliding. It is a TOS level system. The simulation should not depend on this system. I need to move the higher-level responsibilities such as pathing and area claiming from the simulator to the TOS.
Turns out the SC movement implementation is not simulated but is path interpolation. How it works is that the SC determines a route that is defined by a list of positions and rotations. The SC then interpolates between points on the route. There is no speed limit or max turn angle in the simulator. It is all defined by the pathing. If the pathing creates an impossible path, for example turn 90 degrees directly, the SC will execute that path. The parameters such as turning angle are defined within the pathing implementation. This would mean that a different implementation of pathing can easily cause impossible paths that the SC would just execute.
The simulation code should be independent of the pathing and the simulation should actually simulate movement with a rotation angle, acceleration, and velocity. The TOS should determine the pathing strategy. If the path can be followed should be determined by the SC simulation movement logic. The SC movement should not interpolate between a list of coordinates but should simulate movement with direction, speed, and acceleration.
After moving responsibility and adding movement simulation the responsibilities look like this:
| ScHardwareService (Simulation) | ScController (TOS) |
|---|---|
| Simulate movement with rotation angle, acceleration, and velocity. | Determine path between current and target position. |
| Smooth path to have make sure the SC can move between the points. | |
| Send the route points one for one to the ScHardwareService | |
| Manage claimed areas to keep vehicles from colliding. |
It took most of the week to implement the SC. By then of the week, I had this working (2x speed):
As you can see there are still several issues. The straddle carrier movement does not support bi-directional movement which is why it currently just turns to the target rotation. The containers are skewed because the Sc does not finish it movements properly and the path taken is a bit convoluted. But the containers do get offloaded from the ship to the stack.
Next week I want to fix these bugs and work on my documentation.