Tester wanted

[RollingGecko]

Hi,

I merged the updates to bldc fw 3.29 know with new functions and multi serial port support from the pull requests. Interface changed. Know the serial port must be initialized. Know the interface is much cleaner. But I've know hardware to test the changes. Is somebody willing to test it before I merge it to the master?? Changes are in this branch: https://github.com/RollingGecko/VescUartControl/tree/VESC6

[Der6FingerJo]

Hey i'd gladly help you out as your library worked nicely on fw 2.18, unfortunately i don't have a VESC here since i'm not home. But i will contact you once i get there in 2 - 3 weeks! Maybe you could also post something on electric-skateboard.builders, people are always willing to help there!

[RollingGecko]

Would be great! I'm currently also out for 3 weeks. Looking forward for your test. Don't know if the guys on the form really work with this library or only with the ArduBoardControl.

[PaulFl]

I'm willing to help too, I'll try with the new branch Still on 2.18 now just because of your library!

[RollingGecko]

ArduBoardControl was not yet adapted to the changes in the library. Added now SetSerialPort also to ArduBoardControl. Now it should work...I hope.

You will find the changes in this branch: https://github.com/RollingGecko/ArduBoardControler/tree/V6

Chears

Andy

[Jorand]

Hi @RollingGecko, I'm using a VESC 4.12 with fw 3.34 and it seems that VescUartSetNunchukValues ​​does not work. http://vesc-project.com/node/121

[Peemouse]

Hi @RollingGecko, I just tried your VESC 6 version of VESC UART Control library and it works fine with a FW3.28. I used a custom now until now but wanted to give it a try as you changed a lot of things. Thanks a lot and good job for this amazing library !

@Jorand : FW3.34 has a different mc_values structure, so the deserialization is not the same. This library can't work unless you dynamically modify the deserialization by reading first the FW version (but not sure it worth that amount of extra bytes embedded).

Clément

[RollingGecko]

@Peemouse: Thx a lot! Than I will classify the work as 'tested' up to FW 3.28 and merge it to the master. To VescUartSetNunchukValues:

Found the same effect when testing my remote.

Vedder changed in command.c from

case COMM_SET_CHUCK_DATA: ind = 0; chuck_d_tmp.js_x = data[ind++]; chuck_d_tmp.js_y = data[ind++]; chuck_d_tmp.bt_c = buffer_get_bool(data, &ind); ind++; chuck_d_tmp.bt_z = buffer_get_bool(data, &ind);

app_nunchuk_update_output(&chuck_d_tmp);

break;

from my pull request to case COMM_SET_CHUCK_DATA: ind = 0; chuck_d_tmp.js_x = data[ind++]; chuck_d_tmp.js_y = data[ind++]; chuck_d_tmp.bt_c = data[ind++]; chuck_d_tmp.bt_z = data[ind++]; chuck_d_tmp.acc_x = buffer_get_int16(data, &ind); chuck_d_tmp.acc_y = buffer_get_int16(data, &ind); chuck_d_tmp.acc_z = buffer_get_int16(data, &ind); app_nunchuk_update_output(&chuck_d_tmp); break;

But have this implemented that way:

void VescUartSetNunchukValues(remotePackage& data, int num) { int32_t ind = 0; uint8_t payload[11]; payload[ind++] = COMM_SET_CHUCK_DATA; payload[ind++] = data.valXJoy; payload[ind++] = data.valYJoy; buffer_append_bool(payload, data.valLowerButton, &ind); buffer_append_bool(payload, data.valUpperButton, &ind); //Acceleration Data. Not used, Int16 (2 byte) payload[ind++] = 0; payload[ind++] = 0; payload[ind++] = 0; payload[ind++] = 0; payload[ind++] = 0; payload[ind++] = 0;

Anyone an idea?

[Peemouse]

Hi @RollingGecko, I had an issue after having loaded the code in a fresh Arduino Nano using the latest version of VESC6 branch library. Once the instruction come to the function VescUartGetValue() the Arduino reboot... I loaded my custom library (based on your old VESC FW2.xx compatible then tweaked to match FW3.xx comm.) back and the Arduino could pass over this step. If you need me to perform some tests, feel free to ask.

[RollingGecko]

Would also be great if somebody can solve the problems and send a tested pull request. I have not the time to continue the development. Sorry. Can somebody confirm that all provided functions work with the latest VESC firmware?

[Pedrodemio]

For now the only thing i can't get to work is the nunchuck app, i still have to test pulling data from the vesc, from what i saw comparing to the oficial vedder repository we are missing a confirmation byte at the end of the data string

[Der6FingerJo]

I can confirm Pedrodemio's findings. Setting the Current/Brake directly works fine however, just not when you want to use 2 VESCs over CAN. I looked into it and it seems that you would need to send an additional "Send this over CAN too"-byte with the original serial command. Unfortunately i don't have much of a programming background and lack the time to read up on all of this.

But everything else works fine, i'm just using PPM for now so no biggie.

[SolidGeek]

I have tried using VescUartSetNunchukValues() to set the speed and use cruise control, however it doesn't seem to work with a VESC 6. Setting current and getting telemetry works great. Has someone looked into this?

[SolidGeek]

Okay I looked into it, and it seems that Vedder has added the new enum: COMM_SET_HANDBRAKE to the COMM_PACKET_ID typedef. This gives the COMM_SET_CHUCK_DATA a value of 34 in your datatypes.h and a value of 35 in Vedders.

[Teslafly]

testing on teensy 3.2, VescUartGetValue() blocks/hangs when it cannot talk to a vesc immediately. SERIALIO is Serial1. it does not return false like the old version