search

EFeru / hoverboard-firmware-hack-FOC

With Field Oriented Control (FOC)
GNU General Public License v3.0
1.11k stars 922 forks source link

VARIANT_PWM #61

Closed vfear closed 3 years ago

vfear commented 4 years ago

Hello. I want to make a firmware VARIANT_PWM using - RoboDurden's online compiler. Please tell me which lines need to be uncommented? I've commented out the VARIANT_PWM string, but it doesn't work, so I guess I need to do something else?

EFeru commented 4 years ago

Oh, I forgot to also change the pins here: https://github.com/EmanuelFeru/hoverboard-firmware-hack-FOC/blob/85552b3e41f383475990a26f85ae4290f571388e/Src/stm32f1xx_it.c#L239-L251 Can you try firmware_PWM_Right_v3.bin?

marshalab commented 4 years ago

@EmanuelFeru firmware_PWM_Right_v3.bin zero reaction. The wheels rotate freely by hand. Nothing happens.

EFeru commented 4 years ago

I am not sure why is like this.. More debugging is needed. With v2 @vfear you said you had movement but only on one channel?

marshalab commented 4 years ago

This vfear was v2, the wheel was spinning with him. My board on v2 and v3 did not react in any way.

vfear commented 4 years ago

no reaction, wheels do not spin on any version (v1 v2 v3 no reaction)

vfear commented 4 years ago

I tried 2 channels - no reaction

vfear commented 4 years ago

What do we do?

EFeru commented 4 years ago

I have to fix my mainboard... I accidentally connected the USART 15V to one Tx/Rx pin which burned the MCU with some nice magic smoke :D Luckilly I have few spare standalone STM32 MCUs. Then, I will try to put pwm with an oscilloscope to PB10, PB11 and see what the issue is.

vfear commented 4 years ago

image

the car is waiting =)))

benjaf commented 4 years ago

@EmanuelFeru I think it might actually be the interrupt not working, rather than the timer. Apparently the interrupt line has to be configured differently if you use anything other than the standard PA pins. This blog post describes setting up interrupts on PB12: https://stm32f4-discovery.net/2014/08/stm32f4-external-interrupts-tutorial/

EFeru commented 4 years ago

@vfear that looks amazing! @benjaf i agree with you, probably something with the interrupt. I will check the link.

EFeru commented 4 years ago

Any progress? I looked to the article and I think bejaf is right, the interrupts need to be remaped too ,we should use IRQ10_15 Handler instead of IRQ2, IRQ3. If I have time I will give it a try these days.

vfear commented 4 years ago

not yet, wait)

EFeru commented 4 years ago

@vfear maybe I have the solution now. Can you try firmware_PWM_Right_v4.zip?

marshalab commented 4 years ago

@EmanuelFeru v4 work! https://www.youtube.com/watch?v=9A_NA7tQei8

But management has strange behavior. Perhaps my cheap Touring 9 console gives a not very high-quality signal. The right wheel lives its own life, jerks sharply and accelerates forward for no reason. My other console behaves even more sternly, but there the sticks are erased.

With smooth stick control, wheel movements are normal. It is necessary to sharply shift the stick and the wheel spins at maximum speed. Sometimes the noise passes and the wheel accelerates again. And only the left wheel is twitching. The right moves smoothly as it should. Therefore, I conclude that this is a software error in the firmware.

And yet, such a sharp behavior occurs with any connection to the receiver, both in the left port and in the right one.

EFeru commented 4 years ago

@marshalab thanks for confirming that the change works. Regarding the way it behaves, activate DEBUG_SERIAL_USART2 (Left cable) and check the value 1: ... and 2: ... see if they are jumping, or not.

Edit: To read the values you need to connect an FDTI, break-out board to read the Serial data.

@marshalab the right wheel seems to behave correctly, so why only left does that.? Is it possible to swap the motors around, to check if still the left does that?

marshalab commented 4 years ago

@EmanuelFeru With DEBUG_SERIAL_USART2 enable no PWM compile

Environment Status Duration

VARIANT_ADC FAILED 00:00:01.590 VARIANT_USART SUCCESS 00:00:01.800 VARIANT_NUNCHUK SUCCESS 00:00:01.770 VARIANT_PPM FAILED 00:00:01.548 VARIANT_PWM FAILED 00:00:01.595 VARIANT_IBUS FAILED 00:00:01.585 VARIANT_HOVERCAR FAILED 00:00:01.568 VARIANT_HOVERBOARD FAILED 00:00:01.550 VARIANT_TRANSPOTTER SUCCESS 00:00:01.748 ======================================================== 6 failed, 3 succeeded in 00:00:14.753

Processing VARIANT_PWM (platform: ststm32; framework: stm32cube; board: genericSTM32F103RC)

Verbose mode can be enabled via -v, --verbose option CONFIGURATION: https://docs.platformio.org/page/boards/ststm32/genericSTM32F103RC.html PLATFORM: ST STM32 6.1.0 > STM32F103RC (48k RAM. 256k Flash) HARDWARE: STM32F103RCT6 72MHz, 48KB RAM, 256KB Flash DEBUG: Current (stlink) External (blackmagic, jlink, stlink) PACKAGES:

marshalab commented 4 years ago

@EmanuelFeru Unfortunately, it was not possible to quickly change the wheels. In a few days I’ll be back and try to swap the wheels. I would like to fully understand the problem.

EFeru commented 4 years ago

@marshalab, In my last commit depending on what side you need, you have to select the LEFT or RIGHT input for PWM. https://github.com/EmanuelFeru/hoverboard-firmware-hack-FOC/blob/d8b529e063b1a03908cd1508e05af5b329eb348b/Inc/config.h#L309-L310

And I just added automatic selection of the DEBUG side according to the PWM input selection: https://github.com/EmanuelFeru/hoverboard-firmware-hack-FOC/blob/d8b529e063b1a03908cd1508e05af5b329eb348b/Inc/config.h#L311-L314

So, it should be fine.

vfear commented 4 years ago

@vfear maybe I have the solution now. Can you try firmware_PWM_Right_v4.zip?

Works. A little strange sound from the wheels (or so it seems to me=)) but otherwise everything is fine. What do we do now? You need to add a pedal and come up with an algorithm for selecting modes (with a remote and pedals, only the remote or only the pedals).

EFeru commented 4 years ago

I think is better if this is done by you according to your needs, because is quite application specific. For example:

vfear commented 4 years ago

have an idea: on the left we connect the gas pedal and potentiometer. with a potentiometer make a choice of modes - P R D (parking, reverse, drive). Parking mode = 0 volts - put the switch in the open of the potentiometer circuit, if = 0 - it is possible to control only through the remote control. if> 0 - control of the pedals and the remote control at the same time, if we lose communication with the remote control - complete stop (parental protection mode) and also: if When you turn on, for 5 seconds we do not see the signal from the remote control - manual control is allowed without using the remote control ( if a signal appears - turn on the parent protection mode again)

vfear commented 4 years ago

addition, make 4 variations 0 (0 volts) - only control from the remote control, parking> 1 volt ... (0 PRD) if we turn it on and within 5 seconds there is no signal from the remote control and the potentiometer> 0 - enable control without remote control, but at when a signal appears, re-enable parental protection

vfear commented 4 years ago

it would be ideal for a baby car, it seems to me. But unfortunately I can’t cope with the code (

EFeru commented 4 years ago

Your proposal sounds feasible to me.

vfear commented 4 years ago

👍 question: is it possible to make pwm_deadband more than 100? Now I tested with the remote control 100 a little

vfear commented 4 years ago

yet, sometimes I turn off the remote control without turning off the car so as not to discharge the batteries for several minutes. Then again I want to turn on the remote and continue driving. In your firmware, if I turn off the remote control, an error is triggered (the sound starts to peep) and until you reboot, further movement is not possible. can this be fixed?

benjaf commented 4 years ago

@vfear You can increase pwm_deadband as needed. If it is only supposed to be used as backup control, something like 300 would probably be fine. That would certainly prevent the remote from interfering unless you provide quite clear input on the transmitter.

vfear commented 4 years ago

@vfear You can increase pwm_deadband as needed. If it is only supposed to be used as backup control, something like 300 would probably be fine. That would certainly prevent the remote from interfering unless you provide quite clear input on the transmitter.

understandably, it was simply written there from -100 to 100. And on the second question, what can you say?

vfear commented 4 years ago

@EmanuelFeru can I somehow get out of the error “loss of connection with the remote control” without rebooting? and the sound of beeping to remove

EFeru commented 4 years ago

Hi @vfear , I am not sure why are you getting beeps from remote timeout. Because, there is no beep implemented for timeout from remote. And it should recover once the PWM receiver pulses are back.

Is it maybe interfering with the ADC timeout timeoutFlagADC? Because, then yes, there is beep on that. However, also from this one the board should recover without the need of a restart. You may try to disable the ADC protection here: https://github.com/EmanuelFeru/hoverboard-firmware-hack-FOC/blob/d8b529e063b1a03908cd1508e05af5b329eb348b/Inc/config.h#L223 But wait also this one is disable for VARIANT_ADC. I have it enabled only for VARIANT_HOVERCAR. So, I am a bit confused:

vfear commented 4 years ago

Hi @vfear , I am not sure why are you getting beeps from remote timeout. Because, there is no beep implemented for timeout from remote. And it should recover once the PWM receiver pulses are back.

Is it maybe interfering with the ADC timeout timeoutFlagADC? Because, then yes, there is beep on that. However, also from this one the board should recover without the need of a restart.

You may try to disable the ADC protection here:

https://github.com/EmanuelFeru/hoverboard-firmware-hack-FOC/blob/d8b529e063b1a03908cd1508e05af5b329eb348b/Inc/config.h#L223

But wait also this one is disable for VARIANT_ADC. I have it enabled only for VARIANT_HOVERCAR. So, I am a bit confused:

  • which Variant are you using?

  • and how did you change it to have 2 input methods (ADC and PWM I guess?)

please forgive me, I myself got confused =) I'm watching this on the old firmware

EFeru commented 4 years ago

No problem :) Give it a try to the new one.

vfear commented 4 years ago

No problem :) Give it a try to the new one.

checked now on a new one, if I turn on VOLTAGE mode - everything is fine, but if I turn on SPEED mode - then what I wrote above happens. Throws an error signal loss.

vfear commented 4 years ago

No problem :) Give it a try to the new one.

I can’t understand how it is?

EFeru commented 4 years ago

I meant to try the latest commits of the FOC branch.

What is the issue you encounter? Is there a moment when turning off remote, where the cmd1 or cmd2 goes a bit crazy? Maybe during turning off. Have a look check with the serial debug activated.

vfear commented 4 years ago

I meant to try the latest commits of the FOC branch.

What is the issue you encounter? Is there a moment when turning off remote, where the cmd1 or cmd2 goes a bit crazy? Maybe during turning off. Have a look check with the serial debug activated.

image image image

vfear commented 4 years ago

https://youtu.be/XuZOuN5hVOM

EFeru commented 4 years ago

@vfear I found the issue. It is below. In case there is a timeout, the MOSFETs Timer is stopped, but the controller doesn't know that, and it will consider as a defective MOSFET (which if it would really happen, is quite a nasty error, that is why a restart is required). As a temporary fix, please remove the || timeout > TIMEOUT in both if conditions. And I will do a proper fix soon. https://github.com/EmanuelFeru/hoverboard-firmware-hack-FOC/blob/68776699e1866b345d1409da3e6148d8956715c4/Src/bldc.c#L117-L129

vfear commented 4 years ago

@vfear I found the issue. It is below.

In case there is a timeout, the MOSFETs Timer is stopped, but the controller doesn't know that, and it will consider as a defective MOSFET (which if it would really happen, is quite a nasty error, that is why a restart is required).

As a temporary fix, please remove the || timeout > TIMEOUT in both if conditions. And I will do a proper fix soon.

https://github.com/EmanuelFeru/hoverboard-firmware-hack-FOC/blob/68776699e1866b345d1409da3e6148d8956715c4/Src/bldc.c#L117-L129

Yes, it works now. only if you disconnect the wire on the go - the wheels still continue to rotate

vfear commented 4 years ago

it is very dangerous in case of signal loss

vfear commented 4 years ago

https://youtu.be/_1H8lZBMjxE

EFeru commented 4 years ago

When you disconnect the wire, does not stop? Because it should normally stop after 500ms, according to this: https://github.com/EmanuelFeru/hoverboard-firmware-hack-FOC/blob/68776699e1866b345d1409da3e6148d8956715c4/Src/control.c#L146-L154

EFeru commented 4 years ago

Ah, yes, please remove && timeout < TIMEOUT, here: https://github.com/EmanuelFeru/hoverboard-firmware-hack-FOC/blob/68776699e1866b345d1409da3e6148d8956715c4/Src/main.c#L262

vfear commented 4 years ago

Ah, yes, please remove && timeout < TIMEOUT, here:

https://github.com/EmanuelFeru/hoverboard-firmware-hack-FOC/blob/68776699e1866b345d1409da3e6148d8956715c4/Src/main.c#L262

yes, now it works well =)

vfear commented 4 years ago

Question: Is it possible to connect 2 motherboards to one receiver in 1 connector? I want to make four-wheel drive. And then when we do the control with the pedal - it turns out just one pedal for 2 boards

benjaf commented 4 years ago

@vfear You can do exactly the same for the receiver.

vfear commented 4 years ago

@EmanuelFeru I downloaded the latest firmware, everything is fine! but why did you add sound when there is no signal from the receiver? how to disable it?

EFeru commented 4 years ago

For timeout, there should be a sound indicating that something is not ok (for example wire disconnected). Normally, the motors should always receive an input. In case you will use the 2nd input (ADC), it should switch to ADC, so there will be no sound because the input is there.

Anyway, if you really want to disable the Timeout sound completely, comment-out these lines: https://github.com/EmanuelFeru/hoverboard-firmware-hack-FOC/blob/22984a7fd60b164609481768f952b8aa529c6f3d/Src/main.c#L462-L463

vfear commented 4 years ago

For timeout, there should be a sound indicating that something is not ok (for example wire disconnected).

Normally, the motors should always receive an input. In case you will use the 2nd input (ADC), it should switch to ADC, so there will be no sound because the input is there.

Anyway, if you really want to disable the Timeout sound completely, comment-out these lines:

https://github.com/EmanuelFeru/hoverboard-firmware-hack-FOC/blob/22984a7fd60b164609481768f952b8aa529c6f3d/Src/main.c#L462-L463

when I turn off the remote control, the receiver also turns off - and the board starts to make a beep sound. Now everything is fine - thanks. (I very often take breaks for several minutes and turn off the remote control so as not to drain the batteries.))