Raspberry Pi integration - Node Red Example about bipropellant-hoverboard-firmware HOT 24 CLOSED

try the one here:
https://github.com/bipropellant/hbprotocol/tree/master/examples/nodered

i'm not sure of it's status at the moment; have not run it for a couple of months, and not sure If I updated the repo for latest protocol changes.

it's very much a 'test' flow, and does not do anything useful (just reads some data, and allows tests the protocol). I know I have a more complete/competent flow on the HB itself, but to extract it I have to power up! (will see what I can do later).
The first thing I usually do after boot is 'stop debug and stop power off'....
p.s. you found this new repo quickly! We only put it up yesterday :).

from bipropellant-hoverboard-firmware.

Awesome thanks, I'll try this. Sorry I hadn't noticed it earlier, I didn't think to look on the protocol repo. Test flow is perfect, I'm just trying to figure out if I'm sending things incorrectly, or if it's not handling correct messages properly. I'll test it this evening.

p.s. you found this new repo quickly! We only put it up yesterday :).

I've gone down a rabbit hole on these repos - there are half a dozen different forks, or forks of forks of the original Fauth ones but most seem to be pretty stagnant. I was very excited when I stumbled on this one and saw that you guys were still very active. Appreciate the work you're doing on this.

from bipropellant-hoverboard-firmware.

check the issues in hbprotocol - @p-h-a-i-l is currently running stuff up based on the protocol move. he's ESP32 based for drive. Just note that since everything has been moved and hbprotocol split off, we're in the process of re-checking operation :).

from bipropellant-hoverboard-firmware.

@adverst - firmware may work better today :) Except for flash write - flash will start at defaults every boot (or does for me). I have not tested with USART2 (have sensor boards attached).
I could not correlate your original issue of motors starting for any byte received - unless somehow ADC control or some other control mechanism has hooked over the top of the USART2 pins.
Ahh.. but you would not have got any reply, certainly, as the Ascii protocol was 'locked' we've now made this obvious, and you must send 'unlockASCII\n' before sending anything except machine protocol (but now it will tell you!).

@bipropellant/founders - perhaps we should commit example working config.h for USART2/3 without sensors?

• although that is really what
  #define CONTROL_TYPE USART2_CONTROLLED
  should do?

from bipropellant-hoverboard-firmware.

@btsimonh I personally just have to change #define CONTROL_TYPE USART2_CONTROLLED, nothing else
Maybe we can write in the installation guide of the wiki that you need to change this parameter to your use before compiling.
The NodeRed example is still working fine for me, I have a version were I added more controls but it's very mess: I need to clean it before sending here!

from bipropellant-hoverboard-firmware.

Ok thanks, meant to check last night but wasn't able. Will try to give it a crack tonight

from bipropellant-hoverboard-firmware.

@adverst don't forget to change the serial modules in the Nodered to your serial port/baudrate (115200 for USART2 I think by default)
I know I had problems with serial transparency, if you still have problems send the output of:
stty -F /dev/ttyUSB0 -a (or replace /dev/ttyUSB0 by your serial port device)

from bipropellant-hoverboard-firmware.

yes - serial transparency was an issue - and making it stick?

from bipropellant-hoverboard-firmware.

I don't remember having issues to make it sticky, but like my board was also defective at this time, I don't know if there was really a serial transparency issue too...

from bipropellant-hoverboard-firmware.

(just pushed my test.txt flow to examples in the sub-repo - but that commit is not referenced by the main repo so you may need to view raw and copy)...

from bipropellant-hoverboard-firmware.

Just tried it with updated firmware and that flow... When I send anything, eg stop debug and stop poweroff, one of the wheels goes to max speed immediately (violently!). Send something else, the other wheel does.

Maybe crazy question - is left sensor or right sensor USART2? I think right sensor is 2, left sensor is 3?

By right and left I mean

from bipropellant-hoverboard-firmware.

Progress!!

2 & 3 are reversed to how I have them above (on this board). Left is USART2.

I couldn't get comms working with raspberry pi and node red, but using terminal on windows I can communicate. I realize the issue I opened here was for rpi, but I just wanted to make sure the issue wasn't elsewhere. So from windows, sent a message, received back 'Locked. Enter UnlockASCII to enable'. So, did that, unlocked it. Can now communicate.

But - she doesn't want to go. I can enter immediate mode, and send commands, but no motion.

Wiki for the protocol lists B - toggle sensor control, but current protocol doesn't support that. Is there some other command required for immediate mode to work to control?

I can read hall positions, speeds, currents, GPIO's etc.

Also, I'm now getting a stead beep after I have it powered on for a while. Battery voltage seems high enough so not sure what that is

Tried Fa per the protocol wiki - Get:

>>Fa
flash magic(m): 1234
posn kp x 100(pkp): 50
posn ki x 100(pki): 50
posn kd x 100(pkd): 0
posn pwm lim(pl): 200
speed kp x 100(skp): 20
speed ki x 100(ski): 10
speed kd x 100(skd): 0
speed pwm incr lim(sl): 10
max current limit x 100(cl): 1500
hoverboard enable(he): 0

I set hoverboard enable to 1, if I send immediate mode commands now still no dice. Wasn't sure if that was meant to be 'hoverboard mode' enable or to just outright enable the motors.

I am also getting a high pitched whine now - not sure what it is coming from, not the motors, something on the board. Not sure what that's about 😐

from bipropellant-hoverboard-firmware.

1/ not sure on steady beep - there is a power off timer, which should beep, beep, beep a lot before power down, prevented with command 'P\n'. From main.c, looks like a steady beep could be temp warning or backwards. Never heard backwards beep, so maybe temp warning - you may have a different temp sensor? for ref, when I press 'c' it shows:

Bat: 35788mV(0) Temp:33C(1675)
L: Current:379mA Avg:126mA r1:364 r2:364
R: Current:439mA Avg:126mA r1:358 r2:358
(when crawling off load as below log)

2/ hoverboard mode should be disabled (in code) if using USART2/3. The three 'modes' at the top should be fine defines for working configs - but I only use the software serial one - @EmerickH may advise exactly what his config is (or search out his personal repo & compare). Hoverboard mode literally means 'allow the board to use the original sensor data'.

3/ try 'fi\n' (flash initialise, just ensures default data as above), then 'fm1234\n' (write all data to flash). Flash WAS giving me some trouble, but the trouble subsided without apparent changes :(. check actual flash content with 'mf\n' (last commits last night).

4/ looking at the code for USART2/3, I think you get console logs always - pls report if you see a log about flash base when doing 'fm1234\n'.

My 'normal' ascii protocol startup is something like:

unlockASCII
ASCII input active. Type ? for help

>>p
disablepoweroff now 1
powerofftimer now 0

>>iw
Immediate commands enabled - WASDXHCGQ - Power (pWm) control
>
>>
(now press w....)
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 90, steer now 0, pwm 45, pwm 45
>speed now 100, steer now 0, pwm 50, pwm 50
>

results in a slow crawl (not a lot goes on until pwm >~40)

Once this is working, try 'ip\n' (pid position) and 'is\n' (pid speed).
The first letter is usually case insensitive. subsequent letters may be case sensitive. Everything should work with lower case :).

I just tried 'i\n' after fresh boot, and my board does nothing with 'w'.
I think latest change may require 'iw', 'is' or 'ip' to set the control mode to something other than none!

have fun!
Simon

from bipropellant-hoverboard-firmware.

p.s. sounds like linux serial is not right. for ref:
to connect to the hoverboard from the pi, i use:
screen /dev/ttyUSB0

I have great trouble ending the session, i've taken to using another SSH to:
screen -X quit

I can't remember ALL the things I did to make serial work; but check:

pi@raspberrypi:~ $ groups pi
pi : pi adm dialout cdrom sudo audio video plugdev games users input netdev bluetooth spi i2c gpio

I think I added dialout.....
And then there is DEFINITELY serial transparency to sort - the protocol is broken by \r\n translation in the std linux serial I/O - and it 'sort of works but not' which is a pain.
(stty -F /dev/ttyUSB0 -a (or replace /dev/ttyUSB0 by your serial port device) - from above).
Also, watch out for running the NodeRed flow AND screen at the same time - on mine, input characters get to both, but some to one and some to the other! Just disable the flow if you want to go direct - and make sure you don't have multiple flows enabled!

p.s. As you work through the RPi serial issues, keep good notes, and we'll put a page on the wiki....

from bipropellant-hoverboard-firmware.

I added some instructions to wiki, especially to use with a Raspberry 3
https://github.com/bipropellant/hoverboard-firmware/wiki/Raspberry-Pi-integration
I also added a page "Making your serial port transparent" with what you need to have but I do not remember exactly how to use stty command line

from bipropellant-hoverboard-firmware.

looks like a steady beep could be temp warning or backwards

In config the temp warnings are currently disabled (by default). I haven't changed these. Only beeps enabled in config are low battery... Possible it's detecting low battery after it's been run a while, but voltage seems ok. I see bits for battery calibration there which I haven't done.

I had output the sensor data, I thought I'd included it. I'm not where the hb is now though so can't check, but I think it was showing temp ~38c.

2/ hoverboard mode should be disabled (in code) if using USART2/3. The three 'modes' at the top should be fine defines for working configs - but I only use the software serial one - @EmerickH may advise exactly what his config is (or search out his personal repo & compare).

Yeah I haven't edited/changed any config other than the mode at the type. I did look at @EmerickH personal repo, that's a different config, it's based off the isabellesimova/HoverboardFirmware fork so is a bit different. I'd tried that one on a couple of different boards, it didn't work for me at all.

try 'fi\n' (flash initialise

I'll try all this tonight.

Question on the immediate mode - when using the terminal in windows I have to specify carriage return or not, I still had it set for immediate mode commands. Could this have prevented them working? Although quit seemed to work, just none of the motion commands.

p.s. sounds like linux serial is not right

It shows as connected in node-red, but not much else. Now that I know I can actually communicate back and forth (even if wheels don't spin) I'll try again from rpi. I checked my stty output as directed by @EmerickH in the docs, my output matches (except 115200) baud

p.s. As you work through the RPi serial issues, keep good notes, and we'll put a page on the wiki....

Yes absolutely. I'm happy to help write up update/write up some docs when everything is behaving

from bipropellant-hoverboard-firmware.

It will register non immediate commands as soon as either \n or \r are received.
Immediate commands work from each byte received.
Do you remember trying 'Iw', 'Is' or 'Ip'? If not, plain old 'I' does nothing for me either :).

from bipropellant-hoverboard-firmware.

Do you remember trying 'Iw', 'Is' or 'Ip'? If not, plain old 'I' does nothing for me either :).

I hadn't done the Iw Is or Ip, these are listed for direct to position/speed etc. I'd just tried the WSADX - Entered I to enter immediate mode, then had sent W, S etc. I think the commands were sending/receiving properly, because when I sent Q it exited immediate mode.

Output here, I'd entered immediate mode, then sent a bunch of W, S etc, then Q to quit:

(sorry for image, can't copy paste from prior terminal session)

I'll try with direct position control when I'm back at the machine later. I'll also try to setup proper debug so I can see what's actually happening

from bipropellant-hoverboard-firmware.

More success!

I didn't change anything from last night, but for whatever reason now on the immediate commands I'm getting output like:

>>speed now 10, steer now 0, pwm 5, pwm 5
>
>speed now 10, steer now -10, pwm 5->0, pwm 5->10
>
>speed now 0, steer now -10, pwm -5, pwm 5

At first I still thought nothing was actually working, but then I saw @btsimonh comment about nothing happening until > 40... so I just continued jacking up the speed.... and it's alive! Speed working, control working, all operating correctly I think.

So now that I know everything is operating correctly I'll switch back to the pi to sort that out and figure out the serial comms there.

from bipropellant-hoverboard-firmware.

What is your target application? - if you have a brief write up of what you dream of achieving, we could add it to the wiki to inspire others :). My application is not so fixed at the moment (so even I could do with some inspiration); @p-h-a-i-l and @EmerickH both have different nice practical projects :).

from bipropellant-hoverboard-firmware.

Node red is also running fine now from Raspberry Pi. I wonder if I just had a bad flash with my earlier attempts.

In terms of 'what I did' - it's pretty much good to go on a stock raspbian install. Install node red, import the sample flow. When I use the example flow, sending ? returns the unlock ascii command. Only change I had to do was when you import the node layout, you need to configure the serial ports for baud rate etc. The sample there doesn't have nodes for unlock ascii etc, but easy enough to add.

For my target application - I'm attempting to build a remote controlled golf cart. You can buy them, but that's just too easy. So now that I have working firmware, and working comms from the rpi, next step is to settle on what is the best method for a remote control. I need to learn a little more node-red to figure if that's a good way of laying out the interaction, it seems pretty good so far.

Fact is there are TONS of applications for the sort of cheap programmable motion that this platform provides.

So this 'issue' can probably be closed. I think everything is working as you'd expect. If I get time, I might tweak this node red flow a little so taht it includes all the basic commands etc. Maybe add in the wiki somewhere that you wont really see any motion until you get to a high enough speed, because that threw me initially. I think mine was working sooner than I realized, I just hadn't told it to go fast enough yet.

from bipropellant-hoverboard-firmware.

good to know it's all happy;
ref control, if it's to be manually controlled, talk to @p-h-a-i-l - he uses some form of common controller, and an ESP32 as the 'host'. I have played with wiimote and a bluetooth joystick thing, but bluetooth was a bit of a disaster area for my on RPi so far (difficult to maintain connection, and complex to install correctly). In theory you can do bluetooth on the esp32 from scratch...
Also looked at bluetooth to android ('automate' maybe? - you can do enough with the free version for tests).
But with a Pi and NR, the sky (and CPU) is the limit for imagining control strategies :).

Do keep us updated, and post pictures as the physical thing comes together. Before I found the HB, I considered a 2nd user Golf cart as my movable base!.

p.s. watch out for serial port transparency - if it's not transparent, it will 'kind of work' but not. Test with lots of 'T' commands (pretty sure that flow has some code which does random size and random content 'T' messages), and log failures & timeouts over a period to ensure you are good.
Also be aware of @EmerickH 's previous power/earth issues (see my old repo issues for gory detail) - basically ensure your controller shares a solid ground with signal ground of the HB mainboard - the motor current draw can cause a lot of noise, which you would see if, for example, you took your RPi gnd from the battery direct, not from the HB mainboard. Worst thing is you may only see an issue when you start driving hard - which is the exact moment you don't want to lose control!

from bipropellant-hoverboard-firmware.

closing dues to age. current example flow not necessarily up to date. will look to update..

from bipropellant-hoverboard-firmware.

updated testflow

from bipropellant-hoverboard-firmware.