bipropellant / bipropellant-hoverboard-firmware Goto Github PK

I just made some tests and deactivated the super loud beeping when you do nothing for a few minutes,

what i found out after deactivating,even when in Platformio.ini the

-D INACTIVITY_TIMEOUT=8

is set the main board turns of at exactly 4 minutes and not 8.

is that correct or is there something else wrong?

i now added a timeout function for the machine protocol, when longer than 200ms not command is received it will turn the motors of and will beep for 100ms. this does only work on the setpwm cmd but is also easy to add to other cmds. Here a short demo of the Timeout: https://youtu.be/vWcUI8V5Epk

Could you describe the communication protocol with the gyroscope board?

Hi. Maybe someone can provide an example of machine protocol communication for Arduino.
Just one or to cmds would be enough.

Unfortunatly the hoverboard Api does not compile and the communications i tried just do nothing.

Do i have to send an ack or nack evertime when i receive an answer from the HB?

Is every asci command usable as machine command ? I am not sure.

I am building an RF bridge via esp32 espnow. Until now i use normal rc gear with an arduino nano and this version:https://github.com/p-h-a-i-l/hoverboard-firmware-hack but i want to have more protocoll support as battery voltage amp and so on. Here is a video of my drive https://youtu.be/R5CGtljj2fk

Check out how I set up the config in my fork

Especially this line

The whole config file is deactivated, as soon as IGNORE_GLOBAL_CONFIG is defined.

I use this to set my config through platformio.ini, but still avoid annoying everybody by changing the default behavior all the time.

Another nice thing: if no environment is set as default, all variants are build. This is nice to check if I break other customization's without setting all possible defines by hand.

@EmanuelFeru -

I think what we need is a function:

BLDC_controller_angle_L( theta, amplitude );

which fills rtY.DC_phaALeft; rtY.DC_phaBLeft; rtY.DC_phaCLeft;

with the values for that phase angle at the amplitude specified.

Also, I think that the
BLDC_controller_step()
should probably be separated into BLDC_controller_step_L and BLDC_controller_step_R, as it's likely we'd want to change between low speed and higher speed modes separately on each wheel?

no rush, off to sleep :).

Implement calibration.

I have implemented calibration when holding the button when the HB is on. Holding the on button from startup is still reserved for future use.

I have also implemented on the hoverboard updating of the center position to the calibrated center at the earliest possible. This mimics the behaviour of the original HB.

I will wait until the current outstanding PR's are completed since the existing PR will make the code rather annoying to merge. (no pressure or anything)

Hi there,

I'm using the ADC with tankmode and two pots,
stepping the +15V from the left sensor cable down to +3,3V going to the pots,
the control is very responsive and works fine so far (still I'm unable to use the USART2, see the other issue, comms are ok but motors just make an high-pitch noise),
I noticed that when I power-off the hoverboard using the original power button, the red led next to the STM doesn't turn off and it still emits the noise as it does when turned on.
I thought that the culprit could be some leftover current in the capacitor of the buck converter but when I disconnect the cables from the buck converter the led is still on, to turn completely off the hoverboard I have to disconnect the battery.
If I turn on the hoverboard without connecting the buck converter and then press the power button it shuts down gracefully and makes the bleeping sound before shutting completely down.
any suggestion / did it happen yo you?
thanks

Hey, I hope I haven't overlooked this issue in the open once if it is already known...

I use the board only in hoverboard mode (that's why I chose this repo ;-)), flashing and starting works fine for me. But when standing on the board and leaning forward, the hoverboard accelerates much slower than before (with the original fw), causing the driver to almost fall off forward (if used to the "normal" hoverboard speed). I tested the speed with wheels in the air and noticed, that holding one angle does not accelerate as it does with the original fw, but keeping the same speed. Top speed is okay, but it's not reachable in hoverboard mode when standing on it. With the original fw, the angle determines the acceleration, with this fw, it determines the speed. Is there a way to change this?

Thank you in advance and thank you also for your great work with this repo so far!

Hello,

I'm using the USART2 control type (Using a Raspberry pi 3 with a usb-to-serial),
so far I can communicate with the board but the motors don't spin, they just make an high frequency noise. I see in the troubleshooting that it is suggested to check the phase mapping,
can someone help me on this?
The board is a STM32, the hoverboard is a new one and was working,
So far I just soldered the SWD header, unlocked the STM and flashed it using st-flash.
I can provide photos and logs, I can use an oscilloscope and a multimeter if it can help
see the attached photo for the board and the brief log:

---- Serial log ---

cf_speedCoef 10690, n_commDeacvHi 60, n_commAcvLo 30
?- ?
Locked. Enter unlockASCII to enable ASCII input mode.
>Locked. Enter unlockASCII to enable ASCII input mode.
>unlockASCII
- unlockASCII
ASCII input active. Type ? for help
>?
- ?
? - display help
A - set alarm
B - toggle sensor control
C - show electrical measurements
E - dEbug control, E->off, Ec->console on, Es->console+scope
F - print/set a flash constant (Fa to print all, Fi to default all):
  Fss - print, Fss<n> - set
  Fm<n> - flash magic
  Fpkp<n> - posn kp x 100
  Fpki<n> - posn ki x 100
  Fpkd<n> - posn kd x 100
  Fpl<n> - posn pwm lim
  Fskp<n> - speed kp x 100
  Fski<n> - speed ki x 100
  Fskd<n> - speed kd x 100
  Fsl<n> - speed pwm incr lim
  Fcl<n> - max current limit x 100
  Fhe<n> - hoverboard enable

G - display stm32 specific
I - enable immediate commands - Ip/Is/Iw - direct to posn/speed/pwm control

L - Lock ascii protocol
M -  M - dump memory
   Mf - dump flash
   M<hexaddr>,<hexlen> - dump mem

N - display sensor data
P -  P -power control
  P -disablepoweroff
  PE enable poweroff
  Pn power off in n seconds
  Pr software reset

R -  - R! -> Reset Firmware
S - show main loop timing stats
T - tt - send a test protocol message 
u - unlockASCII - unlock ASCII protocol
>C
- C
Bat: 39484mV(0) Temp:181C(1684)
L: Current:200mA Avg:62mA r1:263 r2:301
R: Current:79mA Avg:47mA r1:287 r2:290
>P
- P
disablepoweroff now 1
powerofftimer now 0
>Iw
- Iw
Immediate commands enabled - WASDXHCGQ - Power (pWm) control
>>speed now 10, steer now 0, pwm 5, pwm 5
>speed now 20, steer now 0, pwm 10, pwm 10
>speed now 30, steer now 0, pwm 15, pwm 15
>speed now 40, steer now 0, pwm 20, pwm 20
>speed now 50, steer now 0, pwm 25, pwm 25
>speed now 60, steer now 0, pwm 30, pwm 30
>speed now 70, steer now 0, pwm 35, pwm 35
>speed now 80, steer now 0, pwm 40, pwm 40
>speed now 70, steer now 0, pwm 35, pwm 35
>speed now 60, steer now 0, pwm 30, pwm 30
>speed now 50, steer now 0, pwm 25, pwm 25
>speed now 40, steer now 0, pwm 20, pwm 20
>speed now 30, steer now 0, pwm 15, pwm 15
>speed now 20, steer now 0, pwm 10, pwm 10
>speed now 10, steer now 0, pwm 5, pwm 5
>speed now 0, steer now 0, pwm 0, pwm 0
>speed now 0, steer now -10, pwm 0->-5, pwm 0->5
>speed now 0, steer now -20, pwm 0->-10, pwm 0->10
>speed now 0, steer now -30, pwm 0->-15, pwm 0->15
>speed now 0, steer now -20, pwm 0->-10, pwm 0->10
>speed now 0, steer now -10, pwm 0->-5, pwm 0->5
>speed now 0, steer now 0, pwm 0->0, pwm 0->0
>Stop set
>?
- ?
? - display help
A - set alarm
B - toggle sensor control
C - show electrical measurements
E - dEbug control, E->off, Ec->console on, Es->console+scope
F - print/set a flash constant (Fa to print all, Fi to default all):
  Fss - print, Fss<n> - set
  Fm<n> - flash magic
  Fpkp<n> - posn kp x 100
  Fpki<n> - posn ki x 100
  Fpkd<n> - posn kd x 100
  Fpl<n> - posn pwm lim
  Fskp<n> - speed kp x 100
  Fski<n> - speed ki x 100
  Fskd<n> - speed kd x 100
  Fsl<n> - speed pwm incr lim
  Fcl<n> - max current limit x 100
  Fhe<n> - hoverboard enable

G - display stm32 specific
I - enable immediate commands - Ip/Is/Iw - direct to posn/speed/pwm control

L - Lock ascii protocol
M -  M - dump memory
   Mf - dump flash
   M<hexaddr>,<hexlen> - dump mem

N - display sensor data
P -  P -power control
  P -disablepoweroff
  PE enable poweroff
  Pn power off in n seconds
  Pr software reset

R -  - R! -> Reset Firmware
S - show main loop timing stats
T - tt - send a test protocol message 
u - unlockASCII - unlock ASCII protocol
>speed now -10, steer now 0, pwm -5, pwm -5
>>Stop set
>Ip
- Ip
Immediate commands enabled - WASDXHCGQ - Position control
>>wanted_posn now 100mm 100mm
>wanted_posn now 200mm 200mm
>wanted_posn now 300mm 300mm
>wanted_posn now 200mm 200mm
>wanted_posn now 100mm 100mm
>wanted_posn now 0mm 200mm
>wanted_posn now 100mm 100mm
>wanted_posn now 0mm 0mm
>Stop set
>>?
- ?
? - display help
A - set alarm
B - toggle sensor control
C - show electrical measurements
E - dEbug control, E->off, Ec->console on, Es->console+scope
F - print/set a flash constant (Fa to print all, Fi to default all):
  Fss - print, Fss<n> - set
  Fm<n> - flash magic
  Fpkp<n> - posn kp x 100
  Fpki<n> - posn ki x 100
  Fpkd<n> - posn kd x 100
  Fpl<n> - posn pwm lim
  Fskp<n> - speed kp x 100
  Fski<n> - speed ki x 100
  Fskd<n> - speed kd x 100
  Fsl<n> - speed pwm incr lim
  Fcl<n> - max current limit x 100
  Fhe<n> - hoverboard enable

G - display stm32 specific
I - enable immediate commands - Ip/Is/Iw - direct to posn/speed/pwm control

L - Lock ascii protocol
M -  M - dump memory
   Mf - dump flash
   M<hexaddr>,<hexlen> - dump mem

N - display sensor data
P -  P -power control
  P -disablepoweroff
  PE enable poweroff
  Pn power off in n seconds
  Pr software reset

R -  - R! -> Reset Firmware
S - show main loop timing stats
T - tt - send a test protocol message 
u - unlockASCII - unlock ASCII protocol
>Is
- Is
Immediate commands enabled - WASDXHCGQ - Speed control
>>speed now 10, steer now 0, speedL 5, speedR 5
>speed now 20, steer now 0, speedL 10, speedR 10
>speed now 30, steer now 0, speedL 15, speedR 15
>speed now 20, steer now 0, speedL 10, speedR 10
>speed now 10, steer now 0, speedL 5, speedR 5
>speed now 0, steer now 0, speedL 0, speedR 0
>speed now 0, steer now -10, speedL -5, speedR 5
>speed now 0, steer now 0, speedL 0, speedR 0
>speed now 0, steer now 10, speedL 5, speedR -5
>Stop set
>>power off by low voltage

Hi,
I am working with ADC as Tankmode and I've set the following parameters in the config file:

  // thoery says this is the only thing you need to change....
  #define CONTROL_TYPE USART3_CONTROLLED
  #define ADC_TANKMODE 1
  #define CONTROL_ADC               // use ADC as input. disable DEBUG_SERIAL_USART2!
  #define ADC1_MIN         0        // min ADC1-value while poti at minimum-position (0 - 4095)
  #define ADC1_ZERO     2047        // ADC1-value while poti at zero-position (0 - 4095)
  #define ADC1_MAX      4095        // max ADC1-value while poti at maximum-position (0 - 4095)
  #define ADC1_MULT_NEG 1000.0f     // Use 1000.0f to calibrate from MIN to MAX
  #define ADC1_MULT_POS 1000.0f     // Use 1000.0f to calibrate from MIN to MAX
  #define ADC2_MIN         0        // min ADC2-value while poti at minimum-position (0 - 4095)
  #define ADC2_ZERO     2047        // ADC2-value while poti at zero-position (0 - 4095)
  #define ADC2_MAX      4095        // max ADC2-value while poti at maximum-position (0 - 4095)
  #define ADC2_MULT_NEG 1000.0f     // Use 1000.0f to calibrate from MIN to MAX
  #define ADC2_MULT_POS 1000.0f     // Use 1000.0f to calibrate from MIN to MAX
  #define ADC_OFF_START    0          // Start Value of Area at which other inputs can be active (0 - 4095) Applies to Speed ADC
  #define ADC_OFF_END      0          // End Value of Area at which other inputs can be active (0 - 4095) Applies to Speed ADC
  #define ADC_OFF_FILTER 1.0          // Additional low pass Filter applied only to ADC Off functionality. 1.0=No Filter, 0.1 lots of Filtering
  //////////////////////////////////////////////////////////

Now I can control it with potentiometers and it is working well. But I need to get information about hall sensors or at least each wheel speed with an Arduino. Is there anything else that I need to setup in the config file for uart communication throught USART3? And how it would be the Arduino code just for reading the speed of each wheel?

Hello,
I have been testing PID speed control. I have encountered this weird behavior, where I need to push motor in order for it to move. https://photos.app.goo.gl/Qaz6EH3oQySmb5k48
Hoverboard is controlled b Ascii.
Could it be motor direction issue ? Position is increasing although motors are spinning backwards.
PWM mode works fine. Motors start spinning at around 200 .

I noticed today, that our repo name might be quite confusing..

First working Firmware for Hoverboard: Hoverboard-Board-Hack
Niklas' refactoring: hoverboard-firmware-hack
Isabelle's hard fork: HoverboardFirmware
Fork for split motor controller Hoverboard-Firmware-Hack-Gen2

Ours hoverboard-firmware

I think this will lead to a lot of confusion..

Is it possible to include the field weakening code from https://github.com/larsmm/hoverboard-firmware-hack-bbcar to increase the top speed of the hoverboard.

Because this projects re-integrates the sensors, it can be used in conjunction with the hoverboard carts and achieve a high top speed.

I noticed some starting problems, sometimes I wasn't able to pull of without pushing forward with my foot or moving the vehicle a little bit and trying again.

Wheels: 10" Air
Load: ~100 kg (vehicle and driver)
Road conditions: bumpy

I was using my watchdog branch, Analog input (=pwm directly).
Default config, but phase advance disabled.

This is not directly related but may be you can help.
I am using usart2 to drive my hoverboard
As soon as usart us connected it powers on without me pressing power button.
When the timeout kickin it powers off and on again.

How do I change this behavior? I can't see in code what signals power on on
usart ?

On Mon, Jul 8, 2019, 6:23 AM phail [email protected] wrote:

Looking good, thanks!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/bipropellant/bipropellant-hoverboard-firmware/issues/64?email_source=notifications&email_token=AAXUAJYKNXPC5BMESTBS7D3P6M5VHA5CNFSM4H62QU32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZNCCXI#issuecomment-509223261,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAXUAJYIJFCCAYCZ3SEYIIDP6M5VHANCNFSM4H62QU3Q
.

Originally posted by @sjamthe in #64 (comment)

The firmware cannot measure current when breaking, right?
What happens if there is too much current when breaking using regeneration?
Or the wheels cannot produce too much current for the board electronics to handle?

As mentioned here: #55

Change lots of hardcoded magic numbers to flash stored values which can be updated via serial protocol.
Especially ADC parameters need to be update-able via protocol.

@btsimonh: We still need to have the default values somewhere. I'd still use defines but use them only for flash initialization. Do you know of a better way?

I felt like I had to leave a warning somewhere ;)

When using the machine protocol with USART2 and USART3, the main routine crashes pretty often for me.
That's also the reason why I'm not actively using this fork. In my own branch only minimal parts of this fork are implemented, this is running stable.
Also a watchdog is running which at leasts stops the motors since the bldc interrupts keep on firing happily :)
My goal is to merge both back together, but it looks like we're short on timers. Maybe in the final product you have to decide between function vs. watchdog.

While merging electricalmeasurements, pid and Flash functionality, instability came back too. Need to look further into the root cause, but wanted to leave this here as warning.

Neither timeouts nor a watchdog is implemented right now in bipropellant-hoverboard-firmware.

How do you all have your debug configuration setup? I'm using the PIO setup in windows with ST-Link V2 (generic ebay kind). Are you using black magic probe or similar?

My brand motherboard YST, after firmware use Motor Test Mode just 1 wheels spinning...how this problem?

int scale[2] and float scale (in PPM code)

Has somebody compiled the API on X86? It's a bit a puzzle still. Has anybody gotten beyond that point already? I get the millis() are to be replaced, but where is setup_protocol(). Cannot find it.

Tx

-T430s:~/bipropellant-hoverboard-api/my⟫ g++ read.cpp ../src/HoverboardAPI.cpp ../src/hbprotocol/protocol.c ../src/hbprotocol/machine_protocol.c ../src/protocolFunctions.c ../src/hbprotocol/ascii_protocol.c -I ../src -I ../src/hbprotocol -lserial -std=c++11 -Wwrite-strings -Wnarrowing -fpermissive

...............

../src/hbprotocol/protocol.c:322:1: warning: ISO C++ forbids converting a string constant to ‘char*’ [-Wwrite-strings]
../src/hbprotocol/protocol.c:322:1: warning: ISO C++ forbids converting a string constant to ‘char*’ [-Wwrite-strings]
../src/hbprotocol/protocol.c: In function ‘void protocol_process_message(PROTOCOL_STAT*, PROTOCOL_MSG2*)’:
../src/hbprotocol/protocol.c:433:67: warning: invalid conversion from ‘void*’ to ‘unsigned char*’ [-fpermissive]
unsigned char src = params[writevals->code]->ptr;
^
../src/hbprotocol/protocol.c:458:68: warning: invalid conversion from ‘void’ to ‘unsigned char*’ [-fpermissive]
unsigned char dest = params[writevals->code]->ptr;
^
../src/hbprotocol/protocol.c:498:68: warning: invalid conversion from ‘void’ to ‘unsigned char*’ [-fpermissive]
unsigned char dest = params[writevals->code]->ptr;
^
../src/hbprotocol/machine_protocol.c: In function ‘void protocol_send_nack(int ()(unsigned char*, int), unsigned char, unsigned char)’:
../src/hbprotocol/machine_protocol.c:262:53: warning: narrowing conversion of ‘som’ from ‘unsigned char’ to ‘char’ inside { } [-Wnarrowing]
char tmp[] = { som, CI, 1, PROTOCOL_CMD_NACK, 0 };
^
../src/hbprotocol/machine_protocol.c:262:53: warning: narrowing conversion of ‘CI’ from ‘unsigned char’ to ‘char’ inside { } [-Wnarrowing]
../src/hbprotocol/machine_protocol.c: In function ‘void protocol_send_ack(int ()(unsigned char, int), unsigned char)’:
../src/hbprotocol/machine_protocol.c:268:65: warning: narrowing conversion of ‘CI’ from ‘unsigned char’ to ‘char’ inside { } [-Wnarrowing]
char tmp[] = { PROTOCOL_SOM_ACK, CI, 1, PROTOCOL_CMD_ACK, 0 };
^
/tmp/ccihzymg.o: In function tickWrapper()': HoverboardAPI.cpp:(.text+0x5): undefined reference to millis'
/tmp/ccihzymg.o: In function HoverboardAPI::HoverboardAPI(int (*)(unsigned char*, int))': HoverboardAPI.cpp:(.text+0x34): undefined reference to setup_protocol'
HoverboardAPI.cpp:(.text+0x6f): undefined reference to delay' /tmp/ccx2ZUJZ.o: In function protocol_init':
protocol.c:(.text+0xb0f): undefined reference to ascii_init' /tmp/ccsJ09fJ.o: In function protocol_byte':
machine_protocol.c:(.text+0x89): undefined reference to `ascii_byte'
collect2: error: ld returned 1 exit status

I was testing ASCII Immediate protocol Is worked well, but when I tried Iw the motors started at 100, 200 and at 400 suddenly the motors stopped abruptly.

I noticed system was off so I tried to restart it but no luck. Checked voltage and it had suddenly dropped to 20V and dropping very fast.

No here are some observations

1. Even when power is turned off my right wheel is somewhat rigid but if I remove the yellow power cable to the wheel it turns ok when turned by hand.
2. When charger is connected battery doesn't charge (charger light stays green)
3. I am able to power of the microprocessor and use ascii protocol to to run some commands like ?, G, C etc. But as soon as I send any Immediate commands to turn motors the microprocessor powers off without power-off tune.

Questions?

1. Is my board fried? Why is it not charging or turning?
2. How can I test?
   The battery is getting 41V but still not charging. I will leave it on overnight and see.

thanks

Reminder from #39

Also we should do some housekeeping and format all file headers.

I have a feew boards where the readout is not locked, here is a backup of them.

Its in HEX format.

https://gist.github.com/atc1441/c4cc8af0dc0ed48994210da552985a14

maybe you need it when you want to go back to stock, it works with the dauther boards in this picture:
https://www.bilder-upload.eu/upload/58cb89-1561888915.jpg

Hi guys. I've got a board that is based on GD chip
Has anyone managed to run the firmware on these boards?
Could you advice on how to configure it properly?
I've got several theories but it would be great is someone could confirm.
As mentioned in config file the baud rate for GD chips is 52177
Below are a couple of configuration schemes

First option is to select
#define CONTROL_TYPE SOFTWARE_SERIAL_A2_A3

So i need to change the baud rate to 52177 in

// ##### SOFTWARE SERIAL #####// // there should now be a free choice of serial GPIO pins #define SOFTWARE_SERIAL_BAUD 52177

The second option is to select
#define CONTROL_TYPE USART3_CONTROLLED

and to change the baud rate in
// #define SERIAL_USART3_IT #define USART3_BAUD 52177 // UART baud rate

Do I get it right?
Sorry if my questions are a bit dumb :-)

Hello everyone,
I'm back and I see you made a lot of improvements!
I updated today the firmware of my HB but I have a problem:
Using USART2_CONTROLLED (or your predefined usart2 PIO env) I'm no more able to control speed or posn inc of the robot...
The serial is replying correctly to test buffer, hall position request, ... but when I send a speed command nothing happens...
Have you got any idea of what's not working?
Also, the board is sending some [119,13,1] buffers ("Sensor (Hoverboard mode)" ?), maybe something it is going into hb mode even if USART2_CONTROLLED is used?
Thank you!

There are two inactivity timeouts.

I tried to remove one but the one i chose to remove uses a variable in hbprotocol which is in another branch.

If hbprotocol is to stand on its own, it shouldnt depend on variables declared in other files such as main.c.
We should combine the two inactivity timeouts or eliminate one of them

as noted in #2 and bipropellant/bipropellant-protocol#7

Hello,
I have a problem with flashing the firmware with Windows 10. I have connected the USB -ST link v2 dongle as described without 3.3v.
The STM32 ST Utility 004 writes "Can not connect to target". I really do not use the 3.3volts? "why"???
please help.... I really not use the 3.3volts?
I have connected the motherboard with an external power supply 36V.

Firstly, thanks for creating and updating this project!

I've been looking at the ADC functionality added by @p-h-a-i-l in PR #55 , as it's exactly what I'm after (previously I was looking at the BBCar repo).

I've followed the Wiki page on ADC and Defined CONTROL_ADC, along with setting the ADC values for single-pot mode, but I get the following compilation error:

inc/config.h:489:6: error: #error SERIAL_USART2_IT not allowed, cable already in use.
     #error SERIAL_USART2_IT not allowed, cable already in use.
      ^~~~~
make: *** [build/setup.o] Error 1

I've attempted to #undef DEBUG_SERIAL_USART2 and SERIAL_USART2_IT (both together and individually) but that results in multiple compilation errors.

Is there something I'm missing in order to compile in ADC Mode?

Hi,
The wiki mentions using Node Red for serial control, just wondering if you had an example flow that could be used?

I have a basic flow set up with an injector sending an ascii string to the serial port (USB -> USART2 , I've also set Control Type to USART2_CONTROLLED via config.h)

When I sent any payload, the wheels start spinning. Tried sending ? or T etc, doesn't seem to matter what I send, but wheels start spinning.

Pretty new to all this, so if you have an example flow setup, that might help figure what is wrong.
Cheers,

I would need a info or a tip, if there is now a Hoverboard-Fimware where I can steer 100% perfect in all 4 directions, either with a anlogen joy-stick or hall-joysick or a nunchuk.

maybe has such a firmware ????

Currently the main loop timing is determined by a delay at the start of the loop, and so the loop interval could vary.

We should change this to be 'delay until 5ms after the start of the previous loop', or 'delay until the next 5ms tick'.
When we do this, we should probably instrument the time in the main loop, and always delay by at least 1ms.

e.g.

unsigned long now = HAL_GetTick();
unsigned long start_processing = now + DELAY_IN_MAIN_LOOP;
unsigned long main_too_long = 0;

// main loop
while (1) {
  unsigned long time_in = now;
  if (start_processing < now) {
    main_too_long++;
    start_processing = now + 1;  // at least 1ms of delay
  }

  // deliberate delay loop
  while (now < start_processing){
    // do idle stuff - e.g. comms.
    now = HAL_GetTick();
  }

  unsigned long processing_in = now;

  //////////////////////////////////
  // do 5ms main loop stuff
  //////////////////////////////////


  ////////////////////////////////
  // take stats
  now = HAL_GetTick();
  unsigned long main_interval = now - time_in ;
  unsigned long main_delay = processing_in - time_in ;
  unsigned long main_processing = now - processing_in ;
  // maybe average main_dur as a stat?

  // select next loop start point
  start_processing += DELAY_IN_MAIN_LOOP;
}

/////////////////

thoughts?

The LED flash routine doesn work in the older generation sensor boards. The protocol is unknown and is low priority until it is decoded.

@btsimonh Are you working to update protocol submodule? I am just trying to remind you in case you may forget.

New thread.....

Continuation of #32

Concrete information can be added here:
https://github.com/bipropellant/bipropellant-hoverboard-firmware/wiki/Notes-on-BLDC-Drive-and-Hoverboard-motors
or as additional pages on the wiki :).

it's no wonder these are renowned for starting fires:

On my second hoverboard, the inside edge of the joining tube is RAZOR sharp!
No wonder this came to me in a non working state....
Will dismantle and relieve with Dremmel, and re-insulate.

Hi, in line 259 in file BLDC.c is a type, the accerage current will always be for the Left motor even when you try to read motor[1]

electrical_measurements.motors[0].dcAmpsAvgAcc += ABS(adc_buffer.dcl - offsetdcl);
electrical_measurements.motors[1].dcAmpsAvgAcc += ABS(adc_buffer.dcl - offsetdcl);

see here:

Would be interested to hear other's experience with serial control and noise on the lines....

I've done quite a bit of (software) investigation, and am coming to the conclusion that my wiring is not thought through enough (laugh at my setup here.

I use software serial, and when the board is under load (e.g. with current limit set at 1A and a motor held still with drive - on the sinsquash PR, so current limiting should be graceful), when I send characters to the board, a LOT are wrong :(.

I also see quite a few sensor misreads at times.

From a software perspective, I'm now running GPIO_SPEED_FREQ_LOW on all FET drive lines, and on the serial RX GPIO, and i think it reduced the noise, but it's still unacceptable....

My next step will be to re-work the physical installation, maybe shield the sensor serial and the software serial lines, and put in thicker ground lines between my pi and the main board.
@EmerickH - did you solve all your comms issues in the end?

would add this repo to my online compiler www.pionierland.de/hoverhack

errors so far:

• control_structures.h:
  #include "protocol.h" -> #include "protocolfunctions.h"
• protocolfunctions.h:
  #include "protocol.h" -> ``

Now i get

inc/protocolfunctions.h:8:8: error: unknown type name 'PROTOCOL_STAT'
 extern PROTOCOL_STAT sSoftwareSerial;

There is no PROTOCOL_STAT defined anywhere into the repo.

Hello!
When trying to compile your code I get a "no such file or directory" about the #include "protocol.h" on the main file. Is it really missing from the repo?

Thanks

I have this odd problem, when board powers on as soon as the battery is connected. You could expect this if the power button is faulty, but no! It reacts to button presses and turns off to endless bleep. Tried with original firmware and got same result.
Do you have any idea what went wrong?

Hi All,

Need some help in determining SWD pins. sorry this is not an issue.
I got a replacement board from ebay but it turned out to be a different microcontroller AT32F403RCT6. The board is
YST board

Does any one know is the SWD pins are the same? my ST-link doesn't detect in the layout of green board.

Is there a way I can find out the pins of which is which by probing voltage or something? I blue my old board by connecting 3.3 so want to be really safe.

thanks

Hello,
I am trying to control the board without sensors attached and using one arduino nano.
After loading the firmware with the #define CONTROL_TYPE USART3_CONTROLLED on config.h and using the provided arduino example on the same file
`void loop() {

int sensorValue = analogRead(A2);

speed = sensorValue;
Serial.write((uint8_t *) &steer, sizeof(steer));
Serial.write((uint8_t *) &speed, sizeof(speed));
delay(20);
}` with a serial speed of 115200 but I simple don't get any sort of movement.
When using the ASCII all works has it should...
Is there anything else I should look for? Is this info correct?
Thanks

I need the absolute Hallticks. Thus added an enum for it in Codes ({ 0x07, "hall position steps", NULL, UI_NONE, &contentbuf, sizeof(PROTOCOL_POSN), ... )
in alignment of corresponding function and code in protocol.c/h.

Via API i can now do this.

hoverboard.requestRead(HoverboardAPI::Codes::sensHallPosSteps, PROTOCOL_SOM_NOACK);

Question: Where do i find the result once the request is completed?

Thank you.

I am working with machine protocol with #39 . Today I had one crash upon sending speed command. Board powered off, I turned it back on and checked temp with ASCII.... It was 140C.... Inspected with thermometer and it was only 35.

Originally posted by @AntumArk in #30 (comment)