The standard convention typically used in ROS (and ROS2) for Euler angles is:

• Roll: [-π, π] (or -180° to 180°)
• Pitch: [-π/2, π/2] (or -90° to 90°)
• Yaw: [-π, π] (or -180° to 180°)

In many conventions used in robotics and computer graphics, including ROS (Robot Operating System), yaw angle rotation is typically defined as positive when turning counterclockwise and negative when turning clockwise.

This convention aligns with the right-hand rule, where positive rotation is in the direction of your curled fingers when your thumb points in the positive axis direction (in this case, the positive Z-axis).

So, to clarify:

Counterclockwise rotation around the Z-axis (yaw) is positive.
Clockwise rotation around the Z-axis (yaw) is negative.

https://www.ros.org/reps/rep-0103.html#rotation-representation

For complex simulations with several robots and middleware (in this case, Convoy with Leader and Follower robots), it is necessary the implementation of a launch script. This program will have the mission of spawning each program's instance with the correct arguments and in the correct order.

The preliminary order that the script shall follow is:

1. Build Leader's RadonUlzer firmware
2. Build Leader's DroidControl firmware
3. Build Follower's RadonUlzer firmware
4. Build Follower's DroidControl firmware
5. Open correct Webots scenario
6. Define flags, names, ports, arguments, and running order for each robot instance
7. Run respective programs, making sure the correct connections/ports are established
8. Success...?

Points of discussion:

• Where should this script be located? (It must has access to several Repos and programs)
• Bash, Python, or other scripting language?

Logging tags are not always used. This is a warning in the compilation process, which is then treated as an error.
Proposed solution is to define the tag only when logging is enabled(pseudocode):

#ifdef (LOG_INFO_ENABLE || LOG_DEBUG_ENABLE)
static const char* TAG = "Odo";
#endif

The Client cannot subscribe to more than one channel without a minimum of 2 calls to the process() method in between the calls in order to process the incoming SCRB_RSP. The following snippet will fail to do what is expected:

void setup()
{
    gYapClient.subscribeToChannel("TEST1", CB1);
    gYapClient.subscribeToChannel("TEST2", CB2);
}

This client would only try to subscribe to TEST2, as the m_pendingSuscribeChannel member would be overwriten on the second call to the method.

Currently I do not have a clean solution for this issue. (Should this be converted to a Github Issue?)

The first idea to come to mind is to use an array to hold a determined number of pending channels to suscribe to. However this raises other problems such as memory usage and how to track which channels are suscribed and which are still pending, and when/where does the suscribing process takes places.

Originally posted by @gabryelreyes in #2 (comment)

Keep in mind that the response may never come.

Handle the negative range in function convert_webots_angle_to_ru_angle in webots/controllers/Supervisor/supervisor.py

Using the following call:

/* int32_t turtleSpeedData->angular = 1500  [mrad/s] */
int16_t angularSpeed = static_cast<int16_t>(turtleSpeedData->angular);
diffDrive.setAngularSpeed(angularSpeed);

This results in a counter-clockwise rotation of aroung 270° while the expected behavior is the rotation of the Zumo clockwise around 90° in one second.

Issue has been tracked to DifferentialDrive::calculateLinearSpeedLeftRight where the result of angularSpeed32 * wheelBase32 exceeds the maximum value of int16_t and wraps over to its negative domain.

After running some basic tests I've encountered an issue when calling odometry for longer periods of time.

The test involved the robot endlessly running through the course while periodically outputting X and Y coordinates. It has been done in order to map out key points/areas of the original track for other implementations:

The following values have been found with AND without clearing position after crossing the start/end line:

Conclusions:

• Y values are somewhat consistent while X isn't at all
• clearing position at the start/end line helps

Should save the calibration values of the MotorCalibrationState to EEPROM.
This allows the removal of the state from all other applications.
Applications can then read the value from the EEPROM and directly use it.

Goal: The max. motor speed in steps/s shall be equal between simulation and target. Because the encoder steps / mm are known, the max. velocity can be calculated.

Improve this later to get rid of the memcpy too. Because we send synchronous and the stream will copy the data again.

Originally posted by @BlueAndi in #2 (comment)

In order to prevent missing files and path problems, it is proposed to pack all relevant files into an output folder. This ensures that the executable has all the relevant files in its local path.

Relevant files:

• DLLs
• Sounds files
• settings.json

• Role of Arduino and ArduinoNative in the architecture
• PlatformIO Tasks build an Environment

The IMU components in HALSim and HALTarget are missing the final keyword on their inherited methods.

The max. number of channels configured for the Client must be equal or greater than the max. channels of the Server. Otherwise, the subscription to a channel may fail due to the size of the m_dataChannels Array

Divide between Stream and Print class. Here its mixed.

Originally posted by @BlueAndi in #2 (comment)

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.

Originally posted by @gabryelreyes in #2 (comment)

In order to prevent sudden high accelerations, which may cause errors in some sensors, a ramp for progressive acceleration is required. It shall be processed before the DiffDrive PID controller

Implement changed as in BlueAndi/DroidControlShip#15

The speedometer wrongly reseted the speed of the left motor when it detects a direction change of the "right" one.
Most likely a copy paste error as the involved variable names only differs by left/right suffix.

in Speedometer.cpp @ 97

     if (currentDrivingDirection != m_lastDirectionRight)   // <-- Right motor changed direction
       {
           resetLeft = true;   // <--ERROR Left motor is wrongly reset. Should be "resetRight = true;"
       }

OR make optional/turn off by default??

Please update the architecture documentation: https://github.com/BlueAndi/RadonUlzer/blob/main/doc/architecture/SENSORFUSION.md

The info appears at startup after loading the world (2023a and 2023b).

Create a simple line follower application without using DifferentialDrive, Odometry, etc.
Its easier to start with for beginners.

Replace YAP with SerialMuxProt in sourcecode, documentation and architecture.

New version allows for use of Launcher Script for external controllers.

May bring breaking changes to the world and PROTOs

Bytearray utils, commonly used for SerialMuxProt, are not necessary.
Remove them and fixed possible dependencies,
Tried once, CI failed, reverted.

See:

• e920df4
• https://github.com/BlueAndi/RadonUlzer/actions/runs/6667869543
• 45a588e

• Refactor sourcecode
• Add rule to CI static checks.

#77

The idea is to separate the HAL for the target, simulation and its interfaces in github repositories.
The advantage is to use them in different other projects too, different than RadonUlzer.

Proposal:

• ZumoHALATmega32u4: https://github.com/BlueAndi/ZumoHALATmega32u4
• ZumoHALWebots: https://github.com/BlueAndi/ZumoHALWebots
• ZumoHALInterfaces: https://github.com/BlueAndi/ZumoHALInterfaces

Some improvements were suggested in a merged PR: #81 (review)

Make a script that generates the boilerplate files and updates the configuration to include the application

Fix and improve the Supervisor controller.
Should be able to remove the PyLint suppressions.