search

bipropellant / bipropellant-hoverboard-firmware

OpenSource Hoverboard firmware based on Niklas Fauth's one https://github.com/NiklasFauth/hoverboard-firmware-hack
GNU General Public License v3.0
169 stars 72 forks source link

Doesn't turn on with pushbutton, no hoverboard functionality #90

Open Chaos99 opened 4 years ago

Chaos99 commented 4 years ago

I have a setup with original hoverboard control board and battery and one sensor board connected to the right connector with RX/TX bridged to the left connector.

My right motor has two switched phases and switched hall lines to drive it the other way around.

This setup worked with the original hoverboard firmware controlling the motor speeds with the single sensor tilt angle.

I've set the CONTROL_TYPE to HOVERBOARD and build and flashed this firmware after unlocking with the openocd command (I only got confirmation after the third command mentioned in the wiki (trying the other two before)). Flashing looks ok, verifying works.

Now the board won't turn on permanently. Pushing the power button only turns the board on as long as I keep pressing the button.

The motors don't move and have no resistance to turning. The LEDs flash green once when turning on and I saw them flashing once when turning the motors manually.

I tried double tapping one or both of the optical switches on the single sensor board to enter "sensor mode", but there is no effect.

Any idea what I have could done wrong?

Chaos99 commented 4 years ago

I've also tried flashing the NiklasFauth firmware which I didn't expect to work. With this, I had motor movement for a moment, then nothing again. I also had to hold down the power button.

I assume flashing works as those two firmwares behaved differently.

p-h-a-i-l commented 4 years ago

This does sound like a hardware issue, I'd say something in your self powering circuitry is broken. Maybe start by checking the TIP127 transistors..

Chaos99 commented 4 years ago

I'll check out the TIP127 transitors.

Although it did work with the orginal firmware right up to the point of the first flash trail. (I did some speed measurements for reference right on the bench before). Is there a known danger to destroy something with (failing) attempts to flash or to unlock? I did not connect the 3V3 pin by the way. But the flashing procedure was the first time I ever held the power button for longer than just short presses.

I'm now about to solder wires to B2/C9 (LED pin and non-connect pin right side of uC) for the serial console to get some debugging output.

p-h-a-i-l commented 4 years ago

Can you here the startup melody from the buzzer? If not, flashing might have failed.

Chaos99 commented 4 years ago

No, the buzzer does not sound. I tried to solder wires to pins B2/C9 for debug output, but failed so far with the 0.5er pitch of the pins. I see the LEDs turn on, but they are controlled via the sensor board. I measured VBAT, which is at 3.3V as long as I keep pressing the button. But SUPPLY_ENABLE_MCU is only 3.3V for the first second or two, then goes back to 0V. I'll try to re-programm from platform.io instead of the commad line stlink-flash utility and see if I can get other results there. The stlink tool reported a successful verification after programing, so I assume writing to flash worked. But it could still be that the compilation went wrong somehow.

Chaos99 commented 4 years ago

Removed the sensor boards and tried NiklasFauths firmware again after configuring it. Flashes, boots up and does the motor test. Even sends something on the serial console. But also no sound. And I still have to hold the pushbutton down.

EFeru commented 4 years ago

If you have to keep the push button pressed seems like the power latching circuit does not work. It is either a TIP127 broken or the STM32 itself. Step wise I would the following:

  1. Check the TIP127. Replace if it is the case
  2. Remove the battery and flash the STM32 with 3.3 v from the ST link. If flashing is successful then you should hear the melody but at a lower volume (due to power)
  3. If you don't hear the melody or flashing fails then you have to replace the STM32

Edit: From what you say sounds like a TIP127.

Chaos99 commented 4 years ago

Seem I have a different layout. The first TIP127 isn't one, it's a IRF9530. I also traced the buzzer pin and it's no longer pin 20, it's pin 2. So I changed the definition in the code (the NiklasFauth version) and voila: Start- and Stop-beep are working.

Are there alternative layouts recorded somewhere? I suppose the SUPPLY_ENABLE_MCU pin is changed too and this is why I need to hold the button. I'll try to trace that out too.

Chaos99 commented 4 years ago

For future reference: Board is labled G3 TT-SCCO2B 20160629, it has a STM32F103RCT6. Difference to the published schematics and default settings in the firmware:

may be more. Turns on and stays on with these changes. Sound buzzer. Executes Motor test.

Chaos99 commented 4 years ago

CHARGER_CONNECT on A11 (Pin 44) instead of A12 (Pin 45) V_BATT_MEAS on A1 (Pin 15) instead of C2 (Pin 10)

UART pins are unchanged

EFeru commented 4 years ago

It seems like you have a particular board. Can you make a picture of your main board? To see how different is from the usual one.

Chaos99 commented 4 years ago

Yes, I'll try to make a picture. I may have it X-rayed to trace the full schematics. It looks very much like the one pictured in the wiki. I only discovered the differences now. All connectors and footprints of the bigger parts are in the same place, only the routing and the smaller SMD components are different. It really may be a new generation of the same board.

I'll probably create a fork of the NiklasFauth repo with my modifications and upload the schematics/pictures there. I'll post a link here once I'm done. Might be a few days.

I still need to decide which repo to use for my final project.

EFeru commented 4 years ago

That would be nice. I think now that you did the fixes already, it would be nice to document it. :)

derFrickler commented 4 years ago

Hi Chaos99, seems i got exaclty the same board with the same issues. Could you please specify what exactly you needed to change? Thanks a lot!

Made some progress. Tried to change the pins in the defines.h as described by you, buzzer is working now, but i still have to hold the button to power the board. Also charging does not seem to work. Do you have any hints? Could you please share your defines.h?

Chaos99 commented 4 years ago

I've uploaded my version as https://github.com/Chaos99/hoverboard-firmware-hack/tree/G3_board You also need to change the ADC channel to measure the battery voltage.

Currently, the motor-test works for me, but the board doesn't power down on on a button press. I will continue to investigate.

derFrickler commented 4 years ago

Great, will test your code as soon as i get some time!

stdlogicvector commented 4 years ago

I've got the same board (G3 TT-SCCO2B 20160629) and can confirm the changed pins.

To use pin Pin PC13 I had to add CLEAR_REG(BKP->RTCCR); after the GPIO_init.

The CHARGER_PIN (PA11) is an output on this board, controlling the connection between charger and battery. The voltage of the charger port can be measured on pin PC2. The battery voltage is on pin PA1.

Can someone confirm that the voltage to the 4-pin headers with ADC/UART has the switched battery voltage instead of the regulated 15V? In the photo in the original repo these are labeled with 15V. There should be a warning somewhere... I just exploded a 3.3V regulator that couldn't handle the 38V instead of 15V.

derFrickler commented 4 years ago

Great to see thats its progressing. I tested the branch from Chaos99 and the Motortest works and the board is staying on. Still have some issues with the charging - but as you say, pins are different there too. Have not yet checked the voltage on the external header, can measure it this evening.

@konstantinwerner : did you do your changes in the bipropellant firmware already? Is there a branch to test it?

stdlogicvector commented 4 years ago

I'll make a fork of the repo this weekend. At the moment it's just hacked into the transpotter code.

derFrickler commented 4 years ago

@konstantinwerner Any news? Did you get it fully working?

Chaos99 commented 4 years ago

@derFrickler What exactly are your problems with charging? Charging via the original charger is pure analog and the controller is not involved in this. It merely detects the presents of the charger to (in the orginal firmware at least) block you from driving off.

Measurement of battery voltage incl. low-level warning works in my branch. But it needs to be calibrated to your battery in the header files.

derFrickler commented 4 years ago

@Chaos99 , yes, your repo is working, thanks!

Still, when I connect the charger, the board powers on. When I try to turn it off with the charger connected, the buzzer stays on beeping.

Now I have to adapt the changes to this repo to get the Gametrax controller working.

T-One-1 commented 4 years ago

@Chaos99, I have the same board as yours. Would you please tell me if you made it work ? I tried to flash the G3 firmware in this link (https://github.com/Chaos99/hoverboard-firmware-hack/tree/G3_board). Exactly as you, the motor Test work, But nothing more. I have no idea how can I move on from this step.

Thank you in advance.

P.S: I'm trying to build a robot based on this hoverboard motherboard.

Chaos99 commented 4 years ago

@T-One-1 Please have a look at my fork of the FOC firmware in the uart-fix branch at my repo

I ultimately did choose the FOC firmware over the bipopellant. It has (probably) the better motor contol, but I couldn't get it to work with the sensor boards either. I rewote most of the communication code and now it works with stock-firmware on the sensor boards.

Because I couldn't get the communication with the sensor boards working I stripped down the firmware to the bare minimum to ease debugging, so all the configurable use cases are gone in my branch and it's just doing a PID loop for self-balancing in the main loop. Be careful though, the PID parameters are not guaranteed to be stable in your case and a lot of safety-features are still missing.

PS: Props to your social engineering skills, but next time try keybase.io or search for a similar username/avatar on social media platforms before trying to contact me via the domain admin of my defunct blog. And not that it didn't work, but what the heck? Your question is a few hours old! People have lifes out here!

T-One-1 commented 4 years ago

@Chaos99 Thanks a lot for your answer. I just want to control it via arduino, raspberry pi or jetson nano via UART or PWM simple movement forward, backward and speed for each motor. I want to build something like in the link below and integrated with ROS. Unfortunately, her software doesn't work with my board. So, I suppose I will not need to use the sensor board. I will try your software. I will let you know how it is going.

If I well understood your old posts, this new G3 main board has different PIN schematics. Did you have a list of the PINs and what they control ( do ) ? how did you figured out what every PIN is related to ?

P.S: It is my first time on github and I just discovered keybase.io today. Hope I didn't bother you.

links: https://hackaday.io/project/158256-hoverbot/log/146069-assembling-hoverbot

Best regards,

Chaos99 commented 4 years ago

@T-One-1 See this comment right here in thsi thread.

Or do a diff between my defines.h and the one in the stock repo. (Better do a full diff, there are slight changes in other files too.)

humble800 commented 1 year ago

@derFrickler What exactly are your problems with charging? Charging via the original charger is pure analog and the controller is not involved in this. It merely detects the presents of the charger to (in the orginal firmware at least) block you from driving off.

Hi @Chos99- I am trying to read the voltage of the charger port from pin PC2 by adding one extra ADC conversion in setup.c MX_ADC1_Init() https://github.com/Chaos99/hoverboard-firmware-hack-FOC/blob/8dc24abc8fc1486a1e8445f4c6678fb9a0f9b73f/Src/setup.c#L425. I wasn’t able to do that because hdac1 now has 6 of NbrOfConversion (https://github.com/Chaos99/hoverboard-firmware-hack-FOC/blob/8dc24abc8fc1486a1e8445f4c6678fb9a0f9b73f/Src/setup.c#L437) while hadc2 still has 5 number of conversions. Were you able to block the hoverboard from driving off when the charger is plugged in? If so, I will appreciate your advice.

Candas1 commented 1 year ago

No need for adc https://github.com/Candas1/hoverboard-firmware-hack-FOC/blob/d845bc9bf8f9d854b68301a936e63c075315329f/Src/main.c#L284

derFrickler commented 1 year ago

The problem was that my board had a different pinout which was not really working. With the BoardVariant set to 1 the FOC firmware works perfectly since long: https://github.com/EFeru/hoverboard-firmware-hack-FOC/blob/main/Inc/config.h#L66

humble800 commented 1 year ago

Thank you for your comments, @Candas1 and @derFrickler.

I am using the G3 board labeled TT-SCCO2B 20160629 and trying to disable the motor when charger is plugged in for safety reasons.

From @stdlogicvector's comment above (https://github.com/bipropellant/bipropellant-hoverboard-firmware/issues/90#issuecomment-578521660), the CHARGER_PIN on the G3 board is output only. So I am not able to use HAL_GPIO_ReadPin(CHARGER_PORT, CHARGER_PIN) to determine if the charger is plugged in. Unlike the older version of the control board, I always get 0 on the G3 board whether the charger is plugged in.

Since the voltage of the charger port on the G3 board can be measured on pin PC2, I am trying to use the ADC value of PC2 to determine if the charger is plugged in. From my reading of the MX_ADC1_Init() (https://github.com/EFeru/hoverboard-firmware-hack-FOC/blob/24b3d2515f70c0709b658364930930a935e6552c/Src/setup.c#L594) and MX_ADC2_Init(), the current FOC code uses interleaving DMA with multiple ADC to read in the analog data. I added one additional conversion in MX_ADC1_Init() to read PC2 data, and dded two uint16_t words in the definition of adc_buf_t (https://github.com/EFeru/hoverboard-firmware-hack-FOC/blob/24b3d2515f70c0709b658364930930a935e6552c/Inc/defines.h#L219) to store charger port voltage. So I have 6 conversions through ADC1 (https://github.com/EFeru/hoverboard-firmware-hack-FOC/blob/24b3d2515f70c0709b658364930930a935e6552c/Src/setup.c#L606) and 5 conversions through ADC2 (https://github.com/EFeru/hoverboard-firmware-hack-FOC/blob/24b3d2515f70c0709b658364930930a935e6552c/Src/setup.c#L680). The key changes are noted below:

void MX_ADC1_Init(void) { ..... hadc1.Init.NbrOfConversion = 6; .... sConfig.SamplingTime = ADC_SAMPLETIME_7CYCLES_5; sConfig.Channel = ADC_CHANNEL_12; // charger voltage pin PC2 sConfig.Rank = 6; HAL_ADC_ConfigChannel(&hadc1, &sConfig); ..... DMA1_Channel1->CCR = 0; DMA1_Channel1->CNDTR = 6; DMA1_Channel1->CPAR = (uint32_t) & (ADC1->DR); DMA1_Channel1->CMAR = (uint32_t)&adc_buffer; DMA1_Channel1->CCR = DMA_CCR_MSIZE_1 | DMA_CCR_PSIZE_1 | DMA_CCR_MINC | DMA_CCR_CIRC | DMA_CCR_TCIE; DMA1_Channel1->CCR |= DMA_CCR_EN;

HAL_NVIC_SetPriority(DMA1_Channel1_IRQn, 0, 0); HAL_NVIC_EnableIRQ(DMA1_Channel1_IRQn); }

typedef struct { uint16_t dcr; uint16_t dcl; uint16_t rlA; uint16_t rlB; uint16_t rrB; uint16_t rrC; uint16_t batt1; uint16_t l_tx2; uint16_t temp; uint16_t l_rx2; **#if BOARD_VARIANT == 1
uint16_t l_chsargervol1; uint16_t l_chsargervol2; uint16_t l_chsargervol3; uint16_t l_chsargervol4;

endif**

} adc_buf_t;

I am still very much learning the complicated ADC/DMA setup. Is stm32 process capable of handling 6 ADC1 conversions and 5 ADC2 conversion while keeping the interleaving DMA mode working as it should? It seems like stm32 expects both ADC1 and ADC2 have the same number of conversions in order for the interleaving DMA mode to work properly.

Thank you again for your help. Any suggestion will be appreciate.

humble800 commented 1 year ago

I actually kind of make it work by adding another ADC conversion through adc2, reading the battery voltage on both adc1 and adc2. Now both adc1 and adc2 are doing 6 adc readings. I was able to read the charger voltage on pin PC2 when the charger is plugged in.

void MX_ADC2_Init(void) { .... sConfig.SamplingTime = ADC_SAMPLETIME_7CYCLES_5; sConfig.Channel = ADC_CHANNEL_1; // pa1 vbat sConfig.Rank = 6; HAL_ADC_ConfigChannel(&hadc2, &sConfig); ... }

However I don't know how to enable to enable the battery charging per @stdlogicvector's comments (https://github.com/bipropellant/bipropellant-hoverboard-firmware/issues/90#issuecomment-578521660) I have tried HAL_GPIO_WritePin(CHARGER_PORT, CHARGER_PIN, GPIO_PIN_SET ); but there is no voltage output to the battery even when the charger is plugged in.

Do anyone know how to enable the charging circuit on the G3 board?

humble800 commented 1 year ago

Hello @Chaos99- Do you or does anyone have the circuit diagram for the G3 board particularly the charging circuit? (https://github.com/bipropellant/bipropellant-hoverboard-firmware/issues/90#issuecomment-573572693) I am hoping to make the charging work for the G3 board labeled TT-SCCO2B 20160629. If you have the circuit diagram, I will appreciate your sharing. Thank you.