Clarification wanted

[MTRatcliffe]

Hi, Im struggling a little to understand how to communicate with the board via serial. Could you describe the wiring diagram for serial control, ie what pins I should use on the control board. Im planning to use a esp8266 or esp32 if that makes a difference? Thanks, Mike

[btsimonh]

Hi Mike,

are you scrapping the sensor boards; if so then you can use USART2 or USART3 using the cables which normally connect to the sensor boards. Careful, as these carry +12v as well as the 3.3v serial tx/rx and gnd. (a good source of volts for your ESP via a cheap DC-DC by the way)... My HB is not open at the moment, but I'd assume the gnd is black, +12v is red, and the other two wires are the 3.3v serial.... I tested with a USB serial convertor & a PC at first to get the wiring right (hint: 'realterm' is fairly sweet for a windows app for looking at serial from an engineering perspective). If you intend to keep the sensor boards in place, then you would need to use 'software serial' (expect a few serial errors, but the protocol correct these). For this, it very much depends on your HB motherboard; mine has some very convenient solder points (see https://github.com/btsimonh/hoverboard-firmware-hack/blob/newprotocol/otherboards/ExtraPins2.jpg)

use the newprotocol branch (which I've just made the default.... ), but you will need to change settings in config.h; theoretically only:

define CONTROL_TYPE HOVERBOARD_WITH_SOFTWARE_SERIAL_B2_C9

to the type you want....

Looking forward to your contributions! I've not much time at the moment, so feel free to suggest and implement protocol enhancements. We're pretty happy with the base protocol now; so now it's down to HOW we control the things, and adding cool stuff like fine slow speed movement. (the pid control is a little sloppy... position control ~5cm - when we should be able to achieve ~5mm).

br,

Simon

[MTRatcliffe]

Hi Simon, thankyou for the quick reply.

I had been using the usart2 to communicate with the external micro-controller from the main repo this code is based on[sensor board disconnected], but wanted to retain the function as a hover board. The easiest fix for me may be to just add the ground pin for the sensor board to a three way switch [external mcu or sensor board ground connected, not both]. My main hover board controller does not have spare pins broken out like the one in the image.

define CONTROL_TYPE HOVERBOARD_WITH_SOFTWARE_SERIAL_B2_C9 , it is this bit that confused me, when looking at a stm32f10XX pin-out I dont see these pins, does B2=PB2 and C9=PC9 in this case? http://joe-c.de/media/all/microC/STMF103RxTx_pinout.pngI am new to STM32 programming, im sure I will pick it up but at the moment my actual code offerings would be of no help.

I do however know quite a bit about feedback loops, the ticks from the hall sensors with a 6.5 inch motor/tyre correlate to a forward/backward step of 5.76mm [my maths may be off]. So a PID feedback loop would be at max good to two hall steps [11mm ish], do the sensor boards give you a read out for acceleration in all three axis? If so it should be possible to add a forwards acceleration reading and hall reading to a kalman filter [or complimentary filter] to get a more accurate slow speed/location control.

All the best, Mike

[btsimonh]

:) exactly where I was at; one hoverboard, and two applications....

One of the issues with using USART2 for both with one firmware is that the sensor board serial is a stupid 9 bit serial; they seem to signal start of message using the 9th bit (or maybe end, can't remember). But the fact is that 9 bit serial is a rarely supported thing in 'normal' devices - e.g. a usb too serial won't do it.... so with a switch, you firmware would also need to change the serial parameters to swap between modes. (this could be possible - I switch to HB mode with a 'double tap' on the foot sensor pad).

so; B2 C9 - the pins in the photo are marked 40, 28, 44 - these were the pins on the MCU; so two of these pins must be my B2/C9. looking at your diagram, 28=PB2/BOOT1, 40=PC9. I did identify a couple of other available pins, (see ExtraPins3), but rejected them from a 'I can't see to solder to something that small' perspective... Since all HB firmware SEEMS so be very similar, I would trace PB2/PC9 and see if you can find a convenient place to hook to them. The should not already be connected to anything important (and if they are the firmware won't work anyway!).

ref the pid control; I was really excited when the code I put in just worked; but lacked the time to really think about the final implementation; It works nicely for speed - controlling speed by setting power alone is not great for a robot application. And for posn, it worked, but just with a huge dead zone.

For slow speed, I think we'll need sinusoidal drive. There a great hackaday where someone drives a syncronous motor REALLY Slowly. But so far, I've not found anyone who has implemented sinusoidal on a HB (except the original firmware maybe!). p.s. when running in HB mode, our firmware does have a slight 'grindy' undertone as it swaps sharply between which coils have power. But, it does work pretty damn well! As far as I know, this is the only repo which attempted to reproduce true HB functionality.

Ref sensors. We get 16 bit angle fwd/back (duplicated), and 16 bit angle side to side, and maybe an 8 bit acceleration (duplicated) (see https://github.com/btsimonh/hoverboard-firmware-hack/blob/newprotocol/inc/sensorcoms.h ; the first 7 variables in the structure are what we get raw). But I didn't consider using the acceleration value... however, the processes required to continually re-calibrate (e.g. when going up an incline?) are beyond my brain power at 8am on a sunday! But; the fact the acceleration is sent twice kind of indicates this was an important value in the original firmware; yet I don't use it at all at present. Maybe the 'Hoverboard' mode can be improved too by using this value; e.g. 'angle -> desired acceleration -> modulate power to achieve required acceleration'? rather than the simple 'angle -> power to wheels'.

p.p.s. if you have an STM based board, would be really interested in your assessment of the sensor board baud rate; mine needs 52177, but others have analysed and got 26300. What I'm not clear on now is if this is because the chips are 'mildly' different, and the std HB firmware does not configure the clock correctly (the GD32 runs a faster clock), and so it's just an artefact of lazy production, or if it's different for a reason. My analysis of the protocol data matched others' analysis, just the baud rate was off. But just highlighting you MAY need to change it in config.h for STM based sensor boards.

have fun and let me know how you get on :)

[btsimonh]

@EmerickH @p-h-a-i-l check out Mike's idea on use of acceleration above....

[MTRatcliffe]

Basic noob questions: I dont mind cycling the power after switching the switch, In the setup routine then it should be a case of checking the serial protocall being used and decide if its in robot mode or hover board. That being said I still haven't wrote more than a few lines of code for a stm32.

Right now im editing the code in a text editor [not the best way] do you have any advice on a coding environments? [ie I now see that arduino is covering STM32f10xxx].

"so; B2 C9 - the pins in the photo are marked 40, 28, 44 - these were the pins on the MCU; so two of these pins must be my B2/C9. looking at your diagram, 28=PB2/BOOT1, 40=PC9." I feel like I am missing something here still, is there a pin mapping file that maps the STM pins to other names included in the repo?

Some insight into more precise position control: Is this the video you are referring to?: http://www.berryjam.eu/2015/04/driving-bldc-gimbals-at-super-slow-speeds-with-arduino/ If I understand the tutorial correctly he is changing the power to all three coils so that they make a rotating magnetic field similar to a 3-phase sinusoidal power source, but moves the speed out of the time domain [ie 50hz] and into a user controlled time frame. ie tick one degree forward whenever I ask.

This is relatively simple to implement and works well when you dont care about power usage [that is, choose a power setting and slowly increment the magnetic field position] But it doesnt use feedback and just assumes the motor torque was enough to move the rotor and we wouldn't know if this was true until a hall tick occurred/didnt when expected. Could always calibrate it first when its on a robot by running it at full power and halving the overall power until we dont get a hall tick as expected, then add a safety margin and call it running-power-min. Our step resolution here would then only be limited by how many bits the PWM is, a lot more than a hall sensor tick.

Sensor Board Maybe the sensor board is already performing this internally, but to get good angle reading from a IMU we need to filter them. In short the gyro's drift [so flat wont always be flat] and acceleration is noisy, but when both of these are fed into a kalman or complimentary filter we can get a low noise low drift angle reading.

The sensor boards I have dont have s real stm32 chip on board, but a generic Chinese copy i believe it is the GD32 [im not complaining it seems to work just fine].

In short, im still stuck at the beginning of deciding what ide to use to make changes to the code :D

All the best, Mike

[btsimonh]

Hi Mike,

0/ detecting the serial protocol at boot MAY be a more complex problem. I suppose it is possible to boot with the sensor serial configured, and then if not getting the sensor protocol, re-configure the USART... the sensor data is continuous.....

1/ PlatformIO in vscode. Provides the complete build environment and editor :). Theory says you install vscode (free), and then the platformio addon (free), open my folder, and hit build. At that point, it will download all the tools required, and build with no further intervention. And it you hook up your STLink programmer, it will even program it for you!. (I use openOCD from my RpiZero for programming, as the RpiZero is inside the HB). Although it should also still work in the Arduino GUI, personally I find that a little too dumbed down.

2/ B2/C9: my

define CONTROL_TYPE HOVERBOARD_WITH_SOFTWARE_SERIAL_B2_C9

define causes the following to be active:

define SOFTWARE_SERIAL_RX_PIN GPIO_PIN_2

define SOFTWARE_SERIAL_RX_PORT GPIOB

define SOFTWARE_SERIAL_TX_PIN GPIO_PIN_9

define SOFTWARE_SERIAL_TX_PORT GPIOC

so B2 -> port GPIOB, pin 2. C9-> port GPIOC, pin 9 Each GPIO has 16 'pins', some of which are general, but most optionally have other functions as well according to the MCU setup...

3/ yep - that's the video :). yes - BETWEEN hall ticks, and at low speed, you'd power the magnets at 'enough' power to guarantee a position; for the period you want to maintain that position. Over a certain speed, when you have regular ticks and can estimate posn accurately by estimating speed, then the drive scheme can change....

have fun,

Simon

p.s. for ESP projects, I like Tasmota as software a base. I have got a couple of ESP32, but feel the SDK is not yet mature for my use...

[p-h-a-i-l]

Interesting idea to use the Acceleration sensor data as an additional parameter for PID. Unfortunately in my applications, I do not have the sensor boards anymore.

Regarding ESP: Why do you chose Tasmota as base? I thought this was specialized for home automation?

Btw, I plan to switch my "stable" branch to the new protocol and add the PID features. I hope I can have them fully merged some day :)

[btsimonh]

@MTRatcliffe - note move of repo to https://github.com/orgs/bipropellant