The difference & application scope of STANDSTILL_HOLD and ELECTRIC_BRAKE?

[waythe]

Hi I guess the STANDSTILL_HOLD: Give wheels a torque if the input is zero and speed is almost zero. the ELECTRIC_BRAKE: Give a reverse direction torque if the input is zero and speed is slow. So what does STANDSTILL_HOLD mean if ELECTRIC_BRAKE is enabled? also, do they work for all variables (except VARIANT_TRANSPOTTER which is special)? I didn't see the answer in the wiki.

I looked into the code a little. for standstillHold() & electricBrake(), they read the input1[inIdex].cmd and input2[inIdx].cmd, I think in different variables the inputs mean different, in USART they are steer & speed (instead of brake/throttle). so if they judge according to Serial input, do they act correctly?

also I notice that electricBrake() needs a parameter speedBlend, which seems defined only in VARIANT_HOVERCAR and VARIANT_SKATEBOARD. so are they defined for certain variables only? how to choose whether to use STANDSTILL_HOLD or ELECTRIC_BRAKE?

[waythe]

And do I need to modify mainboard-hack.uvoptx & mainboard-hack.uvprojx if I am trying to add a variable for my own. Now I added a new variable similar with the VARIANT_USART and registered it in platformio.ini, build has no problem but not sure whether it can work yet.

[Candas1]

Hi,

The firmware has a lot of possible conbinations, so not all can be documented. As mentioned in the wiki:

• STANDSTILL_HOLD makes sense for Voltage and Torque mode only
• ELECTRIC_BRAKE makes sense for Torque mode only

speedBlend is also defined whenever electric_brake is defined. So this could work for all variants except Transpotter if you know what it does and what you want.

Best way to understand how it works is to try it.

[waythe]

hi I was trying different modes and settings today. I am still using USART variable with my arduino. After tried one or twice, now I met a strange thing that the motors stops moving, it does not respond the input. what I see from the Arduino debug message I am sending proper commands with nonzero speed + steer. the board don't beep so I think they can receive the Serial Commands properly. I use Bluetooth module to debug, the board output like: IN2_RAW: value:300 init:0 min:-1000 max:1000 so it means commands are received.

but it is strange that the motors don't move. the driver should be ok, when I use SPD mode, the wheels are trying to keep standstill. any suggestion to debug?

I am now trying to fetch the latest firmware so that I can compare it with my local code, in case I made some low level mistake in my code.

[waythe]

one thing I can think of is that I connect the two boards' power buttons together. and when flushing the firmware, I need to hold the power button, does it influence the other one?

[waythe]

I changed the FLASH_WRITE_KEY then they are back now. I guess it's the Input Calibration's bad. but I thought Input Calibration is for ADC, they also take effect for Serial input?

[waythe]

BTW, are you convenient to update the unit of input in wiki? I was using -100~100 in VLT mode, when I change to TOR/SPD, the motors move much faster. I guess in SPD mode the unit becomes RPM? but what is the unit in VLT/TOR?

[waythe]

seen from https://github.com/EFeru/hoverboard-firmware-hack-FOC/issues/204 which proves that for SPD mode the input is RPM. still have no idea of the unit in VLT/TOR.

and from my test, in SPD mode, the motors run faster when backward when I gave the same input (like -15 is obviously faster than 15). this looks strange. where I can change the behavior? ( I changed STEER_COEFFICIENT to the same with SPEED_COEFFICIENT but I guess it is not the cause.)

[waythe]

also, I tried that STANDSTILL_HOLD, this does not work as I expected. in UASRT, the input1 & input2 are steer & speed. I expect that if I give input like "steer = 100 and speed = 0", the car will turn around in place. and if I give input like "steer = 0 && speed = 0", the car will stand still. I'll see if I am able to modify the logic by myself.

[waythe]

hi, now everything works. (I met several other troubles like connectivity problem and failure of Arduino board so it takes extra time) finally, I kept the VLT Mode (with STANDSTILL) for my transpotter after trying other modes. Here are some experiences or questions:

1. During my test of SPD mode, wheels run obviously faster backward than forward, with the same input(ABS). not sure if it is a common issue or a bug?
2. I have two boards with their poweron button connected, so when I flush one board (need to hold the button), another board may enter the Input Calibration unexcepted, I guess after the calibration, min=max=0 because may arduino output zero all the time. so my transpotter stopped moving
3. STANDSTILL_HOLD is not so friendly to serial input, but it can be easily modified here
4. I am still not clear how STANDSTILL_HOLD and ELECTRIC_BRAKE work differently in TOR mode when speed is zero, I may try it in my next work.
5. input unit for SPD mode is RPM, what is it for VLT/TOR?
6. I tried to let the board beep by adding an extra field in the Serial Command. then I tried two ways: 1st, call beepShort in readInputRawif a beep command is sent, 2nd, set a flag in readInputRaw and call beepShort in the main loop. however, neither of them works. I guess that the delay introduced by the beeps may cause trouble like timeout or strange behavior. but actually, I didn't even hear any sound. I didn't investigate deeply because it is not a must and I was busy on other issues. but if anybody has a successful experience it would be nice to share.

[Candas1]

Hi,

1. This shouldn't happen, and I don't think it's a bug as it's widely used. Are you using normal hoverboard wheels ?
2. Yes this can happen. You can deactivate autocalibration in config.h if you don't need it, all is described in the wiki. I have made a change a few weeks ago to prevent autocalibration deactivating both inputs, but I haven't committed yet.
3. I didn't get this point
4. at standstill, standstill hold should apply. It's basically switching to SPD mode with 0 speed target.
5. With voltage mode, I think it's % duty cycle X10, @EFeru can you comment about Unit for torque mode ? I can document this somewhere when I have time
6. Yes the delay will be a problem. It probably doesn't work because of this

[EFeru]

There is no unit for the input in Voltage or Torque, meaning the physical motor operation 0 to maximum is mapped to 0, 1000. Basically, we just request maximum phase pwm and the torque is the result.

If you want to obtain torque in Nm then you need to measure it with a torque sensor and create a map/look up table which you place before the input, i.e., Torque request -> torque map -> input request [-1000, 1000]

[waythe]

oh Thank you all @Candas1 @EFeru , I understand the unit of Voltage / Torque doesn't mean that much. the difficulty I met was hard to decide a proper value as the inputs (of cause tests will give the most intuitive feeling, but in my case, I don't have a wide & safe enough space to test the device, especially when I want to test the behavior with load and higher input value.) and when I change the mode with the same Arduino code, the output differs a lot (like from VLT to SPD). SPD is easy to understand with unit RPM. I guess some notes or suggestions can be given in the wiki so as to help starters to choose parameters.

the physical motor operation 0 to maximum is mapped to 0, 1000. is '1000' a fixed number or editable? or it is also influenced by N_MOT_MAX, INPUT FORMAT, FIELD_WEAK_HI, etc?

@Candas1

1. I feel strange also, I checked my arduino output speed like +100 and -100 with steer zero, but was not convenient to debug the serial output of the boards. I am using normal hoverboard wheels and motherboards, two boards & 4 wheels act the same. I also notice that when I give steer with 100 and -100 and speed zero, the wheels' speed are also different. When I change back to VLT, they back to normal.
2. I see, I've already disabled the autocalibration by following the wiki, so I think it is not a trouble anymore.
3. I mentioned above https://github.com/EFeru/hoverboard-firmware-hack-FOC/issues/278#issuecomment-1079713049, from the code, seems this STAND_STILL is designed for modes with brake & throttle pedals instead of other modes like USART.
4. is my following understanding correct?: STAND_STILL is a mode, when enters it, the wheels will try keeping a zero speed. ELECTRIC_BRAKE changes the input to a new one, without caring about how the input will be used later. so if both of them are activated, when speed > 0 and throttle input is small, ELECTRIC_BRAKE will take effect. when it stops, STAND_STILL will take effect, then if you want to move, the input must > BRAKE_THRES, and also input - BRAKE_THRES should be big enough to exit the STAND_STILL.
5. oh I see, then probably I can realize the beep by modifying the line you specified. seems the actual beep happens here. BTW, does STM32 suppots multi-thread or is HAL_Delay asyn? sorry I am not a embedded software engineer. I thought 'HAL_Delay' will block the CPU, so we shall not use beeps while driving. but if it block the CPU, the beep logic in bldc.c should not work either. not to mention the firmware supports backward beeps. I may get misunderstand here.

[Candas1]

3. Well you could have a brake and throttle on a arduino
4. I mean the delay could be a problem depending on how you use the beeps, it will block the main loop, but if it's just for a short beep it shouldn't be a problem. Motor control doesn't happen in the main loop