Embedded System Control and Setup

From Lofaro Lab Wiki
Revision as of 01:24, 11 May 2016 by Agoldsto (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Overview

This tutorial goes over the programming and use of the embedded systems that are placed into each of the robotic arms in order to make sign language movement possible. This tutorial assumes that the user has prior knowledge of making project folders and empty projects in Code Composer Studio and uploading programs to a MSP432 microcontroller, which is the microcontroller of choice for the embedded system. If not, there are supplementary tutorials embedded within this page which can help with these tasks.

Hardware

Tristate.PNG

Before any software can be uploaded and tested, external hardware must be made in order to interface with the servos in each of the robot's arms. To recreate the circuit above, one will need a 200 ohm resistor, a 10 kOhm resistor and a tri-state buffer IC, such as the SN74LVC245A octal tri-state buffer IC by Texas Instruments. Once this circuit has been recreated, the MSP432 can now be connected to this circuit, and a wire can be connected to the node that is formed at pin 18; this wire will act as the signal line to the servos.

After connecting the signal line to the node described above, locate pins 2.1, 2.2 and 2.3 on the MSP432 Launchpad; these pins will correspond to the MSP432's direction, transmit and receive lines once the board has been properly programmed. Upon locating these pins, connect pins 2.1, 2.2 and 2.3 to pins one, two and three of the tristate buffer IC, respectively.

Once the MSP432 has been connected to the external hardware circuit shown above, the Raspberry Pi 2's pinout sheet should be referred to in order to find its SPI bus pins. Once these are found, male-to-male header pins must be soldered onto the bottom of the MSP432 Launchpad in order to access pins 9.4, 9.5, 9.6 and 9.7. After pins have been soldered to the GPIO ports, connect pin 9.4 to the Raspberry Pi's chip select, 9.5 to the Pi's clock, 9.6 to the Pi's MISO, and 9.7 to the Pi's MOSI. Finally, solder one more male-to-male header at the bottom of the Launchpad for pin 10.0, and find pins 1.5, 6.6 and 6.7; these pins will act as our error, ready, go and emergency flags for fast communication with the Pi, respectively. At this point, it is up the designer of the Raspberry Pi to determine which GPIOs they want to use for the fast communication described above, as it does not matter which pins they use, as long as they do not interfere with the Pi's SPI bus. It should be noted, however, that the GPIOs that connect to pins 10.0 and 1.5 on the MSP432 must be active high inputs on the Pi, and the GPIOs on the Pi that connect to pins 6.6 and 6.7 on the MSP432 must be active low outputs; therefore, the inputs on the Raspberry Pi must be pulled low, while its outputs must be pulled high.

Once all of these connections are made, one can then program the MSP432.

Programming the MSP432

If you do not have Code Composer Studio, or CCS, installed on your computer, be sure to visit http://www.ti.com/tool/ccstudio to install the latest version. Once this has been installed, please follow the tutorial at [1] to set up a empty project in CCS. After following that tutorial, one should now have an empty project folder in the their Project Explorer tab, as illustrated in the tutorial and shown below.

Empty project.PNG

Once this is complete, download the embedded system code at https://github.com/ASL-Robot/msp430-dxl/tree/master/msp432-dxl; be sure to download all of the .c and .h files, as they are all needed for robotic movement. Right click on the empty project folder that was created, and then on "Add Files"; once again, be sure all of the .c and .h files are added to the project. After all of the appropriate .c and .h files have been selected, click on the "Copy Fles" option to copy all of the files into the project folder's main directory, as shown below.

Copy links.PNG

After clicking "OK", all of the files should be added to the project folder and now, one can program the microcontroller. Now, click on the "main.c" file within the project folder, which should open up the file in the main window. After do so, click on the hammer icon in the top left corner of the screen in order to compile each file, and then click on the bug icon to program the MSP432. These icons are featured in the screenshot shown below.

Compile.PNG

Once compilation and programming are complete, a green "play" icon should be featured at the top of the screen; press the green play icon, then press the red "stop" icon after a few seconds. At this point, the microcontroller has been successfully programmed and can now act as an embedded system within the robot.

Interfacing with the Embedded System

The embedded system follows a SPI protocol which the main controller, the Raspberry Pi 2, must follow in order to command it correctly. A tutorial on how to use the Raspberry Pi 2's SPI bus can be found at https://learn.sparkfun.com/tutorials/raspberry-pi-spi-and-i2c-tutorial. There are three types of packets that can be sent to the embedded system: a movement packet, a read packet and an error packet.

Each packet begins the same; one must send out which packet type they wish to convey to the embedded system. If a 0x01 is sent to the embedded system, then the system will analyze this to be a movement packet, where it will then wait for additional information on which motors to move and their time specifications. If a 0x02 is sent, then the embedded system will send back all of the positional readings of the robot, in id numbered order. For example, if a 0x02 is sent to the embedded system, and the embedded system sends back a 0x00 and then four other bytes of information, then that means that the motor with ID 0 is currently at a position which is told by the four following bytes. These bytes are in little endian order and correspond to a 32-bit floating point number representing the motor's position in radians. The embedded will repeat this action eight times, as there are expected to be eight motors within each robot's arms; the ID scheme of the motors can be found in the section entitled "Motor ID Scheme". Lastly, the embedded system will send back an extra byte of information corresponding to the robot's current "checkpoint"; this will be covered later in the tutorial. If a 0x03 is sent to the system, the embedded system will send back a single byte of information correspond to the current error state of the robot. If the byte that is sent back is non-zero, then the robot is facing an error. However, if it is zero, then the robot is currently not facing an error and can carry on with motions. Timing diagrams for these packet types can be found in the Timing Diagrams section.

As state previously, if a 0x01 is sent to the embedded system, it will interpret the packet as a movement packet and will wait for the number of movements, the motor IDs that are expected to move, their positions and their start and end times. A timing diagram on the bytes to send the microcontroller can be found in the section entitled Timing Diagrams.

After all of the movement packets have been sent and the embedded system has processed them all, the Raspberry Pi should receive a logic high on its "ready" pin; this is to indicate to the Raspberry Pi that the embedded system is ready to send out the movement packets to the motors. Once this logic high is received, the Raspberry Pi should send out a logic low on the "go" signal in order to begin movement.

Lastly, movement can be stopped if a logic low is sent the embedded system's "emergency" pin. This will automatically hold all of the motors in their place and will wait for more movement packets from the Raspberry Pi.

Timing Diagrams

NOTE: If a number follows a letter in the diagrams below, such as "p0" or "t3", the number corresponds to the specific byte position within that packet. So, in the below diagram, p0 represents the LSB of a 32-bit packet, p1 represents the second byte, p2 represents the third, and p3 represents the MSB of the packet.

Packet type one.PNG

Above is the timing diagram to command the robot to some simple movements. 0x01 must be sent first to signify that the packet being sent is a moving packet, then the low byte of the number of movements, mv_l, then the high byte of the number of movements, mv_h. So, if 256 movements need to be sent, then the low byte must be 0x00, while the high byte must be 0x01.

Afterwards, the id of the motor that needs to be moved is sent. Refer to the section "Motor ID Scheme" to find which ids correspond to which joints.

Finally, the position and speed data must be sent. The position data, denoted by p0-p3, should be sent over to the motor in 32-bit floating point form, expressed in radians. Each of the angles sent to the motors must be relative to their respective home positions. The start and end times, denoted by t0-t3 and e0-e3 respectively, are also 32-bit numbers, expressed in microseconds.

Packet one type for hand.PNG

If a hand movement is needed, the above timing diagram must be sent to the embedded system. It is must like above, except instead of sending a motor id, the user must send 0xFE to represent that a hand movement is needed. Afterwards, the specific gesture, or g_id, must be sent; the complete gesture listing can be found in the section entitled "Gesture IDs". Finally, the start time of the gesture must be sent, which is once again in 32-bit number, expressed in microseconds.

Packet type two.PNG

If the user does not wish to send a movement, but rather, read back the current positions of the motors, he or she can then send a 0x02 to the system to read back all of the current motor positions. The embedded system will stop sending packets when it has sent all of the motor positions back, along with its checkpoint data.

Packet type three.PNG

If the user simply wants to read back the current error state of the system, he or she can then send a 0x03 to the system to read back its current error state. As stated previously, if the data sent back is non-zero, then an error has taken place within the robot; however, if it is zero, then there is currently no error. The error byte that is sent back from the embedded system can be decoded using the table provided by Robotis below.

Error bits.PNG

Gesture IDs

NOTE: The letters that contain extra movement other than the fingers will only perform the hand gesture for that letter; only the fingers were programmed with pre-loaded gestures, not any other motor!

2: open

6: 'a'

7: 'b'

8: 'c'

9: 'd'

10: 'e'

11: 'f'

12: 'g'

13: 'h'

14: 'i'

15: 'k'

16: 'l'

17: 'n'

18: 'o'

19: 'r'

20: 's'

21: 't'

22: 'u'

23: 'v'

24: 'x'

25: 'y'

26: 'j'

27: 'p'

28: 'z'

29: 'q'

Motor ID Scheme

ID 0: AX-12A, Wrist Yaw

ID 1: MX-28T, Wrist Pitch

ID 2: MX-64T, Wrist Roll

ID 3: MX-106T, Elbow Pitch

ID 4: MX-106T, Arm Yaw

ID 5: MX-106T, Shoulder Roll

ID 6: MX-106T, Shoulder Yaw

ID 7: MX-106T, Shoulder Pitch