Communicating with the VESC using UART


Posted on October 9, 2015

Many people have asked me how to communicate with the VESC using UART, but I did not have a good answer since I haven’t written any tutorial about that and the only thing I could refer to was the BLDC Tool code. Now I have created a project for the STM32F4 discovery board that implements UART communication with the VESC where the full interface is implemented. In this post I will try to explain how the code works and how to port it to other platforms.

많은 사람들은 제게 UART를 이용해서 VESC와 어떻게 통신하는지 물어왔습니다. 그러나 저는 그것에 대해서 어떤 가이드를 작성하지 않았기 때문에 좋은 답장을 갖고 있진 않습니다. 제가 참조할 수 있는 유일한 것은 BLDC Tool의 코드입니다. 저는 완전한 인터페이스가 구현된 VESC와 UART 통신을 구현한 STM32F4 discovery 보드에 대한 프로젝트를 만들었습니다. 이 글에서 저는 어떻게 코드가 동작하고 다른 플랫폼으로 어떻게 포팅하는지를 설명할 것입니다.


Getting started

Start by downloading the code from github: 

https://github.com/vedderb/bldc_uart_comm_stm32f4_discovery



If you have a stm32f4 discovery board, you can upload the code to it and test it by following the tutorial in my VESC Post for installing the toolchain. After that, just connect both USB ports of the discovery board (one for the built in programmer and one for the serial terminal) and type make upload from the project directory. Don’t forget to connect rx (PB11), tx (PB10) and gnd from the discovery board to tx, rx and gnd on the VESC. The discovery board will show up as a USB-serial port and you can use a serial terminal such as screen or gtkterm to access a simple command line interface on it. Only a few commands are implemented for the command line interface (type help to list them), but a good exercise is to write more commands in the main file using the provided interface. Doing that with the bldc_interface code should be quite straight forward.

여러분이 stm32f4 discovery 보드를 갖고 계시다면, 여러분은 코드를 업로드 할 수 있고 toolchain을 설치하기 위해서 제 VESC 글에 가이드에 따라 테스트 할 수 있습니다. 그 후에 discovery 보드의 양 USB 포트를 연결하세요(프로그래머에 설치된 하나와 시리얼 터미널에 하나) 그리고 프로젝트 디렉토리로부터 make upload를 치시기 바랍니다. discovery 보드의 rx (PB11), tx (PB10) 그리고 gnd를 VESC의 tx, rx 그리고 gnd를 연결하는 것을 잊지 마십시오. discovery 보드는 USB-serial 포트로 나타나고 여러분은 간단한 command line 인터페이스를 접근하기 위해서 screen 혹은 gtkterm과 같은 시리얼 터미널을 이용할 수 있습니다. command line 인터페이스를 위해서 오직 몇 개의 명령에 대해서 구현되어졌습니다(리스트하기 위해서 help를 치세요), 그러나 좋은 연습은 제공된 인터페이스를 이용해서 메인 파일에 좀더의 명령어를 작성할 수 있습니다. bldc_interface 코드와 그것을 하는 것은 매우 직관적(straight forward)입니다.


Understanding the implementation

The VESC communicates over UART using packets with the following format:

VESC는 다음의 포맷을 갖는 패킷을 사용하여 UART로 통신합니다:


    • One Start byte (value 2 for short packets and 3 for long packets)

    • One or two bytes specifying the packet length

    • The payload of the packet

    • Two bytes with a CRC checksum on the payload

    • One stop byte (value 3)


The higher level of the VESC communication code is the same for the USB, UART and CAN ports, so everything that can be done from BLDC Tool can be done from the other ports as well. Therefore I have abstracted out the higher layer of the communication into separate files so that it can be reused for CAN-bus and USB without modifying the rest of the code later.

VESC 통신 코드의 상위 레벨은 USB, UART 그리고 CAN 포트에 대해서도 동일합니다. 그래서 BLDC Tool로부터 할 수 있었던 것은 모두 다른 포트들에서도 할 수 있습니다. 그러므로 저는 통신의 상위 레이어를 분리된 파일들로 구체화 하였습니다. 그 결과 이것은 CAN 버스와 USB에 대해서 나중에 코드의 나머지 수정 없이 다시 사용할 수 있습니다.


The important files in the project, which you can use for your implementation, are the following. They are plain C files and don’t have any hardware dependencies.

여러분이 여러분의 구현을 위해서 사용할 수 있는 프로젝트에서 중요한 파일들은 다음과 같습니다. 일반 C 파일이며 어떤 하드웨어 의존성을 갖지 않습니다.


bldc_interface.c and bldc_interface.h


These files can assemble the payload for all the commands that the VESC supports. They can also interpret packets from the VESC and extract the data from them. Notice that only the payload is handled in these files, not the start, stop, length and checksum bytes since these are different for the CAN interface.

이들 파일은 VESC가 지원하는 모든 명령들의 페이로드(payload)를 조립할 수 있습니다. 이들 파일은 또한 VESC로부터 패킷을 번역하고 그들로부터 데이터를 추출할 수 있습니다. 이들은 CAN 인터페이스에서 다르기 때문에 start, stop, length 그리고 checksum bytes가 아닌 오직 페이로드만이 이들 파일에서 다룰 수 있다는 것을 기억하세요. 


datatypes.h


The data structures used by the VESC.

VESC에서 사용된 데이터 구조입니다.


buffer.c and buffer.h


Helper functions for for going between C types and byte arrays. These are used by the bldc_interface files.

C 타입 그리고 byte 배열사이에 Helper 기능들. 이들은 bldc_interface 파일에서 사용됩니다.

crc.c and crc.h


For calculating the CRC checksum

CRC checksum을 계산하기 위함


packet.c and packet.h


For assembling the packets for the VESC with start, stop, length and checksum bytes. These files also have a state machine where one byte received from the VESC can be added at a time to assemble a packet and check the checksum correctness.

start, stop, length 그리고 checksum bytes와 함께 VESC를 위한 패킷의 조립을 위함. 이들 파일은 또한 VESC로부터 수신된 한 바이트가 패킷을 조립하기 위해서 한번에 추가되고 checksum이 올바른지 체크할 수 있도록 하는 state machine을 갖습니다.


bldc_interface_uart.c and bldc_interface_uart.h


Connects packet and bldc_interface to provide a clean UART interface. This is where the user has to make the connection to the UART interface for the platform of choice.

깨끗한 UART 인터페이스 제공하기 위해서 패킷과 bldc_interface을 연결합니다. 이는 사용자가 선택한 플랫폼의 UART 인터페이스로 연결해야 하는 곳입니다.


All of these files rely heavily on function pointers. This might sound complicated at first, but it is actually quite convenient and easy to use. The connection between these files and the UART port is done in the file comm_uart.c, which is the file that you have to implement if you want to port this to a different platform. Also, if you decide to use some other port than UART such as CAN or USB, you only have to re-implement this file and the higher level implementation will work as before.

이들 파일 모두는 함수 포인터에 강하게 의존합니다. 이는 처음에 복잡하게 들려질 수 있습니다, 그러나 이는 실제로 매우 편리하고 사용이 용이합니다. 이들 파일과 UART 포트의 연결은 comm_uart.c 파일에서 이루어집니다. 이 파일은 여러분이 이를 다른 플랫폼으로 포트하기를 원한다면 구현해야만 하는 파일입니다. 또한 여러분이 UART보다 CAN 혹은 USB와 같은 다른 포트를 사용하기로 했다면 여러분은 단지 이 파일을 다시 구현해야 합니다. 그리고 상위 레벨 구현은 전과 같이 동작할 것입니다.


Making the platform-specific UART connection

This should be rather straight forward. The bldc_interface_uart files have three functions that have to be used:

이것은 오히려 직관적일 수 있습니다. bldc_interface_uart 파일은 3가지 함수를 갖습니다:


bldc_interface_uart_init


This is the init function that takes a function pointer to a function that you provide for sending data on the UART. You can use it something like this:

이것은 UART 상에 데이터를 보내기 위해 여러분 제공한 함수로 함수 포인터를 옮겨 놓는 함수의 초기화 함수입니다. 여러분은 이를 다음과 같이 사용할 수 있습니다:


/**

 * A function that will send the bytes in *data with length len on the UART

 */

static void send_packet(unsigned char *data, unsigned int len) {

// Your implementation

}

 

// Your init function

void comm_uart_init(void) {

// Initialize your UART...

 

// Initialize the bldc interface and provide your send function

bldc_interface_uart_init(send_packet);

}


bldc_interface_uart_process_byte


Call this function every time a byte is received on the UART with the received byte. It will run the state machine in the packet assembler and the callbacks in bldc interface will be called when the packets are ready.

UART 상에 한 바이트가 도착할 때마다 이 함수를 호출합니다. 이는 packet assembler에서 state machine을 동작시키고 bldc 인터페이스에서 callback은 패킷이 준비되었을 때 호출될 것입니다.


bldc_interface_uart_run_timer


Call this function every millisecond to reset the packet state machine after a timeout in case data is lost.

데이터를 잃어버린 경우에 대해서 timeout 후에 packet state machine을 리셋하기 위해서 매 ms 마다 이 함수를 호출합니다.


Notice that bldc_interface_uart_process_byte and bldc_interface_uart_run_timer can be omitted it you only plan to send data to the VESC and not read anything.

bldc_interface_uart_process_byte와 bldc_interface_uart_run_timer는 여러분이 VESC에 데이터를 보내고 어떠한 것도 읽지 않을 계획이라면 생략될 수 있습니다.

 

In this example project this is implemented in comm_uart.c. This implementation is a bit more complicated than necessary because it uses threads to run the data processing to not block the UART while running the callbacks and to not run the callbacks from an interrupt scope, but a much simpler implementation can also be done if you don’t have an RTOS. You could call bldc_interface_uart_process_byte directly from an interrupt handler every time you receive a byte.

이 예제 프로젝트에서 이것은 comm_uart.c에서 구현되어졌습니다. 이들 구현은 필요보다 다소 복잡합니다. 왜냐하면 이는 callback이 작동하는 동안 UART를 막지 많고 데이터 프로세싱을 위한 그리고 interrupt scope로부터 callback이 작동하는 것을 막기 위해서 스레드를 사용하기 때문입니다. 그러나 여러분이 RTOS를 갖고 있지 않다면 또한 훨씬 간단하게 구현될 수 있습니다. 여러분은 여러분이 한 바이트를 수신한 때마다 interrupt handler로부터 곧바로 bldc_interface_uart_process_byte를 호출할 수 있습니다.


Using bldc_interface

After you are done with the hardware specific UART implementation, you can use bldc_interface in your application. To set the current, duty cycle etc. just call the corresponding function from the setters e.g.

여러분이 하드웨어에 요구되는 UART 구현을 완료한 후에 여러분은 여러분의 애플리케이션에서 bldc_interface를 사용할 수 있습니다. 예를 들어, 전류와 듀티 싸이클 등을 설정하기 위해서 설정기(setters)로부터 관련함수를 호출합니다.


// Run the motor in current control mode with 10A commanded current

bldc_interface_set_current(10.0);


You can do everything that BLDC Tool can do, including changing the configuration (you should read the old configuration before updating it though). Notice that you have to call these functions at regular intervals to not trigger the timeout in the VESC that will release the motor if no new commands have been received for longer than the configured time for safety reasons. This can be done either by calling the corresponding setters at regular intervals or by calling the bldc_interface_send_alive function.

여러분은 BLDC Tool이 할 수 있는 모든 것을 할 수 있습니다, 설정을 변경(하지만 업데이트 전에 이전 설정을 읽어야만 합니다)하는 것을 포함해서 말입니다. 여러분은 VESC에서 timeout이 작동하지 않기 위해서 정기적인 간격으로 이들 함수를 호출해야 함을 기억하세요! VESC는 안전의 이유로 설정된 시간보다 긴 시간 동안 어떠한 새로운 명령을 수신할 수 없다면, 모터를 통제권을 내려놓습니다. 이는 정기적인 간격으로 관련 설정기를 호출하거나 bldc_interface_send_alive 함수를 호출하는 것에 의해서 해결될 수 있습니다.


Reading data

Reading data is done with getter functions and callback function pointers. For example, to get realtime data from the VESC, first set a callback to your function for handling the data using bldc_interface_set_rx_value_func and then request the data with bldc_interface_get_values. It can look something like this:

데이터를 읽는 것은 getter 함수와 callback 함수 포인터들과 함께 이루어집니다. 예를 들어, VESC로부터 실시간 데이터를 얻기 위해서 우선 bldc_interface_set_rx_value_func 함수를 사용해서 데이터를 핸들링 하기 위해서 여러분의 함수로 callback을 설정하세요 그리고 나서 bldc_interface_get_values 함수로 데이터를 요청합니다. 이는 다음과 같이 보여집니다:


// Your callback function for the received data. In this case you simply

// print it using printf.

void bldc_val_received(mc_values *val) {

printf("Input voltage: %.2f V\r\n", val->v_in);

printf("Temp:          %.2f degC\r\n", val->temp_pcb);

printf("Current motor: %.2f A\r\n", val->current_motor);

printf("Current in:    %.2f A\r\n", val->current_in);

printf("RPM:           %.1f RPM\r\n", val->rpm);

printf("Duty cycle:    %.1f %%\r\n", val->duty_now * 100.0);

printf("Ah Drawn:      %.4f Ah\r\n", val->amp_hours);

printf("Ah Regen:      %.4f Ah\r\n", val->amp_hours_charged);

printf("Wh Drawn:      %.4f Wh\r\n", val->watt_hours);

printf("Wh Regen:      %.4f Wh\r\n", val->watt_hours_charged);

printf("Tacho:         %i counts\r\n", val->tachometer);

printf("Tacho ABS:     %i counts\r\n", val->tachometer_abs);

printf("Fault Code:    %s\r\n", bldc_interface_fault_to_string(val->fault_code));

}


// Somewhere in your init code you can set your callback function(s).

bldc_interface_set_rx_value_func(bldc_val_received);


// Every time you want to read the realtime data you call the corresponding getter.

// This will send the get command to the VESC and return. When the data is received

// the callback will be called from the UART interface.

bldc_interface_get_values();


Have a look at main.c to see some examples of this.

예제를 보기 위해서 main.c를 보세요


That’s it! I hope this is enough to get started with UART communication to the VESC.

VESC로의 UART 통신을 시작하기에 충분하기를 희망합니다.



Posted by Nature & Life


CAN(Controller Area Network) 프로토콜은 Bosch사에서 1986년 자동차 전장 용으로 처음 개발되었으며 1991년에 스펙 2.0이 발표되었고 현재 국제 표준 프로토콜로 성장하였습니다. 이는 호스트 컴퓨터 없이 3개 이상의 MCU나 controller, 장치들이 서로 다중 통신이 가능하며, 메시지는 우선순위 따라 ID(Identifier)를 할당하고 이 ID를 이용해 메시지를 구별합니다. 다양한 에러 감지 메커니즘이 상호 보완적으로 에러를 감지하기 때문에 높은 안정성을 보장하며, 메시지 전송 시 에러가 감지되면 자동적으로 해당 메시지를 즉시 재전송하는 기능이 있기 때문에 다른 프로토콜에 비해서 에러 회복 시간이 짧다는 것입니다.


차량에 적용하는 CAN 통신의 예제


버스가 유휴 상태인 경우 모든 CAN 노드는 메시지를 보낼 수 있고, 전송된 모든 메시지는 모든 노드에서 수신됩니다. 수신 노드는 ID 필터링 기준에 따라 메시지의 무시 여부를 판단합니다. 정교한 오류 감지 및 결함 격리 메커니즘과 문제가 발생한 메시지의 재전송으로 데이터 무결성과 일관성이 보장합니다. 또한 두 개 이상의 CAN 노드가 동시에 메시지 전송을 요청하는 경우 우선순위가 가장 높은 메시지가 즉시 버스 액세스 권한을 획득하도록 프로토콜이 보장합니다. 현재는 CAN의 안정성과 신뢰성 등 장점이 입증되어 항공기, 의료기 등에 사용되고 IoT application에서도 사용되는 추세입니다.


가장 쉽고 편리하고 익숙한 UART 통신은 별도의 transceiver가 필요없고 모든 MCU가 반드시 내장하게 됩니다. 그러나 보통 115200bps로 대략 10kbps로 느리며 한 바이트 통신이라는 단점이 있습니다. 예를 들어, 드론 제어를 할 경우에 다수의 센서 등과 같이 여러 바이트가 하나의 패킷이 되는 경우에는 패킷을 분리하는 작업이 용이하지 않다는 것입니다. 뿐만 아니라 UART는 하나의 장치와 두개의 선으로 독립적이야 하나 관성센서보드, 제어보드, 초음파센서보드, GPS, 무선통신만으로 5개를 초과하여 10가닥 이상이 필요하다는 것입니다.


CAN을 지원하는 MCU의 경우에는 한번에 8-byte 데이터를 전송하는 HW 패킷을 제공하므로 UART(보통 RS232/RS485) 통신에서는 패킷 통신을 위해 위에서 말한 것처럼 사용자가 일일이 패킷 형식을 만들어 주고 수신 받을 때도 그런 해석이 필요하지만 CAN은 8byte 데이터를 담는 HW 패킷 통신을 기본으로 함으로, 사용자는 데이터 버퍼에 데이터를 쓰고 전송만 하면 그 외 모든 처리는 하드웨어가 알아서 하므로 분산제어 분야 적용에도 용이하다는 것입니다.


CAN 통신의 특징:

1) 2선 twist pair를 이용한 전기적 differential 통신을 하므로 저가이며 전기적인 잡음에 매우 강해 신뢰성이 우수합니다.

2) 이론적으로 2,032개의 장치들을 연결할 수 있으나 CAN transceiver에 따라 최대 노드수(32, 64, 128...)는 달라 집니다.

3) 통신 버스를 공유하고 있는 CAN controller들은 모두가 마스터(master)가 될 수 있는 Multi-Master 통신을 합니다.

4) 40m 내에서 최대 1Mbps로 우수한 통신 속도를 갖습니다.

5) 8byte 데이터 전송을 하는 하드웨어 패킷을 제공합니다.

6) 다수의 MCU, DSP 등에 기본으로 내장되어 있습니다.

7) 통신 프로토콜/에러 처리를 하드웨어적으로 처리합니다.

8) PLUG & PLAY를 제공합니다.


CAN transceiver는 프레임이라는 패킷으로 CAN 네트워크에서 데이터를 전송하며, CAN 2.0B 버전 이후에 29bit 식별자를 갖는 extended data format의 간단한 설명입니다.



    • SOF(Start Of Frame) - 메시지 시작을 표시하며, 무부하 기간 이후 버스의 노드를 동기화하기 위해 사용

    • Identifier(ID, 식별자) - 메시지의 우선순위를 가리며 2진 값이 더욱 낮을수록 우선순위는 더욱 높아짐

    • RTR(Remote Transmission Request) - 원격 전송 요청 비트, 이 비트가 '0'이면 데이타 프레임이고, '1'이면 메세지가 원격 전송 요청을 의미

    • SRR(Substitute Remote Request) - 표준 프레임의 RTR 위치에 점유

    • IDE(IDentifier Extension) - 이 비트가 '0'이면 표준 CAN 식별자를 전송하고, '1'이면 확장 CAN 식별자를 전송을 의미

    • R0, R1 - 예약비트

    • DLC(Data Length Code) - 데이터 프레임의 데이터 바이트 수(0~8)

    • Data Field - 8byte(64bit) 전송 데이터, MSB부터 전송.

    • CRC(Cyclic Redundancy Check) - 16bit(15bit + 구획문자) 16bit checksum으로 오류 검출 Field.

    • ACK(ACKnowledge Field) - 2bit(1bit + 구획문자)로 오류가 없는 메시지가 전송되었다는 것을 나타냄.

    • EOF(End Of Frame Field) - 메세지(프레임) 종료 Field

    • IFS(Inter Frame Space) - 컨트롤러가 요구하는 시간의 양을 포함하며, 메시지 버퍼 영역에서 적절한 위치로 정확하게 수신된 프레임을 이동시킴


대표적인 CAN Transceiver로는 PCA82C250/C251가 있습니다.



'Flight Controller 이해 > 인터페이스' 카테고리의 다른 글

드론에서 사용되는 무선 통신  (1) 2017.03.09
TWI(I2C) 통신이란?  (0) 2014.03.24
Posted by Nature & Life


출처 : By Benjamin Vedder

http://vedder.se/2015/01/vesc-open-source-esc/

http://vesc-project.com/

https://github.com/vedderb/bldc(bldc 펌웨어 설계) : 모든 하드웨어 버젼에 사용

https://github.com/vedderb/bldc-hardware(bldc 하드웨어 설계) : v4.12까지

http://vesc-project.com/node/311(bldc 하드웨어 설계) : v6.4부터

https://github.com/vedderb/bldc-tool(bldc-tool 설계) : v2.18까지

https://github.com/vedderb/vesc_tool(vesc-tool 설계, bldc-tool의 새로운 버젼)

https://github.com/vedderb/bldc-logger(bldc-logger 설계)

https://github.com/vedderb(기타 프로젝터 설계)


VESC – Open Source ESC

Posted on January 7, 2015 and Post updated 2016-01-22


About this project

I have made many updates to my custom motor controller recently and the old post is getting confusing with notes and updates, I decided to write a new post about it that hopefully is more clear, more complete and easier to follow. This might sound a bit ambitions, but my goal is to make the best ESC available. I really enjoy sharing knowledge, so I want to keep all the hardware and software open.

저는 최근에 제 모터 제어기에 많은 개선을 해왔습니다 그리고 이전에 게시된 내용은 설명과 업데이트에서 혼선을 일의키고 있고, 저는 좀더 분명하고 좀더 완전하며 좀더 이해하기 쉽게 하기 위해서 새로운 게시글을 작성하기로 하였습니다. 이는 약간 애매할 수도 있지만 저의 분명한 목표는 가장 좋은 ESC를 만드는 것입니다. 저는 사실 지식을 공유하는 것을 즐깁니다. 따라서 저는 모든 하드웨어와 소프트웨어를 공개하기를 원합니다.


This is an overview of the schematic (download a complete PDF here):


This is the front of the PCB:


The back:


3D render from KiCad:


Some screenshots of the configuration GUI (BLDC Tool):


Resources

All files are on github to keep them up to date, so check these links on a regular basis:


Related posts


Forums

Because information about the VESC is scattered all over the internet and a lot of information is in email conversations with me, I have created a forum dedicated to the VESC here.

VESC에 대한 정보는 인터넷 상에서 퍼져있기 때문에 많은 정보는 저와 이메일로 대화합니다. 저는 여기에 VESC에 대한 포럼을 만들었습니다.


Live Chat

I have created an IRC channel on freenode where you can live chat with me and other users about VESC and my other projects. Feel free to join: http://webchat.freenode.net/?channels=vedder


Features

    • 하드웨어와 소프트웨어는 오픈소스입니다. 다양한 CPU 리소스가 남았기 때문에 사용자 최적화는 무한합니다.

    • STM32F4 microcontroller.

    • DRV8302 MOSFET driver / buck converter / current shunt amplifier.

    • IRFS7530 MOEFETs (other FETs in the same package also fit).

    • DRV8302에 집적화된 buck converter로부터 외부 전자장치를 위한 5V 1A 출력.

    • Voltage: 8V – 60V (Safe for 3S to 12S LiPo).

    • Current: 수 초동안 250A까지 혹은 온도와 PCB 주변에 공기 순환에 의존하여 연속적인 약 50A.

    • Sensored and sensorless FOC wich auto-detection of all motor parameters is implemented since FW 2.3.

    • Firmware based on ChibiOS/RT.

    • PCB size: slightly less than 40mm x 60mm.

    • Current and voltage measurement on all phases.

    • Regenerative braking.

    • DC motors are also supported.

    • Sensored or sensorless operation.

    • A GUI with lots of configuration parameters.

    • Adaptive PWM frequency to get as good ADC measurements as possible.

    • RPM-based phase advance (or timing/field weakening).

    • Good start-up torque in the sensorless mode (and obviously in the sensored mode as well).

    • The motor is used as a tachometer, which is good for odometry on modified RC cars.

    • Duty-cycle control(voltage control), speed control or current control.

    • Seamless 4-quadrant operation.

    • Interface to control the motor: PPM signal (RC servo), analog, UART, I2C, USB  or CAN-bus.

    • Wireless wii nunchuk (Nyko Kama) control through the I2C port. This is convenient for electric skateboards.

    • Consumed and regenerated amp-hour and watt-hour counting.

    • Optional PPM signal output. Useful when e.g. controlling an RC car from a raspberry pi or an android device.

    • USB포트는 모뎀 프로파일을 사용합니다. 그래서 안드로이드 디바이스는 루팅 없이 모터 제어기에 연결할 수 있습니다. 서보 출력, 주행거리계(odometry) 그리고 여분의 ADC 입력(센서를 위하여 사용될 수 있슴) 때문에 이것은 안드로이드( 혹은 raspberry pi)로 제어되는 RC 카를 개조하기에 완벽합니다.

    • Adjustable protection against

        • Low input voltage

        • High input voltage

        • High motor current

        • High input current

        • High regenerative braking current (separate limits for the motor and the input)

        • Rapid duty cycle changes (ramping)

        • High RPM (separate limits for each direction).

    • 전류 한계에 도달했을 때 모터가 동작을 유지하면서 soft back-off 전략이 사용됩니다. 만일 전류가 너무 높다면, 모터는 완전하게 OFF 됩니다.

    • RPM limit은 또한 soft back-off 전략을 갖습니다.

    • Commutation은 모터 속도가 급격하게 변동할 때 조차도 완벽하게 동작합니다. 이는 이전 속도에 근거하여 지연을 추가하는 것 대신에 zero crossing 후에 자속을 적분한다는 사실 때문입니다. 

    • 제어기가 커진 동안에 모터가 회전할 때 commutation과 회전방향은 추적됩니다. 같은 속도를 얻기 위해서 듀티 싸이클이 또한 계산됩니다. 이는 모터가 이미 회전중일 때 부드러운 출발을 얻게 합니다. 

    • 모든 하드웨어는 센서 없는 자속 기준 제어(field-oriented control; FOC)를 위해서 준비되었습니다. 소프트웨어를 작성하는 것이 남아있습니다. 그러나 저는 FOC가 조금 정숙하게 동작한다는 것 외에 저 인덕턱스 고속 모터에 대하여 많은 이득을 갖는 것인지 아닌지 확신하지 못합니다. 센서 그리고 센서 없는 FOC는 FW 2.3 이후에 완전하게 구현되었습니다.



Posted by Nature & Life
Embedded Lecture/Arduino2017. 3. 18. 12:51


사람도 다른 사람과 의사소통을 위해서 말을 주고받듯이 Arduino Uno도 주변 장치와 소통을 위해서 소위 통신이라는 것을 해야 합니다. Ardunio Uno 보드가 PC나 주변 장치와 유선 통신을 하기 위해서는 지원하는 시리얼 통신(serial communication) 방법이 있습니다. '시리얼'이란 직렬로 병렬 통신과 구분되는 용어로, 병렬(parallel) 통신은 과거 PC가 프린터와 통신하던 방법으로 다수의 선을 이용하여 통신하기에 단위 시간에 많은 데이터를 주고 받을 수 있는 장점이 있습니다.


그러나 병렬 통신은 도로의 폭에 비유할 수 있는 다수의 선을 이용하기에 장치와 거리가 먼 경우에 비용이 커지게 된다는 것입니다. 하지만 최소한의 선로로 빠르게 데이터의 송수신이 가능하다면 가성비는 커지기에 근래에 시리얼 통신 방법이 보다 다양하게 사용되고 있다는 것입니다. Arduino Uno 보드에서는 몇가지 시리얼 통신 방법을 지원하는데 우선 USART를 이용하는 방법입니다. 시리얼 통신은 크게 동기와 비동기 방식으로 구분됩니다.


동기 통신이란 데이터를 전송시 클럭(clock)을 함께 전송하여 받는 쪽에서 이 클럭을 기준으로 미리 정해진 통신 규격(protocol)에 따라 데이터를 취하는 방식입니다. 따라서 데이터의 양방향 통신을 위해서 송신과 수신에 각각 한가닥의 선을 할당하고 클럭을 위한 선을 고려하면 3가닥으로 직관적인 통신이 가능하다는 것입니다. 이를 USRT(Universal Synchronous Receiver and Transmitter)라 명명합니다.


뿐만 아니라 비동기 방식이 있는데 이는 클럭이 필요없이 오직 2가닥으로만 통신하는 방법으로 선로에 대한 비용을 더 감소시킬 수 있지만 하드웨어가 복잡해지는 단점이 있습니다. 그러나 동기식 처럼 수신 쪽에서 항상 대기할 필요 없이 다른 일을 하다가 데이터의 송수신이 가능하므로 MCU의 속도가 빠르게 개선되는 요즈음 필요한 방식이라는 것입니다. 이를 UART(Universal Asynchronous Receiver and Transmitter)라 부릅니다.


USART는 USRT와 UART 방식을 모두 지칭하는 것으로 Arduino Uno 보드는 동기식과 비동기식을 모두 지원합니다. 참고로 RS232, RS485는 시리얼 통신을 위한 전기적 혹은 하드웨어의 규격을 나타내는 말입니다. 이 보드에 사용하는 UART는 주로 Arduino IDE와 같은 PC와의 통신에 사용됩니다. 0번(Rx)과 1번(Tx) 핀을 사용하며 데이터는 MCU로부터 USB 통신을 담당하는 칩을 경우하여 USB 신호로 상호 변환된 후 PC와 송수신하게 됩니다. 또한 아두이노가 PC와의 통신을 수행하고 있다면 이 핀들을 다른 용도로 사용하면 안되며, 통신을 수행할 때에는 TX, RX라고 표시된 LED가 점멸함을 확인할 수 있습니다.



UART와 관련되 아두이노의 라이브러리는 Serial 클래스를 확인하시기 바랍니다. 다음은 UART의 예제입니다. PC에서 문자 하나를 받아서 그것이 '0'이면 LED를 끄고 '1'이면 LED를 켜는 프로그램으로, 아두이노는 데이터가 사용자로부터 들어올 때까지 대기 상태로 있다가 데이터가 입력되면 수행하게 됩니다.


#define LED 13
  void setup() {
 pinMode(LED, OUTPUT);
 Serial.begin(9600);
}
void loop() {
 if ( Serial.available() ) {
   char command = Serial.read();
   if (command == '0') {
     digitalWrite(LED, LOW);
     Serial.println("LED off.");
   }
   else if (command == '1') {
     digitalWrite(LED, HIGH);
     Serial.println("LED on.");
   }
     else {
     Serial.print("Wrong command :");
     Serial.println(command);
     }
  }
}


Serial.begin(long baud_rate) 함수는 UART 통신을 초기화 시키고, 통신 속도(baud rate)를 지정합니다.


Serial.available() 함수는 수신되어 내부 버퍼(64 byte)에 저장된 데이터의 개수를 반환합니다. 만일 버퍼가 비어있다면 0을 반환합니다.


Serial.read() 함수는 수신되어 내부 버퍼(64 byte)에 저장된 데이터 중 가장 첫 번째 데이터(ASCII코드)를 읽어서 반환합니다. 이 함수가 수행되면 내부 버퍼의 크기는 하나씩 줄어들며, 내부 버퍼가 비었다면 -1을 반환합니다.


Serial.print(val) 함수는 입력값을 ASCII값으로 변환하여 PC에 출력하며, 전송된 데이터의 바이트 수를 반환합니다. 비동기 통신 방식이므로 데이터가 전송되기 전에 반환하게 됩니다. 인수 val은 어떤 데이터 타입도 가능합니다.다. 예를 들면,


Serial.print(78) -> "78"

Serial.print(1.23456) -> "1.23456"

Serial.print('N') -> "N"

Serial.print("Hello world.") -> "Hello world."


두 번째 인수로 출력 형식을 지정할 수도 있습니다. 예를 들면,


Serial.print(78, BIN) gives "1001110"

Serial.print(78, OCT) gives "116"

Serial.print(78, DEC) gives "78"

Serial.print(78, HEX) gives "4E"

Serial.println(1.23456, 0) gives "1"

Serial.println(1.23456, 2) gives "1.23"

Serial.println(1.23456, 4) gives "1.2346"


Serial.println() 함수는 출력 문자열의 끝에 줄바꿈 기호 '\r\n' 가 자동으로 붙는다는 점 외에는 Serial.print()함수와 동일한 동작을 수행합니다.


이 예제에서 내부 버퍼란 전송된 데이터가 일시적으로 저장되는 내부 메모리를 말하며 데이터가 전송된 순서대로 저장됩니다. Arduino Uno의 내부 버퍼의 크기는 64 byte인데, 수신된 데이터를 사용하려면 내부 버퍼에서 이 데이터를 읽어내야 하는데 이때 사용되는 함수가 Serial.read() 함수입니다. 가장 먼저 전송된 데이터 하나를 읽어낸 후 그 데이터는 버퍼에서 삭제되며, 만약 버퍼가 비었다면 -1을 반환합니다. 따라서 버퍼에 읽어낼 데이터가 있는지 없는지를 먼저 검사하는 것이 일반적이고 이때 사용되는 함수가 Serial.available()입니다.



'Embedded Lecture > Arduino' 카테고리의 다른 글

인터럽트와 volatile 지시자  (1) 2017.03.18
아두이노의 TWI(I2C) 통신  (0) 2017.03.18
인터럽트의 처리(1)  (0) 2017.03.12
LED 깜박이기  (0) 2017.03.12
아두이노(Arduino) 코딩의 시작  (0) 2017.03.12
Posted by Nature & Life


ESC(electronic speed controller)를 설계할 때 왜 STM32가 유리한가요?


  • High side와 low side에 PWM이 automatic dead-time이 추가를 허용하는 일차적인 FET 제어기로서 TIM1을 사용할 수 있고 다른 이득 등을 제공합니다.

  • 저 비용의 개발 툴

In-Circuit Debugger/Programmer

  • 컴파일러로써 ARM GCC

  • SWD 프로그래밍/디버깅

  • I2C, CAN 지원

  • PWM 제어

  • 클럭 정밀도

정밀한 클럭은 일부 외장 오실레이터(oscillator) 타입을 요구합니다. STM32 내부 오실레이터의 정밀도는 1% 이내입니다. 이는 closed loop 실제 속도, PWM 주파수 정밀도 그리고 timing에 연관된 어떤 보고된 값들에 영향을 줍니다. 또한 이는 UART 최대 통신 속도에 어떤 밀접한 관계를 갖을 것입니다.

일차적인 클럭 속도는 72MHz의 외장 부품을 사용할 수 있지만 내부 오실레이터를 사용할 때 64MHz로 제한됩니다. 이는 64MHz에서 보드상에 프로세싱 파워가 충분하기 때문에 문제가 되질 않습니다.

  • UART

오픈 소스 커뮤너티에서 요구하는 것처럼 USART에 완전한 FTDI 접근을 합니다. 이를 사용하여 CLI(시리얼 터미널과 같은 Command Line Interface)가 구현될 수 있습니다.

  • 모든 FET 상에 게이트 저항

이는 FET turn-on 특성에 정밀한 제어를 할 수 있습니다. FET를 천천히 켜는 것(높은 게이트 저항)은 FET 상에 손실을 증가시킵니다. 그러나 전압 버스에 고주파 잡음을 엄청나게 줄일 수 있습니다. FET를 빠르게 켜는 것(낮은 게이트 저항)은 FET의 손실을 감소시키지만 전압 버스 상에 엄청난 잡음을 증가시킬 것입니다. 이것은 마이크로컨트롤러의 reset, 버스 커패시터 사이즈 그리고 다른 잡음 관련된 설계 결정 이슈에 큰 영향을 줍니다. Dead-time에 관련하여 너무 짧다면, 느린 FET는 실제로 위험할 수 있습니다.

  • 최근에 AVR 시리즈와 같이 STM32 시리즈도 Arduino 환경을 지원합니다.

  • 특히 Cortex M4 경우에 100% C 언어 프로그램이 가능합니다. 고성능의 high end 급의 소형 마이크로컨트롤러로 RISC, Pipeline 등의 구성으로 사실상 assembly 코딩이 불가능하지만, 다른 마이크로컨트롤로 달리 C 언어를 완벽하게 지원하여 assembly의 이해가 필요 없다는 것입니다. 기존의 마이크로컨트롤러는 C 언어를 지원하여도 최상의 성능을 위해서는 assembly 코딩이 불가피하지만 Cortex M4는 의미가 없으며 C 언어에서 지원하지 않은 명령어에 대해서는 intrinsic 함수로 assembly 코드로 1:1 변환하며, 디버깅 시에 C 언어 소스 코드가 의도한 assembly 코드로 올바르게 컴파일 되었는지 확인할 수 있는 정도의 assembly 언어 지식이 요구됩니다.



'Embedded Programming > STM32 Cortex-M4' 카테고리의 다른 글

STM32 MCU 누클레오 보드  (0) 2018.01.12
Discovery vs. Nucleo board  (1) 2018.01.11
STM32F4 시리즈의 소자 구별 방법  (0) 2018.01.03
STM32F405xx 스펙 요약  (0) 2017.11.17
AVR vs. STM32 comparison for Drone  (0) 2015.12.04
Posted by Nature & Life


아두이노(Arduino)가 오픈 소스 플랫폼으로 자리잡은 이유는 AVR 칩이 제공하는 Self-programming 기능으로 거슬러 올라갑니다. Self-programming 기능이란 칩의 퓨즈를 적절히 설정함으로써 부팅시 Application 영역이 아닌 Boot 영역으로 시작 지점이 변경된다는 것입니다.



한편, AVR 칩은 추가적인 하드웨어 구성 없이 USART나 TWI, SPI 등으로 통신이 가능한데, 칩이 Boot 영역에서 수신된 데이터를 감지하고 Application 영역을 변경할 수 있다는 것입니다. 이러한 기능은 3세대 AVR 칩에서 등장하여 펌웨어의 유지 및 보수 목적으로 특히 가혹한 원격지에서 펌웨어 업그레이드에 유연성을 주기 위함이었습니다.


따라서 이러한 기능이 가능하게끔 작성된 Bootloader를 최초 한번 JTAG이나 ISP를 이용하여 펌웨어를 프로그래밍을 하면 아두이노는 그 다음부터 ISP 없이 USART로 프로그램의 간단히 업로드가 가능하게 됩니다. 결국 아두이노 보드는 아래 회로도에서와 같이 별도의 ATmega16U2 칩을 이용해 USB로 데이터를 송수신하고, 이를 다시 ATmega328 칩에 USART 규격으로 통신하는 구조를 가집니다.



요약하면 아두이노 IDE 환경은 AVR 칩에 최초 Bootloader를 탑재하여 PC의 USB 포트로 C 코드인 스케치(Sketch) 파일을 컴파일하고 이를 아두이노 보드로 추가의 하드웨어 없이 전송하여 쉽고 빠른 개발환경을 제공한다는 것입니다. 게다가 아두이노 IDE 환경에서 함께 제공하는 Serial Monitor를 이용해서 클릭 한번으로 그 결과를 바로 확인할 수 있다는 장점을 가집니다.





Posted by Nature & Life

 

 

통신약정(Protocol)이란 데이터를 보내는 사람과 받는 사람이 정보를 오류없이 원할히 주고 받을 수 있도록 쌍방간에 정하는 규칙 혹은 약정입니다. 이는 원거리 인터넷이나 FAX 통신도 혹은 PC와 그 주변기기와의 통신같은 근거리 통신에도 반드시 존재하며 자동차 내에서 혹은 한 보드내에서 칩과 칩 사이의 통신에도 적용됩니다.

 

AVR의 경우에는 다른 칩과의 통신방법으로 SPI(Serial Peripheral Interface)인 SCI(Serial Communication Interface, UART)나 TWI 통신을 지원합니다. 어느 정도 근거리 통신에서도 사용되어야 하기에 송수신에 앞서서 노이즈 등에 대비하여 신호의 크기를 키워야 할 필요가 하는데 이것이 PC 등에 사용되는 RS232C 트랜시버가 됩니다.

 

이러한 SPI 방식에서는 보내는 라인과 받는 라인 그리고 동기화된 클럭(Clock)으로 3가닥의 라인을 필요로 하였고, 한편 이 라인의 수를 더 간소화시켜 오직 2가닥 만으로 데이터의 송수신을 가능하게 한 새로운 인터페이스(Interface)를 제공하게 되었는데 이를 TWI라고 명명합니다.

 

TWI는 'Two Wire Interface'의 약자로 이를 통해서 AVR 칩은 오직 2가닥 만으로 128개의 다른 장치들과의 통신할 수 있다는 것입니다. TWI는 Atmel社 등이 주로 사용하지만 1980년대 Philips社에서 만든 I2C 인터페이스와 매우 유사하여 하드웨어의 별다른 수정없이 그대로 사용할 수 있다는 장점이 있습니다. 통상 I2C 인터페이스가 2가닥의 라인을 이용하므로 TWI라 부르게 되었습니다.

 

Philip社에서 제창한 I2C(IIC)는 칩(IC)간의 통신을 의미하는 'inter IC(Integrated Circuit)'의 준말로 'i square c'라고 읽으며, 비록 서로 다른 회사로부터 만들어졌지만 10-bit 주소나 고속 모드(high speed mode) 등에 차이를 제외하면 서로 호환가능하여 수정없이 사용할 수 있다는 것입니다.

 

TWI 통신이 가능한 장치는 데이터(SDA, Serial Data Line)와 클럭(SCL, Serial Clock) 라인이 공통 버스(bus)에 연결되어 고유의 주소값을 가져 다른 칩과 통신시 master와 slave의 관계를 번갈아가며 데이터의 송수신이 가능합니다. 표준 모드(standard mode)에서 100kbit/s로 통신할 수 있고 버스의 capacitance가 400pF을 넘지 않는 한도에서 칩을 계속 연결할 수 있다고 알려집니다.

 

 

 

 

간단하게 설명하면 아래 그림과 같이 데이터(SDA)를 클럭(SCK)에 동기화하여 주고 받는 방식으로 먼저 데이터를 주고 받고자하는 장치 주소(Address)를 1~7번 비트에 싣고 보낼지 읽을지에 따라서 8번 비트를 Read('1')나 Write('0')로 설정하며 그 다음에 데이터를 연속적으로 읽거나 실을 수가 있다는 것입니다.

 

 

 

여기서 ACK 비트는 정보의 송신자에게 직전 8-bit의 정보를 수신했는지의 여부를 확인하는 값입니다.

 

 

'Flight Controller 이해 > 인터페이스' 카테고리의 다른 글

CAN 통신이란?  (0) 2017.12.24
드론에서 사용되는 무선 통신  (1) 2017.03.09
Posted by Nature & Life