search

btsimonh / hoverboard-firmware-hack

New Hoverboard Firmware Hack. Now written from scratch and generally much better.
GNU General Public License v3.0
22 stars 4 forks source link

Pid control / UART fixes #2

Closed EmerickH closed 5 years ago

EmerickH commented 5 years ago

TO-DO:

Original message:

I've added some little fixes to @p-h-a-i-l cleanup to make it compile correctly with make on my computer but I can't get it working for control: with Minicom I can receive debug informations but when I send a character, I don't get any response... Any idea?

My goal is to use position control

Thank you
btsimonh commented 5 years ago

looks like it's going into the right direction :). I've not much time for this at the moment, but just ping me when you think you have a version here which is worth merging. Ref sending chars, make sure you hit return!. If no banana, check through the software serial code; raising the priority of the interrupt may help, or doubling the sample frequency (if CPU has capacity). I get a few miss-reads when sending. If you are not using the sensors, then please adapt the code to work with the native uarts (best in interrupt mode; DMA really add nothing or a character based/variable message size interface like this). I know a number of people want to use the native uarts... but I have no interest in them myself as they are in use :(. p.s. when using position control, watch out for hitting objects but it still wanting to move further! It seems it can get quite angry if you don't let it achieve it's position.... It also needs a different drive mode for slow speed/ fine position. Something which sends the correct static PWM values to the motors to hold them at a location between two hall points; possibly current sensing to know if it's close to where the demand is? see this link for inspiration...

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

I did get the "machine" protocol running (not reeaaaally tested though) now too, basically it's missing the timout reset and control mode selection. Need to clean up my changes and will commit later™. As a quick hack to use the existing wiring, I just defined the usart pins for the software serial interface.. dirty but functional. Would be nice to utilize the hw uart, but not a priority for now.

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

(just noticed, that I already pushed my experimental state to github :). So command 0x03 (speed data variable) should be working..)

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

which contol method did you try? The human Interface should be ok does iw <enter> wwwwwwwwwwwwww move the wheels?

EmerickH commented 5 years ago

@p-h-a-i-l

I just defined the usart pins for the software serial interface..

I did the same thing but I can't get RX working... (no response and not moving)

which contol method did you try? The human Interface should be ok does iw < enter > wwwwwwwwwwwwww move the wheels?

Not working... I don't really know how serial works, so I can't change to native uart...

I saw you inverted RX and TX, is it normal?

@btsimonh

raising the priority of the interrupt may help

Line 121 HAL_NVIC_SetPriority(EXTI2_IRQn, 0, 0); isn't the highest priority?

doubling the sample frequency (if CPU has capacity)

How do you do?

EDIT: I tested from a PC with an Serial USB adapter, also not working...

btsimonh commented 5 years ago

@EmerickH - priority - ahh... maybe; docs not to hand. In that case lowering all the other priorities! I think I set them all the same.... sampling freq: you'd have to understand the softwareserial file... halve the timer, and halve some calculation in the rx interrupt routine? but I think 'cos it seems to work well sometimes, the priority is the place to start; basically, the interrupt routine is fairly short compared to the other interrupt routines going on, and is VERY regular. So making it top priority should not affect other things too much, but should make the serial work much better (by reducing timing jitter when the interrupt goes off to poll the RX line). I guess the next thing to do is instrument the RX routine to see if you EVER get notification of a change of the RX line state (since you can send debug!). Maybe the pin is still not configured right, or the edge detection is not working?

EmerickH commented 5 years ago

I made some changes to use simple UART (for debug only now), not tested yet because I don't have the robot but maybe working

EmerickH commented 5 years ago

New changes for RX, I think it's not working because too long: https://github.com/btsimonh/hoverboard-firmware-hack/pull/2/commits/aca9fa75609782be248100034ff385cbffd0fa55#diff-4d56b20caf039f2e5b395d378e4d2368R433 And 1 byte buffer is not very good I think... We need to make a receiver buffer like softwareserial.c instead of DMA receive but I'm not expert in interrupts...

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

@EmerickH

I saw you inverted RX and TX, is it normal?

Just did it so I can plug in my USB to serial adapter directly to the JST connector. No technical reason.

btsimonh commented 5 years ago

the interrupt driven RX should not be difficult to implement; there must be some STM32 samples somewhere...

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

@EmerickH I made some Tests yesterday, I can confirm your Problems with the Softwareserial RX. I can only receive SpeedData commands every now and then. In 99% of times I get a NACK. I think for the "human" Interface with very short Messages this is not an Issue, but the SpeedData command is around 61 Bytes long. Didn't have time to test you new code unfortunately, but I look forward to your improvements.

btsimonh commented 5 years ago

@p-h-a-i-l - what are you sending the 'machine protocol' from? I've not done an implementation yet, so if you have a 'pattern' project o the go, it may help all of us. I can''t see me being able to get back on this in the short term, but if I had a really easy way of programatically testing the coms, maybe I could take a quick look at the software serial implementation?

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

ESP32, I can push that project to Github. My "implementation" is a 98% reuse of your protocol sources, didn't want to reinvent the wheel :)

btsimonh commented 5 years ago

brill; got my two ESP32 on friday!. However, will likely re-code to JS.
p.s. what you driving the ESP with?
p.p.s. A bit of an aside, but my favourite ESP8266 project is sonoff tasmota (for a variety of reasons). Just compiled the ESP32 port, see my platformio test branch. Note, it's not yet 'tasmota' functional, but handles things like setting wifi from UI, and MQTT; I love the fact tasmota HAS a web UI and configuration, and have used it as a basis for 'non sonoff' projects just because I don't have to do a lot for myself.

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

So you're planning to have JS on your raspi? What do you mean by driving? My Input Method or the framework? As for the Input Methods I implemented the Nunchuck (Joystick & Acceleration), separate Acceleration Sensor and Platooning with Gametrak. The goal is to have a wireless connection between the controller and Motor control board. For now I'm using ESPnow which is very simple to use but I'm als experimenting with 433Mhz RF Modules, BLE, BT and Wifi. I need more time though :) Framework is based on Arduino but digging deeper to ESP-IDF and FreeRTos functions here and there.

btsimonh commented 5 years ago

interesting. keep me informed on your BLE efforts; I'm doing a LOT of work on BLE at the moment - my ESP32s were bought to make a BLE to MQTT gateway to get over BLE range issues. For me, JS = Node-Red. I did some work on Wiimote (using 'input' in linux) for control of the hoverboard; a little unreliable so far!

btsimonh commented 5 years ago

ok, updated 'pidcontrol' branch with lowering of interrupt priority for everything (almost everything) except software serial. e.g. when I held down 'f', sometimes got a square in return. now better. (but notice original firmware returned '#' when ascii buffer was full).

btsimonh commented 5 years ago

Added one more commit to respond to test message 'T' by reflecting the message as 't'. now running long term test :).

btsimonh commented 5 years ago

One more push - fixed a bug in software serial which meant that the last character was ignored!!!! Still one or two NACKs when pushing heavily (127 byte messages, every 100ms), but much better. Note that the TX MUST be enabled to have the timeout work...

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

I had some time yesterday to test your lates changes @btsimonh . Major improvement, almost no more NACKs.

As long as I don't run the motors :) When I startup the wheels, almost no messages go through anymore. (Subjective I think it might not be an EMI problem, because there were never any checksum errors on the NACK Messages. So Interrupts? Hopefully I'll find some time to play around with @EmerickH s HW UART code.

btsimonh commented 5 years ago

hmm... maybe the interrupt priorities were the wrong way around; but google indicated I did it right? I have to admit I did not run the wheels!..... Check the RX pin you are using are not somehow being interfered with by the motor code?

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

tried PB10/USART3_TX Pin29 and PA2/USART2_TX/ADC123_IN2 Pin16, since they are the usual UART Pins it shouldn't be a problem

btsimonh commented 5 years ago

hi @EmerickH - some of these will have been overtaken with the other pull request? could you have a quick review and drop the changes you'd like (heartbeat sounds good, but must be able to enable/configure it via the protocol rather than build option) on top of the current branch and issue a new pull req?

EmerickH commented 5 years ago

This code is outdated, I close the pull