Working code explanation

[correderadiego]

With this hardware structure you have create a reponsive robot. You send a command using IR and it reacts. It charges the vector moments from mode.h.
Could you show me the way you have used to desing it? The different parts that it involves.I would like a block structure with the different parts of the code and the interactions of every part. If you could underline the code lines that you use for every part it would be great.

[borntoleave]

A brief flowchart of the program is described in sketch structure. Previously all of the codes were on Raspberry Pi. The ideal control flow is described in control hierarchy. After migrating the motion module to Arduino, I haven't organized the structure to perfection. What's currently working is:

• pause motion and react when lifted
• change posture or walking mode according to serial or IR commands
• calibration through serial port
• apply adjustments to servo angles

The serial protocol is shown in serial token table. It supports both serial monitor of Arduino IDE and serial port connected to RaspberryPi. However, there's an unfixed bug for token 'l'.

I have an idea to re-design the data structure and shrink the size of modes.h by 2 or 3 KB. It will help to release more program storage space. For now, you may help to check the MPU codes. It's currently reserving almost half of the dynamic memory for buffering. The buffer is used because after introducing extra codes, the frame rate becomes slower than the refreshing rate of the MPU. However, reducing the buffer size will slow down the code as every time it uses up the buffer the MPU will re-initialize.

[correderadiego]

After continue with the development I would like to understand the system properly. I have created a class structure that I would like to populate with your code. I am going to start asking for different parts of your algorithm to translate it to class mode.
I would like to start by the static mode without information from the accelerometer and then add the accelerometer.
I would like to know all the statics modes (no accelerometer included) and the way you read the information and translate it to the servos.
After it I will release version 1.0.
^_^

[borntoleave]

I started with static walking modes without adjustments for accelerometer/gyro data. They are generated by using reverse kinematics. The outputs are gradually changed frames of servo angles. The robot can be considered as a hardware player for those angles, and the angles are displayed as the rotation of joints.

Considering the periodic nature of those data, and to reduce computational task on the micro-controller, I want to save those data in memory, rather than repeatedly generating them in realtime.

However, the size of SRAM on Arduino Pro mini is only 2KB, while one single static mode can easily fill most of the space. So I saved those data to the flash memory(progmem), details are covered in https://www.arduino.cc/reference/en/language/variables/utilities/progmem/. I also wrote some wrapper functions for more convenient operations on progmem.

To further shrink the data size, I used 1 degree as angular resolution. The range of signed char is -128 ~ 127, and covers the range of servos (-80 ~ 80) well. So the integer angles can be saved as a long char string in flash, then converted back to integer angles when needed. The information of each static gait/posture is parsed by the format:
first character : number of frames
following rows : each frame of angles

Due to the constrained library's functionalities, angle 0s are shifted to 1s to avoid being read as '\0'(the end of char string). Instead, the program will detect the end of string by calculating numberOfFrames x 16 (or 8 depending on the DoF of model). Some lookup tables are also created for extracting the mode of a certain key.

Every time when the program detects a signal to switch mode (gait/posture), it will update the frame array by reading from flash.

Note that the above troubles introduced by limited system resources can be avoided by using better micro-controllers.