openTCS: Frequently Asked Questions

openTCS works independently from specific navigation implementations, so any kind of navigation principle may be used. Locating and navigating are tasks usually performed on the vehicle side: The vehicle simply reports its current state, including its position, to the control system, and the control system orders the vehicle to move to a different position.

Note that openTCS focuses on the dispatching of vehicles for transport orders. This task should not be confused with lower-level vehicle-side tasks like accelerating, decelerating and steering the vehicle, which are out of openTCS’s scope.

The requirements for this are minimal:

There is virtually no limit imposed by the design of the software. The hardware equipment used (CPU, RAM, communication bandwidth etc.) can, however, limit the system’s effective performance.

Transport orders can be created interactively by a user via the graphical user interface.

To create transport orders from other systems, e.g. a warehouse management system, interfaces based on Java Remote Method Invocation (RMI) and webservices are included. These are documented in the developer’s guide. Additional, custom interfaces for software that cannot use these interfaces can be added easily.

Vehicles are not allowed to stop at reporting points. Hence at least the starting point and the endpoint (usually linked to a location) of a route must be halt points to make routing possible.

Select Bezier from the path tools and connect two points by clicking on the first point, dragging the mouse to the second point and releasing the mouse button there. Then activate the selection tool and click on the previously created bezier path. Two blue control points will appear. Drag the control points to change the shape of the path.

The openTCS kernel itself works with a logical driving course model - geometric attributes of e.g. points and paths are not relevant for its core functionality. It may, however, have to provide (real/physical) coordinates of a destination point to a vehicle, depending on the way the vehicle’s navigation works. With openTCS, these are called the model coordinates.

The layout coordinates, on the other hand, are coordinates that are used merely for visualizing the driving course in the Model Editor and Operations Desk applications. These coordinates will probably be the same as the model coordinates in most cases, but they may differ, e.g. in cases where the driving course is supposed to be modelled/displayed in a distorted way.

With openTCS, transport orders do not have a priority attribute. That is because a transport order’s priority may change over time or when other transport orders are added.

In the end, a single transport order’s effective priority depends on the dispatcher implementation used. With openTCS’s default dispatcher, transport orders' deadline attributes are intended to be used for prioritizing - the sooner the deadline, the higher an order’s effective priority. To give a transport order a higher priority from the beginning, you can set its deadline to something earlier than all other orders' deadlines, e.g. to "right now" or a point of time in the past.

This should be decided based on project-specific requirements. You are free to implement it either way.

See https://docs.oracle.com/javase/8/docs/technotes/guides/rmi/faq.html#netmultihomed.

This is probably because the kernel is running on a host with multiple IP addresses. See https://docs.oracle.com/javase/8/docs/technotes/guides/rmi/faq.html#netmultihomed.