Regarding the initial motor rotation calibration when using SimpleFOC

developement
1

SimpleFOC. The library rotates twice at the beginning, is this achieved in the initial Angle alignment of the motor and sensor in the alignSensor() function or is the separate absolute Angle alignment below achieved in the function absoluteZeroAlign()?

2

What? You can browse the code documentation at source that might help

3

I didn’t really want the motor to run at the beginning, but I knew it was necessary. But I wonder if there is another way to initialize the motor sensor without having the motor turn twice at the beginning

4

Yes, if you provide the motor.sensor_direction = Direction::<some direction> and the electrical zero motor.electric_zero_angle = <value>, then it will skip any motion on startup.

1 Like
5

Yeah, you can get it to print these values so you can use them in the future, however they will be different for each motor/sensor pair.

Also that’s not the same as the calibration, which you sort of need for magnetic angle sensors at least.

There is a thread where people discussed storing the calibration data to flash so you don’t have to do the stuff every boot up. However apparently saving stuff to flash is hard in arduino, I was not clear why. In micropython I can make any object like an array into an object and store it to flash with a single line of code, and take it back and restore it with another single line, although the best method requires two lines… Essentially there just needs to be a library to do it in arduino, if you look around you might find something, search for json stuff.

6

We now have SettingsStorage drivers for a few different backends.

Unfortunately its not that simple to interact with the flash.
The complexity arises from a few points:

  1. each MCU type, and even different series of the same MCU types, can have different flash layouts and different APIs for interacting with the flash. The Arduino EEPROM library tries to standardise some of this, but in the end its very hardware dependent if, how and where you can write to the flash.

  2. each board has a certain amount of flash, and your development environment manages it based on information from the board setup files and framework. In Arduino, this stuff is predefined to include the boot loader, your program and data, and only on some boards, in rare cases, some user-programmable memory.
    If the board setup does not describe a user-programmable area, then any data you store to flash will just be erased and maybe overwritten the next time you flash the MCU… so you have to modify (customise) the board setup files to add a reserved area to the flash, according to the rules of its layout, and for many users this is not simple to achieve.

  3. while you can normally read flash as normal memory, writing to flash is generally different than normal memory due to the need to erase it in sections/pages first, and write to in standardized block sizes at correctly aligned memory addresses. Getting the writes correct so that a binary value like a little-endian float or int32 can then be read back correctly is not trivial.

But if you take some care, it is certainly possible on many MCUs. There are also libraries available to make it easier for you.

1 Like