Yet Another Protocol (YAP)

[gabryelreyes]

Implementation and Testing of the Yet Another Protocol (YAP) protocol.

Note:
The following files are shown as complete replacements; however these have not been modified. This is due a problem in the Line Encoding, which has since been resolved. Sorry for the inconvinience.

• .github/workflows/main.yml
• LICENSE
• RadonAlcer.code-workspace
• doc/doxygen/Doxyfile
• lib/LineFollower/ReadyState.cpp
• lib/Service/Logging.cpp
• lib/Service/Logging.h
• webots/LineFollower_track.wbt

[BlueAndi]

General question: How do we differ between YAP and LOG information?

[gabryelreyes]

General question: How do we differ between YAP and LOG information?

In the simulation this has been solved by routing the print() methods to the console, and the write() method to the SocketServer; which may not be ideal in the architecture, but allows for nice debugging. In the target this is not possible, as both print and write are routed to the Serial interface.

Ideally the LOG information would be sent on its own YAP Data channel, meaning that the Logging Module should be able to write to the YAP Server somehow (only the App knows the YAP Server Instance, so it is not an ideal solution). And maybe only the INFO level Logs, not the DEBUG logs.

Other solution is turning Logs completely off on the target, and any information to be transmitted must be available for the App to read and re-route.

[BlueAndi]

In the target this is not possible, as both print and write are routed to the Serial interface.

Thats why I meant that it should be application depended. Have a look:

The definition of Serial will be part of the corresponding application and therefore you can decide there whats the goal.