How disable Backward spinning motors?

[ruprotaf]

Variant

HOVERCAR

Control type

FOC

Control mode

Torque

Description

How disable backward spinning motors? (Brake + fast accelerate)

[Candas1]

https://github.com/EFeru/hoverboard-firmware-hack-FOC/wiki/Variant-HOVERCAR#toolbox-troubleshooting

[ruprotaf]

The child accidentally turns on the reverse gear, it is difficult for him to figure out the controls. How do I disable this feature altogether?

[Henrikmakes]

I have sort of the same issue, that the brake action is too aggressive. Also using it for custom kids play cars and the controls are fine generally as they are proportional and smooth in trq mode. The problem is that the wheels start to oscillate under full brake input. THe kids car isnt that heavy and the rider isnt more than about 20kgs either. THere are custom 3dprinted soft tires that are larger torque leverage than the standard small 6,5" wheels, but it still brakes too harshly and locks the wheels even on asphalt. I have tried changing the brake input settings many times and reprogrammed the board and let my daughter testdrive inbetween, but it seems the changes arent really doing much.

Chatgpt says I should adjust the the max limit for the brake under pri_input1, and I have gone all the way up to 10000 while maintaining the low value. I guess I dont understand how it works as I would assume that jump from 2000 to 10000 would make the brake not reach "full brake".

I have not touched the mid, and I would not like to change the current settings for the motor as that would affect also the acceleration as I understand it.

Is there some setting I can change to test my way to a suitable max brake force for my application? Making a soft and controled brake works fine, but kids tend to push the button fully.

[Henrikmakes]

The child accidentally turns on the reverse gear, it is difficult for him to figure out the controls. How do I disable this feature altogether?

I made some adjustments to the double press sequence needed to activate the reverse as I found it a bit too easy for my kids to accidentally enable it. SHortened the time limit and increased the stroke requirement slightly. Now going into reverse needs a bit more determination.

[ruprotaf]

The child accidentally turns on the reverse gear, it is difficult for him to figure out the controls. How do I disable this feature altogether?

I made some adjustments to the double press sequence needed to activate the reverse as I found it a bit too easy for my kids to accidentally enable it. SHortened the time limit and increased the stroke requirement slightly. Now going into reverse needs a bit more determination.

Great, can you share the code?

[Henrikmakes]

The child accidentally turns on the reverse gear, it is difficult for him to figure out the controls. How do I disable this feature altogether?

I made some adjustments to the double press sequence needed to activate the reverse as I found it a bit too easy for my kids to accidentally enable it. SHortened the time limit and increased the stroke requirement slightly. Now going into reverse needs a bit more determination.

Great, can you share the code?

Here it is, might not work for your needs!

If I would make it even "harder" to activate reverse I would probably increase the tap_hi a bit more, but this has worked for my kids so far.

// Multiple tap detection: default DOUBLE Tap on Brake pedal (4 pulses)

define MULTIPLE_TAP_NR 2 2 // [-] Define tap number: MULTIPLE_TAP_NR = number_of_taps 2, number_of_taps = 1 (for single taping), 2 (for double tapping), 3 (for triple tapping), etc...

define MULTIPLE_TAP_HI 800 // [-] Multiple tap detection High hysteresis threshold

define MULTIPLE_TAP_LO 200 // [-] Multiple tap detection Low hysteresis threshold

define MULTIPLE_TAP_TIMEOUT 1750 // [ms] Multiple tap detection Timeout period. The taps need to happen within this time window to be accepted.

// ######################## END OF VARIANT_HOVERCAR SETTINGS #########################

[Henrikmakes]

I tried with help of gpt40 to create some code to apply a different current limit to the motors while braking as opposed to accelerating. I figured that would be one way of reducing the problem of the wheels locking up and oscillating around the 0 position when the brake is rapidly fully pressed. Here is some addition to the main.c section:

void controlMotorCurrent(int16_t current, bool is_braking) { if (is_braking) { if (current > I_MOT_MAX_BRAKE 100) { current = I_MOT_MAX_BRAKE 100; } } else { if (current > I_MOT_MAX_ACCEL 100) { current = I_MOT_MAX_ACCEL * 100; } }

if (*current > I_MOT_MAX * 100) {
    *current = I_MOT_MAX * 100;
}

if (*current > I_DC_MAX * 100) {
    *current = I_DC_MAX * 100;
}

}

and

  // Improved detection of braking state
  bool is_braking = (input1[inIdx].cmd < 0) || (MultipleTapBrake.b_multipleTap);
  controlMotorCurrent(&pwmr, is_braking);
  controlMotorCurrent(&pwml, is_braking);

THen this went into the config file. Added the i_mot_max_brake

define I_MOT_MAX_ACCEL 15 // [A] Maximum motor current limit for acceleration

define I_MOT_MAX_BRAKE 3 // [A] Maximum motor current limit for braking// Limitation settings

define I_MOT_MAX 15 // [A] Maximum single motor current limit

define I_DC_MAX 17 // [A] Maximum stage2 DC Link current limit for Commutation and Sinusoidal types (This is the final current protection. Above this value, current chopping is applied. To avoid this make sure that I_DC_MAX = I_MOT_MAX + 2A)

define N_MOT_MAX 1500 // [rpm] Maximum motor speed limit

I have tested programming the playcar with this code and lowering the is_braking current all the way down to 3A, but its evident it still uses the motor current limit already present in the code.

Any pointers to what is wrong here is appreciated! Is it correct that the < sign to detect braking should be <0? THe pot input is naturally not negative, but it says -1000 to 1000 in the code

static int16_t speed; // local variable for speed. -1000 to 1000

[Candas1]

Chatgpt says I should adjust the the max limit for the brake under pri_input1, and I have gone all the way up to 10000 while maintaining the low value. I guess I dont understand how it works as I would assume that jump from 2000 to 10000 would make the brake not reach "full brake".

This should work unless you use the autocalibration which will use the calibrated version instead of 10000.

[Henrikmakes]

Chatgpt says I should adjust the the max limit for the brake under pri_input1, and I have gone all the way up to 10000 while maintaining the low value. I guess I dont understand how it works as I would assume that jump from 2000 to 10000 would make the brake not reach "full brake".

This should work unless you use the autocalibration which will use the calibrated version instead of 10000.

OK, that explains why it isn't working. I thought the calibration was for the controller to understand the range of the pot/hall, and then it would still act within the visible settings. The hurdles of being a programming noob... I will try to find some other way then.

[Candas1]

Yes it is the range of the pot. But the pots maximum is when maximum torque is requested. If you make it 5000 instead of 2500, maximum torque will be applied at 5000 input which you will never reach, half of the torque will be applied at 2500 input.

That's just a workaround to get it done without changing the code.

[Candas1]

When this is enabled, you can get the max value IN1_MAX, change it, and save it to eeprom, even after the calibration. https://github.com/EFeru/hoverboard-firmware-hack-FOC/wiki/Debug-Serial#keyboard-debug-protocol

[Henrikmakes]

THank you for commenting, this is hard for me, I dont have the needed surrounding knowledge to easily do it. Have not used any debug communication yet, and I am not familiar with softwares to use. I found by searching I can use something called putty, but also found a link in the hoverboard repository for webtool. Looks like you are the author of that :)

I did compile the config changes after disabling the communication for the right sideboard usart3 which I am hoping to make the battery indication work for later. (So far no luck but that is a later problem)

[Henrikmakes]

I need to get some ftdi interface to proceed with thereadouts, but I also found this line in the code in config.

define FLASH_WRITE_KEY 0x11071 //0x1107 Flash memory writing key. Change this key to ignore the input calibrations from the flash memory and use the ones in config.h

As shown here I added a 1 to change the key and tried that firmware. At first it wouldnt arm the motors because the throttle low setting was too low and the resting signal was higher. Added more to it and then it started as intended. I can now proceed to change values and test.

I measured the voltage on the usart2 wires over my throttle and brake with the playcar active and it said ~0,87V resting up to ~2,55V fully pressed. Will test to see if my children can ride without contantly locking the wheels when braking tomorrow.

[Candas1]

When firmware measures a 0v to 3.3v input, in results in a 0 to 4095 value, that's what is expected in config.h So 0.87v would be 1080 as min value.

[Henrikmakes]

When firmware measures a 0v to 3.3v input, in results in a 0 to 4095 value, that's what is expected in config.h So 0.87v would be 1080 as min value.

Cool, that also explains why it hesitated arming with 1000min value but armed directly with 1200 i just tested. Thanks that helps me set the upper value better also.

[Henrikmakes]

Did try this a couple of iterations this morning and my kids testdriving. Wheels no longer start to oscillate heavily during heavy braking. So that is clear progress. However, the reverse functionality isnt working for some reason.

define PRI_INPUT1 1, 1200, 0, 5200, 0 // Pedal Brake TYPE, MIN, MID, MAX, DEADBAND. See INPUT FORMAT section

define PRI_INPUT2 1, 1200, 0, 3100, 0 // Pedal Accel TYPE, MIN, MID, MAX, DEADBAND. See INPUT FORMAT section

I have adjusted the values to engage it but something isnt right as it wont activate. Will need to get that ftdi communication device, but I would have thought these were values safely in the range of the thumb brake.

// Multiple tap detection: default DOUBLE Tap on Brake pedal (4 pulses)

define MULTIPLE_TAP_NR 2 2 // [-] Define tap number: MULTIPLE_TAP_NR = number_of_taps 2, number_of_taps = 1 (for single taping), 2 (for double tapping), 3 (for triple tapping), etc...

define MULTIPLE_TAP_HI 2200 // [-] Multiple tap detection High hysteresis threshold

define MULTIPLE_TAP_LO 1600 // [-] Multiple tap detection Low hysteresis threshold

define MULTIPLE_TAP_TIMEOUT 1750 // [ms] Multiple tap detection Timeout period. The taps need to happen within this time window to be accepted.

// ######################## END OF VARIANT_HOVERCAR SETTINGS #########################

[Henrikmakes]

OK, so tonight I tried to communicate with the board through an ftdi and the webtool. With one flash of the mainboard I saw consistent Rx and Tx in the webtool, but couldnt send any commands and didnt see any text in the log. THe ftdi interface led was blinking alot indicating communication.

Since I didnt seem to be able to do anything or send any commands like $help, I thought maybe there are other debug lines in the config that needs to be activated. So I tried activating the debug lines for usart3 and serial commands under the debug section and tried a few more flashes but didnt even manage to get communication up again. Went over the wiki a few times more and don't get what is the problem. I interpret that the hovercar debug lines is to support the hovercar specific control protocol, while the general debug lines in the debug section are for the base purpose talking to the board.

Also tried if the two wires were switched as mentioned in the wiki.

Reflashed the firmware with only the debug line under hovercar enabled and the communication is again going, but cant seem to do anything. what should be active in the config to talk to the board?

[Candas1]

https://github.com/EFeru/hoverboard-firmware-hack-FOC/wiki/Debug-Serial#keyboard-debug-protocol

You activated it?

[Henrikmakes]

I activated everything debug in I believe all possible combinations in the config and flashed each one and tried. When only the usart3 debug is active under hoverboard it seems to continuosly count up rx/tx and success counters, but cant seem to get any data visible in the log. When I add the debug_serial_protocol together with the debug line under hoverboard it counts rx/tx when I try to send commands, but nothing shows up. I am probably doing something wrong but don't know what.

Can a command like $watch be sent or does it need to be $watch\n or $watch \n? I have tried those as well as a few others found in the wiki.

[Candas1]

even DEBUG_SERIAL_PROTOCOL ?

[Henrikmakes]

Yes the 3 obvious debug lines (2 under the debug section, one under hovercar), but I also tried activating the sideboard under hovercar section but then it complained about a confict and the lower one of these two had to be taken away.

//#define SIDEBOARD_SERIAL_USART3 1 // Rx from right sensor board: to use photosensors as buttons. Number indicates priority for dual-input. Comment-out if sideboard is not used! //#define FEEDBACK_SERIAL_USART3 // Tx to right sensor board: for LED battery indication. Comment-out if sideboard is not used!

In the later tries I diabled both of those. So in conclusion I have seen 5 lines that can be enabled or disabled.

In the wiki it says this about the wiring. Connect GND and RX of a 3.3v FTDI adapter/Bluetooth module to the blue wire on left (DEBUG_SERIAL_USART2) or right sensor board cable (DEBUG_SERIAL_USART3) depending on config.h settings. Isnt the tx needed from the ftdi as well? I tried adding it a few times but no luck so far.

[Henrikmakes]

Took another hoverboard mainboard and flashed it to talk debug on usart3, made a few tries but never got any progress. There is probably something obvious wrong. with this board I got the rx/tx counters in the webtool to move when I powered it on, but didnt get any further yet. Is it supposed to work with the degub usart3 and debug serial lines in the debug section or does the debug line for usart 3 under hovercar also need to be active?

[Candas1]

It's been a while I haven't used this to be honest. I am not sure it will work if you enable debug for usart3 as tx and also keep SIDEBOARD_SERIAL_USART3/FEEDBACK_SERIAL_USART3. But I think you commented it out?

[Henrikmakes]

It's been a while I haven't used this to be honest. I am not sure it will work if you enable debug for usart3 as tx and also keep SIDEBOARD_SERIAL_USART3/FEEDBACK_SERIAL_USART3. But I think you commented it out?

I tried all combinations. Need to clarify some things as I dont have the needed surrounding knowledge to inherently know what is right or wrong here.

1. Do I need to use both RX and TX cables when activating the serial debug line even if the wiki only mentions GND and RX?
2. What conclusions can be drawn from the RX and TX counters going up in the webtool (as well as success counter)? (ftdi is blinking rapidly as if its communicating) This is when only the debug usart 3 under hovercar is active.
3. When the serial debug line is active along with usart3, I can connect to the board and see that RX / TX counters go up when pressing send, but I can not see any test. In the wiki troubleshoot it stated that the ftdi rx and tx could be connected to see that sent commands are received, but I see nothing in the webtool, only the rx/tx counters going up for every send. Could the problem lie with the webtool and some registry or whatever that prevents it from showing text?

[Henrikmakes]

OK, i tried also tera term, and managed to get some life out of the controller.image THis is the raw value of the brake hall thumb button, and it goes between expected values. I can not understand why the reverse double tap will not work then.

Here is info sent at startup, says using values from eeprom.

Conclusion: I had config settings that worked but for some reason I didn't get any visible feedback in the webtool or putty but instantly worked in tera term. THere were more settings in putty and tera term, maybe some defaults were correct in tera term over putty but this is just speculation based on my lacking knowledge.

I have seen that the IN1_cmd value remains at zero in the current flash eventhough the brake is pressed. IN2 moves when throttle is pressed. This explains why the double tap for reverse doesnt engage, but I am puzzled to how there was a more reasonable brake in the latest testrides.

Another thing that could also be the culprit here is old stored ADC values. WHen I sent a write command for the IN1_MAX, it would only allow values up to 4095. Could also be this that creates some malfunction in the code I suspect.

A few questions remain but this brought some more clarity to the problems. If I can just solve the brake behavior I will be happy with the functionality of the system and no immediate changes will be needed.

[Henrikmakes]

I think I have solved it now by setting an ADC max value for the brake of 4095 (should be in range and not trigger any unknowns in the software)

I erased the chip and reflashed the new settings. Brake wasnt working, and I started to question whether the IN1_CMD signal was basis for the double tap to engage reverse instead of the adc 0-4095.

I saw some values raising over 100 when pressing the throttle gently in the debug serial communication. Made me suspect the CMD values are 0-1000.

I did then lower my double tap settings down from the 1400-2000range (which would have been logical for the adc) but then set it to 200-800 as it was way back. THat naturally didnt work because of the newly set adc max to 4095. At full brake it will only reach 75% or 750 (~3100/4095). Tried to lower it to 200-600 and it is activating.

I will now leave it like this and let the kids testdrive, and if the brake needs to be tuned down more I will try going over 4095 and adjust the double tap range if needed. Seems it was two things that made it act up. The stored adc eeprom values and the signal the double tap to activate reverse senses. Not 0-4095 but probably 0-1000.

Another option would be to play with the speed change settings and see if the full behavior of the car changes for the better. (Wheelspin and sliding is fun for the acceleration part so I would rather just alter the brake)

[Henrikmakes]

Another comment for someone thjat might be reading thjis having similar troubles. I tried flashing a higher than 4095 brake input adc value to again stretch the range, and I adjusted the double tap range to be safely in the 0-1000 which i assume the speed command signal uses internally, and reverse will not engage. As the board couldnt be sent a higher value than 4095 through serial comm, i suspect the 5200 value I tried in the config causes malfunction.