Serial TX problem

[EmerickH]

Hello, I've tested the latest pidcontrol code and it's now working BUT I still have some problems with TX (STM32 -> Raspberry). I can list commands, change PID values but everytime I start motors it's going crazy! (RX is still perfectly working)

• With UART2:

  When the motors are starting (W command) I can see a regular perturbation (PWM?) wich is translated in random characters in my console (with some correct characters in the middle)

• With UART3:

  A little bit different, before starting motors I can see a signal wich is I think normal serial return: (sorry it's a little bit blurred...) BUT I cannot see anything in my console And when I start with W command, it's going flat with just some littles peaks sometimes

I've checked for ground loops, I tried to isolate better my serial cables from motors one but nothing...

Any Idea? Do you think it's a hardware problem, STM32 one (interruption,...) or Raspberry one?

Thank you for this code wich is already incredible! Emerick

[btsimonh]

some thoughts. So, when the motors are running, they will be pulling PWM amps from the 36V, but also through the ground cable. so, for example, if you were to 'scope between battery negative and GND on the HB board with motors running, you are likely to see significant ripple, however thick the cables. So to stop this affecting you, your Pi ground must be taken from the HB motherboard, preferably close to the STM32 (watch out; I have a feeling that current measurement is done by measuring the GND float at the motors with a VERY small resistor in the GND - so you DONT want to be on a motor gnd, as these will have more disturbance). So; basically, I assume you have a DC-DC for the RPi. You'd need to connect it's input/output GND to the HB, and then it's +ve input to where you wanted to take RPi power from (I assume before the HB relay). And make sure you don't switch the GND cable! My Rpi is powered from the 12v from the HB (actually, from the sensor board).

But this does not explain why you don't seem to see any data any more with UART3....

[p-h-a-i-l]

How long are the leads you are using? Can you take a picture of your full setup? @btsimonh Yes, you are right, measuring the current is done via a shunt resistor. But I guess GND is taken from the UART Connector, so it should be save.

Have you tried supplying your Pi from a USB Battery Pack? Just to eliminate power supply issues? If you take power from the 12V rail (actually 15V on all of my boards..), you should have enough capacitors to stabilize.

One warning to the 12V supply: The voltage is generated via linear regulators, so every mA you take there is taken directly from the Battery. For example: If you need 100mA3.3V= 0.33W for your controller, you will draw 100mA36V=3.6W from the battery. I switched over to having a Buck converter on the 36V Connector (usually used for the BT SPeaker)

[btsimonh]

my DC-DC does not go as high as the possible 42v (safely) :( I think it's quoted at 30v - but point noted....

[p-h-a-i-l]

Yeah, that's an Issue - for now I'm using a LM2596 based module (0.57€ on Aliexpress) it is advertised as 35V capable, but the datasheet promises 40V with 45V absolute maximum. Needs to be replaced someday with something of the correct rating..

[EmerickH]

I've taken ground from the card and it's now better (some crashes sometimes but not often) and I can receive almost all characters correctly. I use a DC-DC direcly on battery 36v (it's a 45v max one). I'll try to sent you photos and details on my setup this w-e.

[EmerickH]

As promised, here's my setup:

My control card (with Raspberry 3 under):

It's a board made on JLPCB for 2$/20 boards DC-DC soldered directly on it.

Hoverboard mainboard:

Relay:

(it's at least 15A/Channel max I think so I use both relais in parallel to get 30A)

Parking sensor board with sensors on patellas:

Full robot:

(flight case imitation)

Full setup:

The robot is at start made for a theater play (gag of the box that moves alone, interact with actors...) but when the base will be developped, we'll maybe try to use it on others domains (industry,...)

[btsimonh]

:) nice. Funny, my daughter has a roland electric piano which lives in a flight case just a little too large to easily handle with one person. I suggested that I embed a HB in the case and do the whole 'follow me' thing for her gigging :). She highlighted that she'd wait until we had the whole Dalek stairs levitation thing cracked in version 2..... else we're just adding 5kg for little benefit.

Thoughts on your interference challenge: make sure ALL your heavy metal is grounded close to the main board. I would assume (but check) that the HB mainboard heatsink is ground, check it with a multimeter, and if it seems intended to be ground (on mine, it's bolted to the HB frame, hence the assumption), then add thick braid between it and the heaviest ground on the board, and to all your other metal components (including the HB chassis) - it's probably important that the motor shafts are a solid ground, else the metal of the wheels may bounce around quite a bit electrically - it's unlikely that the wires into the motor are attached to the motor shaft in any way. If this is already done (I note the heavy shielding on the motor wires), then maybe consider MORE metal, e.g. a grounded copper tape covering for your wooden baseplate.

I bet the actors just love it when it goes awol!

[p-h-a-i-l]

Very nice build, looks really clean. Funny how different all the Applications are. I'm working on a project page, will present mine soon :)

Regarding DC/DC setup: Make sure to have enough clearance for the maximum voltage. My DC/DC went up in Flames on the weekend after fully charging the battery. Took everything attached down, ESP and motor control board..

Relais: I'd exchange the two smaller ones with a bigger one. you never know where the current is really flowing when paralleling.

In the original setup, the Heat Sink of the motor control board is attached to the hoverboard Frame. Same as the motor axis'. But everything is floating, not attached to GND.

[EmerickH]

For the serial bugs: Even after changing ground origin for RPI, putting shield on cables, ... I still have a lot of ACK/NACK and some total crashes (like at the end): It's very strange because RX is working fine...

I will maybe try with an external USB serial adapter to see if it's better. (EDIT: Tested, I receive nothing)

For construction:

• In my hoverboard nothing was grounded like @p-h-a-i-l, but if it was a ground problem, why RX is working fine?
• I checked datasheets of my DC-DC and it can go up to 45V (I don't remember exactly but I checked before buying), 50V for input capacitor.
  • I know that the 2 relays solution is not very good but I never found on Amazon a single relay, that can be controlled with 3.3v and can make pass >30A... The best would be to use a 12V car relay and an optocoupler, but it don't have 12V on board....

[btsimonh]

@EmerickH @p-h-a-i-l - I just got a new hoverboard. It's a STM based unit, MB dated 20141028, sensor boards dated the same. Sensor boards are wired (not socketed). I'm looking for a donation of one or a pair of sensor baords :). (1 is broken; strange that the main board seems to see it, but it's not responsive - but seemingly no physical damage, but a 'free' earth wire was floating around inside that side of the HB... mainboard is tested ok.). If I can get a (free - i'll pay shipping) sensor board, then I can retire the other hoverboard as a hoverboard, and bolt it to a real robot platform! Any offers?

[p-h-a-i-l]

That will not be a problem, I'll prepare a package for you next week. Should have unused sensor boards lying around. Is there an easy way to test with serial adapter?

[EmerickH]

I also have 6 of them I never used if you want. Did you advance on the new protocol?

[btsimonh]

@p-h-a-i-l - I see no reason why if you sent two, at least one would work :). Must be from a STM base board; I was convinced the GM based boards have a higher baud rate. email me btsimonh at googlemail.com and I'll send my address (what part of the world are you in anyway ? :) ). very poor webcam picture attached, a little different to my other ones, which look like they have placements for both bluetooth and for remote (actually, the original board had a remote receiver plugged into one...):

p.s. if I do flash this STM based hoverboard, does our project cover both STM and the chinese copy chip? I've only used it with the GM (?) based board....

[p-h-a-i-l]

I'm using the code already on STM and GD based boards, haven't really noticed any differences. Looks like yours is connected with wire to wire connectors (JST SM series?). Our chinese friends really like to mix and match :). I've also seen variants where the XH series connector is used with flipped pinning and creative colouring. I'm located in Germany, I'll send you an email with more details. Btw, you can get a sneak preview on my creations when you look closely into this article: https://hackaday.com/2019/01/10/35c3-biggest-communication-congress-yet-little-chaos

[p-h-a-i-l]

is this image mirrored? From the top of my head, I'd say I've only seen this mirrored. Usually one of them has a rf board (433Mhz?) for a simple remote. Never seen one with BT. Only the usual BT speaker on BAT+_SW

[btsimonh]

@p-h-a-i-l "is this image mirrored?" - probably - stupid PC webcam! My GD based YST board set has sites for some kind of surface mount module, which I assumed to be bluetooth audio. The remote I was talking about was actually on the '2 separate motherboard' variety (which I had originally in the first HB, but promptly torched by inadvertently connecting the poweron connector to the CPU - 36v direct to the GD chip did not do it any good!). "sneak preview" :). the shark looks VERY similar to my wooden frame.... P.S. 'newprotocol' updated and now working for simple tests, and selectable between old/new thanks to @EmerickH.

[EmerickH]

@p-h-a-i-l The first board I've got has only a 433Mhz antenna soldered on side board for control and a bluetooth for music but the second one has Bluetooth socket (I have not the option but there's clearly a hc-05 emplacement), for control I think directly soldered on side board (and no 443Mhz)

[EmerickH]

@btsimonh I just tested your NodeRed flow with new protocol but it's not working... I also tried to add move controls but it's not working... Here's my modified flow: https://gist.github.com/EmerickH/ab89db3e47ae0d338a8938eda91f4a0a

[btsimonh]

ok, biggest issue I had was the serial port in linux not being transparent..... Apart from that, i generally press inject on 'stop debug and stop poweroff', then press inject on e.g. 'request hall data' - and see a response.
So haw bad is it not working? if it's failing a lot, but basically working, suspect your linux serial is not raw/transparent....

my stty output: (can't remember EXACTLY how I solved the char translation issue, but stty was involved....) pi@raspberrypi:~ $ stty -F /dev/ttyUSB0 -a speed 9600 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0; -parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts -ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8 -opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke -flusho -extproc

[btsimonh]

Ahh.. just looked at your flow...

the machine protocol does not process ascii commands.... (i.e. 'help', 'set imediate' and 'move' are now use...) so to move, you would send a write param of 'position increment'

'W' (PROTOCOL_CMD_WRITEVAL) 0x05 ('PositionIncr') 0x01 0x00 0x00 0x00 - x increment =1 (by ~6mm) 0x01 0x00 0x00 0x00 - y increment =1 (by ~6mm)

but first, you'd need it in control_type=CONTROL_TYPE_POSITION there is no machine protocol command for that yet :(.

yep, a lot more work to do :).

[EmerickH]

@btsimonh some news: I suspected move commands to have changed but I didn't had time to look at code, thank you for infos. I added:

        case PROTOCOL_CMD_POSITION_CONTROL:
            control_type = CONTROL_TYPE_POSITION;
            break;

And modified NodeRed script I also modified my stty to correspond exactly with yours But it still not working because I have not any character return... I've done some tests:

• With newpid branch and USART2_CONTROLLED, I can control with ascii commands but no return
• With newpid branch and SOFTWARE_SERIAL_A2_A3, I can't control and no return (I tried inverting RX/TX)
• With newprotocol branch and USART2_CONTROLLED or SOFTWARE_SERIAL_A2_A3, I can't control and no return with nodered
• I also tried with an external USB Serial adapter but same thing...
• EDIT: just tried with USART3 and newprotocol, same thing

With the new protocol, if there is not return to RPI, is it blocking control (because of ack/nack securities?)

EDIT2: I tried softwareserial on USART3 pins, for the first time I'm receiving messages in nodered! But they seems to be more connection problems that real messages...

Click to expand message

object
payload: buffer[13]raw
[0 … 9]
0: 0xff
1: 0x0
2: 0x0
3: 0x0
4: 0x0
5: 0x0
6: 0x0
7: 0x0
8: 0x0
9: 0x0
[10 … 12]
10: 0x0
11: 0x0
12: 0xfe
port: "/dev/ttyS0"
_msgid: "38ac1ea2.ebebc2"

[btsimonh]

does the ascii protocol work from a terminal on pi? e.g. can you get a ? response. (I used 'screen' i think as a terminal...)

The NR protocol implementation is basic - e.g. no timeouts. But I don;t think it blocks until ack has been received? not sure - HB not powered up atm.

[EmerickH]

New tests: With newprotocol branch and:

#define INCLUDE_PROTOCOL INCLUDE_PROTOCOL1

• With USART2 I can control with minicom -b 115200 -D /dev/ttyS0
• With softwareserial I can't (but I receive nothing in both cases)

EDIT: I just tried:

  #define USART2_BAUD       9600                  // UART baud rate

But same thing, I can control via screen/minicom but no return

[btsimonh]

strange.
I'm using the GD based board. If you are on an original STM based board, the CPU may have fewer cycles for software serial. I've only tested with software serial @9600, and receive both ascii returns and protocol returns, with very few errors. I have Sensors enabled, and the sensor send and receive is certainly working, (I have lights and HB control), so the USARTS are operational (but look at differences in config when sensors are enabled - the bytes are 9 but for that - so since the IS a difference in hardware config, double check that somehow we've disable the send pin or something stupid based on !SENSOR_CONTROL.). Since you are having issues with all types of serial, double check your voltage levels & earthing, etc. again. If you have a 'scope', earth it to the pi earth, and check the rx data at the pi whilst sending '?' to see if the actual signal is not out of pi voltage range. If you don't have a 'scope, put a meter on the pin - with lots of sends you should get ~1/2 of 3v -> ~1.5v. with a quiet line you should get ~3v (for 232 data is inverted, i.e. high is 'inactive'?). If measuring in AC mode, I guess a busy line may show you 3v ac (lots of '?' sent :) ). You could compare the TX & RX pins at the pi....

[9600]

You called?

[btsimonh]

:) sorry seems I did!!!! see above msg!!! Did not mean to; nice ID...... does it happen a lot?

[btsimonh]

@9600, but seriously; you seem to have the knowledge to to advise @EmerickH on possible 3v serial issues between his hoverboard motherboard and his pi ;) better than me!

[9600]

@btsimonh a reasonable amount. It is difficult being a baud rate.

[EmerickH]

Hello everyone, I just flashed a new hoverboard motherboard and I'm able to communicate fine via serial! I think my old motherboard is damaged... I've not tested to move motors yet but I think it was the problem!