Velcocity Randomly jumps to max when at zero using UART variant

[cohnhead66]

I have hoverboard motors driving a golf push cart controlled remotely with an Arduino Pro Mini 3.3v through UART. I have the mode set to speed. The Arduino sends a command every 40msec over the built in serial port of the Arduino. Randomly, when speed and steer commands are being sent as 0,0, the cart will jump to full speed, and ignores further seral commands from the Arduino for some number of seconds. This happens about once or twice in a 4 hour period and needless to say is quite dangerous.

I have attempted the following with little to no improvement: -- changed serial connection from software serial to hardware serial -- reduced baud rate from 38,400 to 19,200 -- disabled feedback messages, by setting feedback to USART 3

Hope someone has seen this before and knows a solution.

[RoboDurden]

I had such problems months ago and implemented a better crc32 error checking with my own fork. But Emanuel said to have improved his communication by now :-)

Anyway you might want to watch my error demo: https://github.com/EmanuelFeru/hoverboard-firmware-hack-FOC/issues/65#issuecomment-646574377

I too have an arduino mini 3.3V. You might want to use softwareserial to keep the hardware serial for debug output.

I have tons of hf noise on my signal lines. Don't know why :-( But it seems to vary with different hoverboard control boards ! Try pulling the unused adc1 and adc2 to GND. Buy a cheap dso to analyze your hf noise.

[Candas1]

Hi,

FOC firmware is already using a serial frame and a checksum. If by any chance a wrong message still makes it, it's smoothened by the filter, it's visible in your video RoboDurden, it will get a 1000 command but it won't reach full speed. Also if no proper message is received during 0.8 seconds, the board will timeout, beep and go to open mode ( cmd = 0 ).

Cohnhead66 you are saying you commands are ignored for seconds and it stays at full speed ? Is the board beeping when it's happening ?

It's hard to track an error happening twice in 4 hours, do you have a chance to record the data somehow ? Are you sure it's not happening on Arduino side ?

[cohnhead66]

I guess i should have mentioned that I was using an older version of the firmware that I build off the repository about 9-12 months ago.

Last night I rebuilt using the most recent commits. Initially I was getting no motor response, until I did a full erase and went through a calibration routine, which I had never done or had to do with my previous setup. Let it run for a few hours in my shop, with no runaway events. Will have to do further testing to see if the issue comes back. Never thought I needed to calibrate when using UART, but saw a few discussions on this in the issues.

Candas, Yes, commands are ignored for some number of seconds. No lost communication beeps. It either stops on its own, or I power down with the power button if I can catch it.

I can't completely rule out Arduino side, but its just sending 0 speed, 0 steer messages when it occurs. I have no arduino code that changes speed by more than 50 counts at a time to smooth accel and decel. Never happens on the steering command either.

Any suggestions for how to record the data? I assume the Feedback data would be most helpful since it shows command and measured speed. --

[RoboDurden]

With 9-12 months old code you for sure had the unreliable uart protocol that I had trouble with too. But I am confident that Emanuel has resolved that issue by now :-)

[Candas1]

OK Just try with the newer release you might not have problems anymore. If it happens we can investigate more.

The auto-calibration is not mandatory at all, I made it available for all variants because I thought even if you use an arduino, you might want to calibrate your inputs (joysticks, throttle handle, .... ).

But it should work even without calibrating in your case, I need to give it a try again myself to see if something is wrong. Do you mind helping to check what's the issue there ? Have you used any other variant or done auto-calibration before on this board ? As the limits of auto-calibration are stored in memory, it's not erased when you flash the firmware, unless you erase all the memory before. So it could be that the limits of a previous ADC calibration were used for example.

[cohnhead66]

New release appears to have solved the issue. Let the system run for multiple hours in my shop last night without issue. Will test in the field tomorrow to confirm.

Regarding calibration, I confirmed that I get inconsistent control without calibrating. I never had to do this with the older versions.

BTW, my control limits that I send from the Arduino are quite low. -300 to 300 for speed, and -65 to 65 for steer. These are the values that worked well with previous version that were never calibrated. When I calibrated sending these limits, speed seemed to work, but steer did not. 65 counts is probably not enough to trigger the calibration routine.

I created an Arduino script to send commands -1000 to 1000 on both speed and steer and this got the calibration response to match my old revision. Not sure why the defaults didn't just work. I tried both erasing the chip before upload and changing the FLASH_WRITE_KEY, and neither seemed to activate the INPUT min and max from the USART settings.

I have used other variants on the board. ADC and PWM and never did auto calibration before. Have done a full chip erase since then.

Hopes this helps. Happy to help investigate.

To test calibration I

[Candas1]

OK I am surprised it was working with a -65 to 65 value, it's really low. As far as I remember USART was always expecting -1000 to 1000 values, it might have been different before.

So now I understand:

• -65 to 65 is too low with current version of the firmware, so steering wasn't working
• if max - min is less then 200, the input is disabled by auto-calibration

[cohnhead66]

Candas1, remember, because I am not riding my rig, I am using Speed Mode exclusively. This is why the low values work. In torque mode 65 counts probably wouldn't even get my rig moving.

Still would like to know why its requiring calibration to happen at all. I assume after calibrating, the limits being saved are the -1000 to 1000, just like the defaults.

[cohnhead66]

I think we should close this issue out. If needed we can open a new issue regarding calibration of USART in speed mode.

[Candas1]

No worries I still want to make sure it's not a bug. I just flashed USART Variant with Speed mode after having erased the memory.

I am sending -65 or 65 commands for steering and the wheel are spinning. I haven't used the auto-calibration.

Have you changed anything else ? Maybe the steer coefficient ?

[cohnhead66]

Will do some more experiments when I get home tonight.

-65 to 65 is my steer command, Perhaps that acts different then speed command.

maybe my erase process isn't really erasing. I have been using STM32 Cube Programmer to do a full chip erase and flash, Never figured out how to do that in Platformio.

[cohnhead66]

So, I am still having random full speed runaways. I was able to capture debug data of this happening in my shop. I added speed data to the debug output. This is only occurred once over more then an hour, my arduino sending only 0 speed commands.

Here is the section of the data log.

in1:0 in2:0 cmdL:0 cmdR:0 spdL:0 spdR:0 BatADC:1577 BatV:4196 TempADC:1619 Temp:428 in1:0 in2:0 cmdL:0 cmdR:0 spdL:0 spdR:0 BatADC:1577 BatV:4196 TempADC:1619 Temp:428 in1:0 in2:11523 cmdL:416 cmdR:416 spdL:219 spdR:-219 BatADC:1485 BatV:4193 TempADC:1618 Temp:430 in1:0 in2:11523 cmdL:937 cmdR:937 spdL:547 spdR:-541 BatADC:1526 BatV:4185 TempADC:1618 Temp:430 in1:0 in2:11523 cmdL:995 cmdR:995 spdL:568 spdR:-562 BatADC:1563 BatV:4182 TempADC:1618 Temp:430 in1:0 in2:0 cmdL:528 cmdR:528 spdL:554 spdR:-555 BatADC:1613 BatV:4182 TempADC:1618 Temp:430 in1:0 in2:0 cmdL:50 cmdR:50 spdL:188 spdR:-191 BatADC:1603 BatV:4188 TempADC:1618 Temp:430 in1:0 in2:0 cmdL:3 cmdR:3 spdL:42 spdR:-52 BatADC:1577 BatV:4188 TempADC:1618 Temp:430 in1:0 in2:0 cmdL:0 cmdR:0 spdL:17 spdR:-11 BatADC:1577 BatV:4188 TempADC:1618 Temp:430 in1:0 in2:0 cmdL:0 cmdR:0 spdL:0 spdR:0 BatADC:1577 BatV:4188 TempADC:1618 Temp:430 in1:0 in2:0 cmdL:0 cmdR:0 spdL:0 spdR:0 BatADC:1566 BatV:4188 TempADC:1618 Temp:430

you can see input 2 goes from 0 to 11523 for 3 cycles and then returns to 0.

any ideas where this 11523 number is coming from. Maybe I can just put in a filter to ignore any values greater then 1000.

[EFeru]

Not sure why you have that. I guess you are using UART variant from the title. So, i think some wrong value manage to escape the checksum and start frame.. which is strange to me but ok... If you add the filter you suggested i think it should be ok since the values that escape are usually high.

[Candas1]

I need to check if 0XABCD ^ 0 ^ 0 = 0XABCD ^ 0 ^ 11523 but I have doubts.

[cohnhead66]

Where would you suggest I add the filter?

[EFeru]

In readInputRaw()

[cohnhead66]

Do you mean readInput()? Can't find readInputRaw()

[EFeru]

In the latest commit is there in util.c

[cohnhead66]

Closing this issue.

Replaced the Arduino Pro Mini that was communicating with the board with a Addafruit Feather with an MO processor. Since then, i have observed no out of range speed commands. Not sure why there were comm errors with the old board.

Thanks for your help.