Sin cos encoder support #81
Conversation
Reads sine and cosine on ADC_IND_EXT and ADC_IND_EXT2, usually used for ACCEL and REGEN inputs. Provides offset and gain compensation and is implemented using floating point math. Note it includes the full mc_interface.h into encoder.c only to access the ADC readings, and no filtering is performed on the signals. Signed-off-by: Marcos Chaparro <mchaparro@powerdesigns.ca>
Signed-off-by: Marcos Chaparro <mchaparro@powerdesigns.ca>
Sin/Cos signals are checked to make sure the module of the vector is larger than 1V and smaller than 1.65V. A working encoder will never have both sin and cos signals at 0V (zero amplitude module). Both sin and cos at 3.3V is also not a possible value. Errors are logged independently for signals too large and for signals too small, provinding the user more insight when an encoder fault happens. In the terminal, the 'encoder' command will show the error counts and error rates of the encoder being used. Signed-off-by: Marcos Chaparro <mchaparro@powerdesigns.ca>
|
Nice! I will try to merge it in the next days. Was away all last week and really busy in the weekend. One comment: ENCODER_SIN_VOLTS could be defined ifndef-wrapped in hw.h, and default to 0 or ADC_VOLTS(ADC_IND_EXT) if ADC_IND_EXT are defined. It would be good if you can add support to VESC Tool too. confgenerator is generated from VESC Tool, so you only need to use the mcconf editor to generate an XML. VESC Tool will also generate a signature that is added to confgenerator to avoid storing or loading incompatible configurations by accident. Note that you need to restart VESC Tool with the new XML before confgenerator can be generated. I hope this makes sense :-) |
|
Good, let me try your comments. Also I just found it there is a reported issue about this (#33) When its merged you can automatically close the issue: https://help.github.com/en/articles/closing-issues-using-keywords |
Signed-off-by: Marcos Chaparro <mchaparro@powerdesigns.ca>
Use m_foc prefix so in VESC Tool they are edited in FOC->Encoder. Generate confgenerator.c and .h using VESC Tool. Signed-off-by: Marcos Chaparro <mchaparro@powerdesigns.ca>
|
I generated the XML and generated confgenerator.c/h from VESC Tool with a new signature. I think I should have bumped vesc tool version. Will create a Pull request on VESC Tool anyways.
|
Adds Sin/Cos to the Encoder list. Expose analog gain compensation, offset and filter constant fields. Include help descriptions and the new FAULT modes for signal amplitude too high or too low. Matches the PR on vedderb/bldc#81 Signed-off-by: Marcos Chaparro <mchaparro@powerdesigns.ca>
Here is theoretical support for sine/cosine analog encoders. This was not tested with actual sin/cos encoders attached to a motor, I'll post an update here when we actually get some field testing done.
Having said so, it should work and it was tested using signal generators connected to our boards.
These signals are input into what is commonly used as ACCEL and REGEN inputs, so using these encoders implicitly requires the board to be controlled over CANbus.
Resulting in correct angle measurements
And rpm measurements
Hopefully this can be merged now to avoid future merge conflicts, it is only available by asserting:
#define HW_HAS_SIN_COS_ENCODERWhen sin/cos signals are not reasonable a fault is asserted. Offset, gain compensation and low pass filtering constant is exposed to be programmed by the user with VESC_TOOL. I have a patch for VESC TOOL to activate sin/cos encoder, but if you prefer we can leave it out for now until we do some formal testing.
Note that encoder.c now includes "mc_interface.h" only to be able to read the analog signals. You may have a way to remove the dependency.
I don't see any reason why
mcpwm_foc_encoder_detect()wouldn't work, but it needs to be tested.During testing we will add to
mcpwm_foc_encoder_detect()the offset and gain compensation to the analog signals so it automatically detects and configures the signals offsets and gains, which are mandatory for correct operation. If sin or cos mean values are too different to the offest would be another interesting fault mode to monitor.