PYVESC UART Issues

In the VESC6 firmware the read response seem to have changed, in case the question is related to that. 

see https://github.com/vedderb/bldc/blob/master/commands.c

	case COMM_GET_VALUES:
		ind = 0;
		send_buffer[ind++] = COMM_GET_VALUES;
		buffer_append_float16(send_buffer, mc_interface_temp_fet_filtered(), 1e1, &ind);
		buffer_append_float16(send_buffer, mc_interface_temp_motor_filtered(), 1e1, &ind);
		buffer_append_float32(send_buffer, mc_interface_read_reset_avg_motor_current(), 1e2, &ind);
		buffer_append_float32(send_buffer, mc_interface_read_reset_avg_input_current(), 1e2, &ind);
		buffer_append_float32(send_buffer, mc_interface_read_reset_avg_id(), 1e2, &ind);
		buffer_append_float32(send_buffer, mc_interface_read_reset_avg_iq(), 1e2, &ind);
		buffer_append_float16(send_buffer, mc_interface_get_duty_cycle_now(), 1e3, &ind);
		buffer_append_float32(send_buffer, mc_interface_get_rpm(), 1e0, &ind);
		buffer_append_float16(send_buffer, GET_INPUT_VOLTAGE(), 1e1, &ind);
		buffer_append_float32(send_buffer, mc_interface_get_amp_hours(false), 1e4, &ind);
		buffer_append_float32(send_buffer, mc_interface_get_amp_hours_charged(false), 1e4, &ind);
		buffer_append_float32(send_buffer, mc_interface_get_watt_hours(false), 1e4, &ind);
		buffer_append_float32(send_buffer, mc_interface_get_watt_hours_charged(false), 1e4, &ind);
		buffer_append_int32(send_buffer, mc_interface_get_tachometer_value(false), &ind);
		buffer_append_int32(send_buffer, mc_interface_get_tachometer_abs_value(false), &ind);
		send_buffer[ind++] = mc_interface_get_fault();
		commands_send_packet(send_buffer, ind);
		break;

This is from my source code. You have the packet structure and above buffer_append_.... fill the payload.

Note: As any network code it is MSB-first.

To get the actual decimal value you have to divide by the factor, e.g. v_in_10 might have the int16_t value of 113, divided by 10 returns the correct 11.3Volt.

That is how far I got. It is working though.

// VESC Types
// Example Packet:
// 02 3a 04 01 1a 00 f3 00 00 01 ba 00 00 00 66 00 00 00 00 ff ff fe 46 fe f8 ff ff e0 2c 00 71 00 00 00 2e 00 00 00 00 00 00 02 12 00 00 00 00 ff ff e0 bb 00 00 3c 2f 00 09 69 58 d0 cc 6f 03

// 02: Packet Start Byte
// 3a: 58 bytes of payload starting with the next byte '04'
// 04: The command COMM_GET_VALUES
// payload mapping to the structure below
// cc6f: The 2 byte CRC
// 03: Packet End Byte

struct getvalues_s {
    int16_t         temp_fet_10;                // 0x011a
	int16_t         temp_motor_10;              // 0x00f3
	int32_t         avg_motor_current_100;      // 0x000001ba (7-10)
	int32_t         avg_input_current_100;      // 0x00000066 (11-14)
    int32_t         avg_id_100;                 // 0x00000000 (15-18)
    int32_t         avg_iq_100;                 // 0xfffffe46 (19-22)
    int16_t         duty_now_1000;              // 0xfef8
    int32_t         rpm_1;                      // 0xffffe02c (25-28)
	int16_t         v_in_10;                    // 0x0071
    int32_t         amp_hours_10000;            // 0x0000002e (31-34)
    int32_t         amp_hours_charged_10000;    // 0x00000000 (35-38)
    int32_t         watt_hours_10000;           // 0x00000212 (39-42)
    int32_t         watt_hours_charged_10000;   // 0x00000000 (43-46)
    int32_t         tachometer;                 // 0xffffe0bb (47-50)
    int32_t         tachometer_abs;             // 0x00003c2f (51-54)
    int8_t          fault_code;                 // 00
    int32_t         unknown;                    // 0x096958d0 purpose unknown
} __attribute__ ((__packed__));

https://github.com/wernerdaehn/CC3D-CableCam-Controller/blob/master/inc/...

https://github.com/wernerdaehn/CC3D-CableCam-Controller/blob/master/src/...

@whdaehn  In that list of bytes your sending the first 01 1a after com_get_values' 04 is that for getting the temp_fet value to be sent back from the vesc? So include the corresponding byte in the payload from that struct you have there to get a desired value back? or will a raw data set automatically be sent back if just 04 is sent as the payload? I'm having trouble getting a response from the VESC and this it may be an incorrect request on my part. Your detailed source code is sort of clearing things up.

Thanks

The com_get_values command requests all values. You cannot tell which parts to return, it returns the full data. Hence I load that into that struct and then I pick the variable I want.

You got the point that above example lists the response only, not what I am sending.

Does that answer it?

Yes, that was my interpretation of how it works. I am sending 02 01 04 40 84 03 but am not getting anything back form the VESC when checking my receive buffer. Any thoughts?

Looks good, checksum I can't tell. The only idea I have is big endian/little endian. Can you send 02 01 04 84 40 03  (CRC bytes swapped) for a test? The VESC does not respond if anything is wrong, hence we don't know what it is. Could also be hardware, TX versus RX, VESC configuration (Uart activated??)...

UPDATE: The packet I am sending was correct and I receive a similar 58 byte packet back to what ou posted above. My receive buffer was/is not triggering correctly but from the VESC end it is transmitting perfectly. I have an arduino piggy backing on the tx so I can see the output and the problem is rx on my nxp board. Thanks for the guidance.

Hey @whdaehn, another follow up question regarding the UART.

The packets that are Tx from the VESC end with a 3, but do they contain a \0 \r or \n after that? I cannot pick up either and can only catch the com values correctly when hardcoding my buffer to stop at 63 bytes (58 payload plus the 5 info bytes), this does work fine but the same would have to be done with each other get command individually.

Can it be confirmed there are no interrupting chars sent after the stop byte, or am I just missing them somehow?

Also I'm looking to use the set_rpm command for control of my motor, I should be able to set 12000 rpm for example and if correctly tuned the vesc should vary its amperage to hold that value correct?

Thanks

This is all binary communication. So no \r \n or \0 chars are being sent. (At least I am not aware of and I have not noticed any.)

My logic is primarily timing driven:

1. If the byte received in the interrupt has a time gap of  >500ms since the last byte was received, this is a new packet. Reset the buffer position to zero.
2. Decode the packet based on its position. So start byte has to be first, when the length byte is read set the high watermark, when the high water mark is reached check if that is the end byte.
3. If all true, copy the buffer into the structure so it can be read more easily and the buffer is free to receive the next bytes.
4. If not, throw away the data.

The point is, the VESC never sends any data unless you request it by sending a command. So as long as you are not sending commands faster than 500ms, above works. And many commands like the set_rpm do not return anything even.

Above logic should cope with all issues like an accidental correct byte due to noise, data loss and the such.

Regarding your second point., yes, I control the VESC with rpm commands as well (with the exception of rpm=0, which I translate into brake_current and handbrake commands for now. Still testing though.). There is an enhancement request to let the VESC handle rpm=0 as well, so it should do everything that is needed to stop and stay at speed=0. Would appreciate if you would support this request by raising your voice there. http://vesc-project.com/node/146

Hello, 

I tried to get all the data from VESC 6.0 too. I am getting no good data at all. However I can set RPM and duty cycles. 

Can you please tell me what should I change in PyVESC files? 

Thanks 

Thanks for the information wdaehn. I updated pyvesc/messages/getters.py and now the GetValues message appears to be working. I don't use all the other messages though, so they may still need tweaking.

To update pyvesc, in getters.py in the GetValues class, change "fields" to the following:

    fields = [
            ('temp_fet', 'h', 10),
            ('temp_motor', 'h', 10),
            ('current_motor', 'i', 100),
            ('current_in', 'i', 100),
            ('avg_id', 'i', 100),
            ('avg_iq', 'i', 100),
            ('duty_now', 'h', 1000),
            ('rpm', 'i', 1),
            ('v_in', 'h', 10),
            ('amp_hours', 'i', 10000),
            ('amp_hours_charged', 'i', 10000),
            ('watt_hours', 'i', 10000),
            ('watt_hours_charged', 'i', 10000),
            ('tachometer', 'i', 1),
            ('tachometer_abs', 'i', 1),
            ('mc_fault_code', 'c'),
            ('unknown', 'i', 1)            
    ]

PS, i've been using these new values on Firmware 3.4, and it's been working well for me too. Should get updated in the github repo.