sra-vjti / sra-board-component Goto Github PK

Add map function to helper function header file, this has been used several times throughout the code.

@ombhilare999 Use a single error variable esp_err_t errfor all the purposes. This has already been discussed with @VedantParanjape

@SAtacker Could we also a brief description of what this component does and what it comprises in the README itself?

Can this if..else.. block be replaced by a switch statement with a default statement handling cases of channels other than LSA?

In the pdf which @ombhilare999 sent about the new design of SRA board, he mentioned that the mode of the motor drivers will be selected with the help of switches. So, what is the need of selecting the mode from the code?

@VedantParanjape @laukik-hase Was the idea of selecting the mode with switches scrapped?

• Porting each component to v5.1
• checking compatibility issues for each code from Wall-e
• Final version should follow current norms of the codebase

The MCPWM driver has been redesigned, and the legacy driver has been depreciated.

The new MCPWM driver is object-oriented, where most of the MCPWM submodule has a driver object associated with it. The driver object is created by factory function. IO control function always needs an object handle, in the first place.

The component currently uses the legacy drivers, which needs to be updated.

More info: https://docs.espressif.com/projects/esp-idf/en/v5.1.1/esp32/migration-guides/release-5.x/5.0/peripherals.html#adc-oneshot-continuous-mode-drivers

As can be seen in first 10 secs of this video that the bot calibrates the LSA for efficiency in reading, this approach is better than directly hardcoding the values, as it accounts for different situations.

change pin definitions to accommodate the routing changes made for the motor driver, LSA and stepper driver, and also remove the redundant motor driver.

@ombhilare999 The name of the function should be meaningful and explain its purpose.

@VedantParanjape @luke2103 @OSSome01
Rather than having two different functions (with the same template) for the two drivers, can we have a single function which takes the motor driver to be initialised as parameter?

Add support for MPU6050 accelerometer using DMP to generate orientation, rather than using complementary filters.

#55 (comment)

I think since we use the espressif v4.1 image, it overrides the git binary that ubuntu-latest provides. Please check if manually installing latest one with PPA fixes it

Add support for ADC on ESP32 using multi sampling to get accurate results

#define MPU6050_SDA 22
#define MPU6050_SCL 21

and MPU6050's INT is connected to GPIO23 of esp32.
Kindly create macro for this

The build system of IDF v5.1 was updated to no longer use GCC based make system. More details are over here: https://docs.espressif.com/projects/esp-idf/en/v5.1.1/esp32/migration-guides/release-5.x/5.0/build-system.html

The current Wall-E build system must be updated to follow the guidelines laid down by espressif.

Add support for Light Sensing Array. Use custom adc functions defined in adc.h which use multi sampling to get more accurate readings.

Change function name from init_line_sensor() to enable_line_sensor()

Add support for servos.

Create menuconfig entry to set min max pulse width

Checking the gh-pages branch, it doesn't seem like the docs are being pushed to it. Also, it doesn't seem updated on the website.

As of now the website is configured to pull docs from main branch :/docs folder.

Remove error handling blocks for functions which have a very little chance of failing. (These functions will be automatically get verified when stress-tested)

Mention the exact version of ESP-IDF that this component uses, which should be the one on which the entire testing phase was completed on.

@VedantParanjape

lvgl library seems more industry standard than u8g2 library. So we should rewrite all our OLED wrappers in lvgl library.

Add support for bar graph LED, keep in mind the following guidelines while coding:

1. since this shares pins with motor drivers, make sure to check if a motor driver is enabled, if it is that part of the bar graph shouldn't be operated.

2. While initializing bar-graph LED check the state of motor driver which shares pins with it.

Can inline comments be inserted for the GPIO config setup - what each of the struct element corresponds to and its purpose will be just fine.

Code was referred from ESP32 ADC example:
https://github.com/espressif/esp-idf/blob/master/examples/peripherals/adc/main/adc1_example_main.c
They haven't done anything for calloc, @VedantParanjape @laukik-hase kindly check once.

Current implementation of this function is very large and a lot of code is repeated, It is a must to optimise this function

Add support for motor drivers. Some points to consider while adding support ⚠️

1. Must handle Parallel and normal mode through code, rather than menuconfig. This can be done with functions like enable_parallel_mode() or passing parameters to enable_motor_driver(PARALLEL) function.

2. Declare a static variable which is set to 0 if motor driver is disabled, set to 1 if motor driver is enabled in parallel mode, and set to 2 if it is initialise in normal mode.

3. There must be helper method like, read_motor_driver_mode(), which will return the mode of the motor driver by reading the static variable defined above.

4. Functions should be abstract enough, don't define functions like bot_forward(), etc. We don't know for what purpose the motor is going to be used, functions like set_motor_speed() should be defined.

The ADC one shot, ADC continuous drivers, and the ADC calibration driver have been redesigned. The old drivers have been marked as legacy. Therefore, the current version must be updated to use the new ADC drivers.

More info here: https://docs.espressif.com/projects/esp-idf/en/v5.1.1/esp32/migration-guides/release-5.x/5.0/peripherals.html#adc-oneshot-continuous-mode-drivers

Currently sra-board-component has support for only 3 servos, but with new sra-board-hardware design which can support 4 servos, we need to add support for 4th servo as well.

As any other IMU, MPU6050 needs to be calibrated before use, this ensures that if there is any offset in the readings (which may be due to position of MPU6050) then it is accounted for.

An example of calibration : https://github.com/kerikun11/micromouse-kerise-v4/blob/master/firmware/src/hardware/imu.h#L125

It makes sense to automate the process of building docs using doxygen + github actions