USART input gets converted to 0

[beustens]

There is a small, but critical bug which results in USART input always getting replaced by 0.

The cmd of input is set to 0, when the typ of input is other than 1 or 2:
https://github.com/EmanuelFeru/hoverboard-firmware-hack-FOC/blob/0709e4cb62ef1d0bfedfc6bc3187614d5862acd6/Src/util.c#L794

Yet, the typ for USART is 3:
https://github.com/EmanuelFeru/hoverboard-firmware-hack-FOC/blob/0709e4cb62ef1d0bfedfc6bc3187614d5862acd6/Inc/config.h#L321

My quick fix was

default: // use raw input
      in->cmd = in->raw;

Btw, I tested the USART via Python, because I had no Arduino laying around. Maybe you are interested in adding the following code as a test script.

import struct # for values to bytes
import serial # to communicate with the hoverboard
from time import sleep # to wait


def command(steer, speed):
	'''
	Creates a bytearray for controlling the hoverboard

	:param steer: -1000...1000
	:param speed: -1000...1000
	:returns: command bytes
	'''
	startBytes = bytes.fromhex('ABCD')[::-1] # lower byte first
	steerBytes = struct.pack('h', steer)
	speedBytes = struct.pack('h', speed)
	# calculate checksum
	checksumBytes = bytes(a^b^c for (a, b, c) in zip(startBytes, steerBytes, speedBytes))

	cmd = startBytes+steerBytes+speedBytes+checksumBytes
	return cmd


uart = serial.Serial('/dev/tty.usbserial-A50285BI', 115200, timeout=1)

# setup test
SPEED_MAX_TEST = 300
iTestMax = SPEED_MAX_TEST
iTest = 0

# ramp speed
while True:
	try:
		speed = SPEED_MAX_TEST-2*abs(iTest)
		cmd = command(0, speed)
		print('\nSending:')
		print(f'speed: {speed}, cmd: {cmd}')
		uart.write(cmd)
		print('Receiving:')
		feedback = uart.read_all()
		#print(feedback)
		if feedback:
			cmd1, cmd2, speedR_meas, speedL_meas, batVoltage, boardTemp, cmdLed = struct.unpack('<hhhhhhH', feedback[2:16])
			print(f'cmd1: {cmd1}, cmd2: {cmd2}, speedR_meas: {speedR_meas}, speedL_meas: {speedL_meas}, batVoltage: {batVoltage}, boardTemp: {boardTemp}, cmdLed: {cmdLed}')

		# calculate next test speed
		iTest += 10
		if (iTest > iTestMax):
			iTest = -iTestMax
		
		sleep(0.1)
	except KeyboardInterrupt:
		break

uart.close()

[Candas1]

Hi,

It's not a bug. This type is initialized somewhere else.
This type can be zero if you do auto-calibration by mistake or if you do it wrongly:
https://github.com/EmanuelFeru/hoverboard-firmware-hack-FOC/wiki/Input-Calibration

Wow the python code is so simple. It's definitely useful for others.

[beustens]

Hi,

this poti/calibration stuff applies to ADC control variant, right? I was talking about USART control variant as defined in config.h. There, the typ is 3. Maybe I missed some getting started section, but the only way I could got the USART variant running, was by fixing the line above in util.c. Or should the typ for USART be 2 in the first place?

[Candas1]

Calibration can run for any variant, and is saved to eeprom so it's conserved even if you flash.
Erase the chip fully in st-link utility and flash again. Code should work without any change.

[beustens]

Okay, so if I leave the typ to 3, I would need to press the button for 5 sec and then send -1000 and 1000 via USART in order to get this variant running? In the Wiki is stated that no calibration is needed for USART. Also, as values are deterministic, I would say no calibration should be necessary.

[Candas1]

No if you leave type as 3, it will determine the type based on min, mid and max values from config.h, so type will become 2 (mid-resting pot).You don't have to run the auto-calibration procedure.

I still think you ran it by mistake/without knowing, and type was set to 0 for both inputs. Erasing and flashing will get you back to normal.

[vamfun]

"The cmd of input is set to 0, when the typ of input is other than 1 or 2:"

I've encountered this when unknowingly entering autocal. I would recommend printing an error message if you ever get to "other than 1 or 2" condition in the input calculation.

[beustens]

I see, the input type gets re-defined in checkInputType in util.c.

I've encountered this when unknowingly entering autocal.

This could be true in my case too. I pressed the button long to make sure the power latch is not released when flashing.