Clarifying Questions

[Manny7115]

Thanks for updating the files and clarifying a few points, this has helped me get closer to a working cube. I have a few questions about axis mapping and calibration.

1. In the ICM20948.cpp file, why is it necessary to swap the axis? This to me seems as if its driving the wrong motor (y-axis) when I am trying to balance on the Y-axis...shouldn't the z-axis motor be one the driving?

2. How are you assigning the motors to the axis? does M1=x-axis, M2=y-axis and M3=z-axis? 2.1. With the motherboard flat on the table, the motor directly above it should be the z-axis and the motor closest to the yellow power connector should be the x-axis correct?

3. Calibrating the gyro is pretty straight forward, the offsets are initially set to 0 while the program is running the active gyro readings shown in the serial monitor are used as the new offset values. Proper calibration of the gyro should result in values close to 0 when the cube is on the table.

4. Calibrating the accelerometer is where things start to not make sense. If I want to calibrate the Z-axis readings do I set b_acc_z = 0 and f_acc_z = 1 while having the motherboard flat on the table? I then invert the motherboard and take another reading of the Z-axis. With both readings I can now calculate the gain and the offset for the axis? 4.1. Or is the offset for all of the axis simply determined when the axis are placed in a 0g field while the gain is determined by the large +/-16xxx readings?

[willem-pennings]

1. The axes are swapped in the ICM20948.cpp file to align the coordinate system of the IMU with the coordinate system that the controller expects. Definitions are according to those shown in this paper (Figure 2). If you look closely at how the IMU is mounted, how its reference frame is defined, and how that of the cube is defined, you'll notice that the X axes are already aligned, whereas the cube's Z axis is the IMU's y axis, and vice versa. This is why they are swapped.
2. The mapping of motors to axes is determined either by your pin definitions in pins.h or by the way you physically connect your motors to the motherboard. In the end, you should arrange both the wires and file such that motor 1 drives the X axis, motor 2 drives the Y axis, and motor 3 drives the Z axis. Regarding orientations, you can again refer to the paper that I linked.
3. Yes, and this gyro calibration step is done again every time the cube is powered on, so this step is not strictly necessary but good practice in my opinion.
4. The calibration procedure is described in a lot of detail in the application note that I link in my calibration program. You measure two points per axis, note down the raw values, do the offset and gain calculations (Eqns. 17 and 18), and then you feed the results back into the script to verify that you did it right. It doesn't matter what you set the b and f values to, because you don't use them during the actual calibration process. They're only used to calculate calibrated values after you do the procedure. Since you seem to be getting values of 16527 and -16359 (your screenshot), your b is 84 and your f is 1676 for the Z axis. Plug in these values for the Z axis, and you'll see that the calibrated output returns 9.81 when you put the cube in the one Z orientation, and -9.81 when you put it upside down with respect to the previous orientation.

[Manny7115]

I appreciate you answering my questions and providing some pointers. I have been able to successfully calibrate the cube and get it to balance reliably on the X&Y edge. Balancing on the corner still seems a little off to me since all wheels ramp up to full speed as soon as the cube is moved into the starting position. This might means that I need to adjust the gains a bit to get the cube balancing on a corner.

[willem-pennings]

It could also be an issue with your equilibrium point offset phi_e. Try adjusting that: for example try setting it to -3 deg and +3 deg and see if that helps.

[Manny7115]

I actually was able to get the cube to balance on a corner for a couple of minutes before the limit error was triggered. To have the cube react normally I simply changed the wiring between M2 and M3 basically I swapped the Z-axis and Y-axis. I left the pinout in the pins.h file the same as what is shown in the latest file on the github. This to me indicates that the wiring is finally correct and that adjusting the PD gains is all that is left.

Just for my reference when you say xyz axis, is this based on the IMU or the cube itself? If I am understanding the linked paper correctly then the axis should be mapped as such and thus the wiring to the controllers are M1=X-axis, M2=Z-axis and M3=Y-axis with reference to the IMU.

[liy012345]

1. The axes are swapped in the ICM20948.cpp file to align the coordinate system of the IMU with the coordinate system that the controller expects. Definitions are according to those shown in this paper (Figure 2). If you look closely at how the IMU is mounted, how its reference frame is defined, and how that of the cube is defined, you'll notice that the X axes are already aligned, whereas the cube's Z axis is the IMU's y axis, and vice versa. This is why they are swapped.
2. The mapping of motors to axes is determined either by your pin definitions in pins.h or by the way you physically connect your motors to the motherboard. In the end, you should arrange both the wires and file such that motor 1 drives the X axis, motor 2 drives the Y axis, and motor 3 drives the Z axis. Regarding orientations, you can again refer to the paper that I linked.
3. Yes, and this gyro calibration step is done again every time the cube is powered on, so this step is not strictly necessary but good practice in my opinion.
4. The calibration procedure is described in a lot of detail in the application note that I link in my calibration program. You measure two points per axis, note down the raw values, do the offset and gain calculations (Eqns. 17 and 18), and then you feed the results back into the script to verify that you did it right. It doesn't matter what you set the b and f values to, because you don't use them during the actual calibration process. They're only used to calculate calibrated values after you do the procedure. Since you seem to be getting values of 16527 and -16359 (your screenshot), your b is 84 and your f is 1676 for the Z axis. Plug in these values for the Z axis, and you'll see that the calibrated output returns 9.81 when you put the cube in the one Z orientation, and -9.81 when you put it upside down with respect to the previous orientation.

Thanks, with your guidance, my cube is stable and steady, but I found that it can only balance for ten minutes or so (as the trajectory increases, the speed of the wheel slowly gets faster and then exceeds the limit value of the safety control, the red and green light flashes and shrinks alternately), is there a good solution for this problem?

[willem-pennings]

I actually was able to get the cube to balance on a corner for a couple of minutes before the limit error was triggered. To have the cube react normally I simply changed the wiring between M2 and M3 basically I swapped the Z-axis and Y-axis. I left the pinout in the pins.h file the same as what is shown in the latest file on the github. This to me indicates that the wiring is finally correct and that adjusting the PD gains is all that is left.

Just for my reference when you say xyz axis, is this based on the IMU or the cube itself? If I am understanding the linked paper correctly then the axis should be mapped as such and thus the wiring to the controllers are M1=X-axis, M2=Z-axis and M3=Y-axis with reference to the IMU.

Hello, I am always considering cube reference frame when I am talking about axes. So yes, the cube and IMU X axis coincide, whereas the IMU Y and Z axes are swapped when converting to the cube reference frame. This is also reflected in the piece of code which you referenced before. There are no other reference frame conversions from the top of my head, except for the one that corrects the sign of the wheel direction.

[willem-pennings]

1. The axes are swapped in the ICM20948.cpp file to align the coordinate system of the IMU with the coordinate system that the controller expects. Definitions are according to those shown in this paper (Figure 2). If you look closely at how the IMU is mounted, how its reference frame is defined, and how that of the cube is defined, you'll notice that the X axes are already aligned, whereas the cube's Z axis is the IMU's y axis, and vice versa. This is why they are swapped.
2. The mapping of motors to axes is determined either by your pin definitions in pins.h or by the way you physically connect your motors to the motherboard. In the end, you should arrange both the wires and file such that motor 1 drives the X axis, motor 2 drives the Y axis, and motor 3 drives the Z axis. Regarding orientations, you can again refer to the paper that I linked.
3. Yes, and this gyro calibration step is done again every time the cube is powered on, so this step is not strictly necessary but good practice in my opinion.
4. The calibration procedure is described in a lot of detail in the application note that I link in my calibration program. You measure two points per axis, note down the raw values, do the offset and gain calculations (Eqns. 17 and 18), and then you feed the results back into the script to verify that you did it right. It doesn't matter what you set the b and f values to, because you don't use them during the actual calibration process. They're only used to calculate calibrated values after you do the procedure. Since you seem to be getting values of 16527 and -16359 (your screenshot), your b is 84 and your f is 1676 for the Z axis. Plug in these values for the Z axis, and you'll see that the calibrated output returns 9.81 when you put the cube in the one Z orientation, and -9.81 when you put it upside down with respect to the previous orientation.

Thanks, with your guidance, my cube is stable and steady, but I found that it can only balance for ten minutes or so (as the trajectory increases, the speed of the wheel slowly gets faster and then exceeds the limit value of the safety control, the red and green light flashes and shrinks alternately), is there a good solution for this problem?

Hello, yes, I have also observed this issue and am working on a fix. I will soon push a relatively large update to the repository which will solve this issue and introduce a bunch of additional features too.

[willem-pennings]

Seems like the original issue has been solved so I will close this issue now.