The general request

General description of the request-schema used for most modules.

The TUC-Bot and its library knows many different modules. Each module usually handles a single feature of the robot. Using all features at once, will lead to communication with all modules. This will slow down the internal communication and important information might be delayed. Therefore, all modules are automatically deactivated on startup.

Request function

If a certain module is needed, then the internal communication needs to be activated. That is why, all respective modules have a request function, e.g. sharps_request().
All request functions have a parameter called request. This parameter is of type eRequestType and can be one of the following values:

kRequestClear	Clears all ongoing requests and returns immediately.
kRequestSingle	Requests one update and returns immediately.
kRequestWait	Requests one update and waits until it is received.
kRequestContinuous	Requests continuous updates and returns immediately.

Note

Not all request functions support all request types. For example the mode of the TUC-Bot can never be requested continuously. See also mode_request().

Bigger modules communicate through more than one data block. Their request functions have a second parameter called bitmask, e.g. encoders_request(). This parameter is used to further finetune the communication based on each data block.

Request state

If a certain request is set, the communication with the respective module will be started. Since, all communication is done sequentially, the precise timing when it is done, can not be estimated beforehand. Therefore, certain flags are set automatically by the library: One flag indicates wether the requested data was received and an other flag indicates if the new data differs from the old data.

Some modules are not just offering data, but also need an input. For example the motor power level can be set via motors_set(). In a similar matter to the reception, there exists a flag if the transmission was succesfully.

The state of the above mentioned flags can be checked with the following functions:

received function	e.g. line_received()	Returns if data was received.
changed function	e.g. buttons_changed()	Returns if received data differs from old data.
transmitted function	e.g. motors_transmitted()	Returns if data block was transmitted successfully.

Note

Reading the internal flags does not change them. But reading or writing to the data block will reset them. For example the function sharps_get() will reset the received and the changed flag of the sharp sensors.

Tighly coupled to the request function, also some of these functions have a second parameter called bitmask.

Only a few modules have a transmitted flag and function.

Request or send!

Some modules allow for requesting and sending data. For both the same data blocks are used. To avoid unintended data corruption, sending data is always dominant.

Therefore, setting data and triggering a send-transmission, will automatically block all ongoing requests to this data block. If a request has already started, its result is ignored and it will be restarted after the send-transmission is done.

List of Modules

Modules which need to be requested:

• All external sensor measurements:
  • Encoders
  • Sharps
  • Line
  • Bumpers
  • Tsops
  • Imu
• All internal sensor measurements:
  • Battery voltage
  • Current
• All Actuators :
  • Servo
  • Motors
  • Drive
• The Buttons
• The Mode of operation
• All external interfaces:
  • Laustracker (German)
  • Packed Communication

Modules which can also transmit data:

• Line
• Motors
• Drive
• Mode of operation