"driving behavior" - reverse (backward) currently not possible?

[gnbl]

What changes are required to allow "reversing" of the speed? Should this be done at the CONTROL_xxx level (main.c) or would the introduction of e.g. SPEED_OFFSET and STEER_OFFSET be preferable?

• https://github.com/EmanuelFeru/hoverboard-firmware-hack-FOC/blob/master/Src/main.c#L268
• https://github.com/EmanuelFeru/hoverboard-firmware-hack-FOC/blob/master/Inc/config.h#L144

Btw,

#define INVERT_R_DIRECTION
#define INVERT_L_DIRECTION

seem both to be defined by default, but there is no explanation as to why this is required in addition to SPEED_COEFFICIENT.

[EFeru]

The main purpose of the SPEED_COEFFICIENT is to adjust the slope or the power if you want on the Input. Of course, if you put it to negative the motor will spin in the opposite direction, however it is not intended to be used to reverse direction.

For reversing direction, depending on your needs, you should comment or un-comment one or both of the following lines:

#define INVERT_R_DIRECTION
#define INVERT_L_DIRECTION

With this I think the task can be closed.

[gnbl]

I think reversing should be possible at runtime by input, unless you want the scope of this firmware to be limited to one direction (two-wheelers like scooters etc.).

[EFeru]

I think reversing should be possible at runtime by input, unless you want the scope of this firmware to be limited to one direction (two-wheelers like scooters etc.).

Of course, indeed, you can always reverse the direction by input. The parameters I was referring is for establishing the behavior of the input.. more exactly sign of the input in connection with sign of the motor speed.

EDIT: If you want to drive both directions via ADC input. As you mentioned, you need to use an offset on the ADC input. I don't see another way at this moment.

[gnbl]

That's what this does:

https://github.com/EmanuelFeru/hoverboard-firmware-hack-FOC/blob/1cc8b3475fc2929dea1685a7dc824458ae5e8e9e/Src/main.c#L287-L289

[EFeru]

yes, you can use that. Although the input resolution would be half, because we go from [0, 1000] -> [-1000, 1000] (using integer data type). If I have time, I will think of something, immediately after the ADC is read to not loose resolution.

[gnbl]

How about this?

      cmd1 = (CLAMP(adc_buffer.l_tx2 - ADC1_MIN, 0, ADC1_MAX) * 2000 / ADC1_MAX) - 1000;  // ADC1 steer
      cmd2 = (CLAMP(adc_buffer.l_rx2 - ADC2_MIN, 0, ADC2_MAX) * 2000 / ADC2_MAX) - 1000;  // ADC2 speed

[EFeru]

Implemented here: https://github.com/EmanuelFeru/hoverboard-firmware-hack-FOC/blob/1376793710294773692ef9a4df178f2e6f0b5665/Src/main.c#L270-L282