GitLab

Error was in WheelEncoder::ConverToRPM
     - In If statement where a assignment = had been used instead of a conditional ==

Bug found where the global state of speed in shared resources is not updated after refactoring. Pushing this as documentation.

Investigating bug.

 - Changed MotorControl Task Scheduling though relative sleep calls to wakeup calls from an external timer (Tim7). As should have been done from the beginning.

- Focus on seperation of auto generated and written code through subfolders
- Renaming of classes
   - MotorDriver -> VNH5019 (Specific motor shield driver)
- Started to move global semantic enums out of nested class namespaces as to streamline their use (e.g, Units of speed, units of length, right/left rear wheel and so on)

Based on initial misunderstanding of FreeRTOS preemptiveness, a rather unrealiable and complex data syncronisation mechanism was employed, which responsibility to uphold was placed solely on developers. This push implementes FreeRTOS mutexes in the wrapper AccessGuard class, which acts as a wrapper for data to be guarded by mutual exclusion between tasks.

Pi Updated to focus on the difference between the absolute values as the direction is handled by the motor driver.

Currently the robot can do laps given a constant heading angle change without visible drift - Yay!

 - Fix error where ki_ in the regulator is set to zero (expected due to implicit integer conversion from float)
 - Decide upon speed input for regulator (m/s vs RPM)
 - Capture test data and compare with digital simulation

Fixed PWM frequency. Was set to 200 Hz, much lower than the bandwidth of the motors, and as such, should be seen as voltage pulses and not an average voltage across the motors.

Changed the frequency to 20k matching the max PWM frequency of the VNH5019 motor driver.

   - Subscrubtion to ackermann message mov_cmd, speed is assumed to PWM dutycycle
   - publishing rear_wheel_state as a point, this included x and y as direct encoder readings. z is the estimated speed.

Restructured the code a bit, giving each periph type a seperate .h/.c file.

Motors seem to have difficulity spinning as fast as stated in their documentation under no-load, investigating.

Needs to check whether it reacts as desired, does it count all 4 edges of the two encoder signals?

Working towards a working wheel encoder interface using onboard timers of the F446RE in "encoder mode".

- The steering is inverted from the GUI
- The MCU had some issues connecting establishing a connection through MicroROS

Test publisher and subscriber thread sets data in a sharedResource class. Another thread reads and controls the PWM signal from it. There is no speedregulation yet, however, the end-to-end communication seems to work atm.

Added relation to translate virtual rear wheel speed to out wheel speeds in set_speed() of the shared resources.

OBS: The code is starting to get somewhat bloated, maybe revise the strategy.

Added initial structure for shared resources across tasks in FreeRTOS. This is intended to be made as a singleton forcing the use of the desired non-block synchronisation mechanism. Reading up on the ARM architecture reference manual, 4 byte aligned words are atomic in their nature - the class will utilize this to ensure thread safety - for a single core system

Speedcontrol holds a working listener/echo example - this structure outlines the needed microros setup and definitions for a simple publisher and subscriber.

Updated speedctrl project to include MicroROS, tested that it compiles using g++14. It does by wrapping micro ros source in extern C keyword.

Added details to sequence overview since reading on microROS executor concepts. Is still subject to change