You are here

VESC 6 for AUV applications

6 posts / 0 new
Last post
bc
Offline
Last seen: 6 years 1 month ago
Joined: 2018-02-22 12:16
Posts: 2
VESC 6 for AUV applications

Hi to all,

I will just post a few questions that I believe are relevant when using the VESC 6  in AUV thrusters applications:

1. Does the VESC 6 implement an RPM controller? (keeps the same RPM when the battery or the mechanical load changes).

2. How is the reverse/forward rotation implemented? The usual RPM mapping from -100% to 100% would be just fine. 

I quickly browsed throw the src code (so probably I missed something...), and it seems that at least for the RPM PID controller, the reverse/forward option, enters as a compile/boot time parameter (configured using the VESC-Tool, see below).
Do you confirm this? If so, can this be changed? For the typical AUV application, the solution is to send (via serial or CAN bus), a value in the interval [-RPM_MAX, RPM_MAX]. As an example, for a PPM interface, it would look like this:
1.0 ms Full Reverse
1.5 ms Neutral
2.0 ms Full Forward
The change of rotation direction must be dynamic! (I guess that for an RC-truck, should be similar... not so much for a sk8..)

3. Is the VESC 6, compatible with the following Hall sensor:
Allegro A1202 and A1203 Continuous-Time Bipolar Switch Family
http://www.farnell.com/datasheets/2353907.pdf?_ga=2.37538976.1868016791....

4. For AUVs with multiple thrusters (for example, 4), multiple VESC6 are required. To save serial ports in a host CPU, one solution could be to connect one of them via serial port, and "daisy-chain" the four with CAN bus. Is this possible? How would the serial port protocol change to accommodate that? 

Thanks in advance

Best regards

Bruno

 

firmware https://github.com/vedderb/bldc/blob/master/mc_interface.c
LOC 360
void mc_interface_set_pid_speed(float rpm) {
    if (mc_interface_try_input()) {
        return;
    }
    switch (m_conf.motor_type) {
    case MOTOR_TYPE_BLDC:
    case MOTOR_TYPE_DC:
        mcpwm_set_pid_speed(DIR_MULT * rpm);
        break;
    case MOTOR_TYPE_FOC:
        mcpwm_foc_set_pid_speed(DIR_MULT * rpm);
        break;
    default:
        break;
    }
}

LOC 36  https://github.com/vedderb/bldc/blob/master/mc_interface.c
// Macros
#define DIR_MULT        (m_conf.m_invert_direction ? -1.0 : 1.0)

LOC 200 https://github.com/vedderb/bldc/blob/master/main.c
    mc_configuration mcconf;
    conf_general_read_mc_configuration(&mcconf);
    mc_interface_init(&mcconf);

LOC 364  https://github.com/vedderb/bldc/blob/master/conf_general.c
/**
* Read mc_configuration from EEPROM. If this fails, default values will be used.
*
* @param conf
* A pointer to a mc_configuration struct to write the read configuration to.
*/
void conf_general_read_mc_configuration(mc_configuration *conf) {
    bool is_ok = true;
    uint8_t *conf_addr = (uint8_t*)conf;
    uint16_t var;
    for (unsigned int i = 0;i < (sizeof(mc_configuration) / 2);i++) {
        if (EE_ReadVariable(EEPROM_BASE_MCCONF + i, &var) == 0) {
            conf_addr[2 * i] = (var >> 8) & 0xFF;
            conf_addr[2 * i + 1] = var & 0xFF;
        } else {
            is_ok = false;
            break;
        }
    }
    if (!is_ok) {
        conf_general_get_default_mc_configuration(conf);
    }
}

 

arvidb
Offline
Last seen: 4 years 10 months ago
Joined: 2018-01-16 23:09
Posts: 77

1) Yes. It controls RPM using a PID controller which you need to tune to your motor/load combo using VESC Tool.

2) How it's implemented is a pretty broad question, and the only answer is: look at the code. ;) However, it seems like your worry is that the direction can only be set at compile/boot time? No need to worry about that, the RPM is dynamically controllable in both directions. The "m_conf.m_invert_direction" handles situations when you have connected the motor so that it turns backwards when you want it to turn forwards (and vice versa). Setting this variable is equivalent to switching two motor phases.

Note that to control the RPM at low speeds you need a sensored motor.

3) Don't know.

4) This is possible, but I don't know the details of the serial protocol.

bc
Offline
Last seen: 6 years 1 month ago
Joined: 2018-02-22 12:16
Posts: 2

Hi arvidb

Thank you for the reply.

1. ok. I hope it is also possible to send the PID parameters via the "COMM_SET_MCCONF" packet

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

mcconf.s_pid_kp = buffer_get_float32_auto(data, &ind);
mcconf.s_pid_ki = buffer_get_float32_auto(data, &ind);
mcconf.s_pid_kd = buffer_get_float32_auto(data, &ind);

from a host CPU via UART or CAN bus.

2. " How it's implemented is a pretty broad question, and the only answer is: look at the code. " :D my phrasing was vague, but I think you understood for the most part what I was looking for! ;)

I will try to clarify: My question was not if it is possible to solve via the software interface, a wiring mistake (switched motor phases). The question was if the RPM value sent via serial is a sinusoidal wave (sweeping RPM values from -RPM_MAX to RPM_MAX) at a frequency of, for example, 0.2 Hz, will the motor follow that RPM command using the current firmware version?

Yes, for good low RPM control, control with sensors is better.

3. OK, Maybe Benjamin can help.

4. OK, Maybe Benjamin can help.

Cheers

Bruno

TheFallen
Offline
Last seen: 10 months 3 weeks ago
VESC Original
Joined: 2017-09-11 11:46
Posts: 222

Why not just talk to all 4 via CAN?

benjamin
Offline
Last seen: 1 day 21 hours ago
VESC FreeVESC OriginalVESC Platinum
Joined: 2016-12-26 15:20
Posts: 490

Regarding RPM control, BLDC or PMSM motors are always controlled in closed loop, so the VESC knows the position and speed of the motor at all times. The RPM controller uses the known RPM value from the observer and adjusts the current to drive the RPM to the desired value with a PID controller. This is completely independent of the battery voltage, as long as the battery voltage is high enough to overcome the back emf of the motor and produce torque at a given speed.

3. The mentioned hall sensors should work, but I have not tested those particular ones. An AS5047 encoder is also an option, which can be easier to integrate mechanically. First you should try if your application even need sensors as driving propellers sensorlessly works quite well with the VESC.

4. Yes, you can connect 4 VESCs over CAN-bus and control all of them over the UART port from any of them. Everything that can be done from VESC Tool can be done over the UART, including the CAN forward function. You can test it with using an USB-to-UART device and connecting it to the UART of the VESC, then using VESC Tool with that UART - it should work the same as the USB port, but a bit slower. In the protocol, you essentially send the packets as usual, but the the first two bytes of the packets are COMM_FORWARD_CAN followed by the CAN ID to forward to.

I will write a bit about the communication protocol in the documentation pages soon.

arvidb
Offline
Last seen: 4 years 10 months ago
Joined: 2018-01-16 23:09
Posts: 77

"Regarding RPM control, BLDC or PMSM motors are always controlled in closed loop, so the VESC knows the position and speed of the motor at all times."

Well, as long as the speed isn't too low, right? (Since the observer uses back-EMF to calculate the rotor position.)