VIP Secure Hardware Wheelchair Team

Wesley Schon, Dan Pettinger, Karvin Dassanayake, Jack Humphries, Graham Saunders, Siyan Yu Georgia Tech Secure Hardware Research Team, Georgia Tech Robosense Team Spring 2016 Supervisors: Assoc. Prof. Vincent Mooney, Prof. Fumin Zhang

Contents

I. Introduction

II. Prior Work

III. Architecture

i. Hardware Architecture

ii. Software Architecture

IV. Subgroup Division

V. Goals

VI. ROS

i. Purpose of ROS

ii. Initial Setup

iii. Current Setup

iv. Target Setup

VII. Odometry

i. Shaft Encoder Setup

ii. Prior Issues

iii. Solution

VIII. Five-Way Controller

IX. Motor Control

i. Initial Implementation

ii. First Redesign

iii. Second Redesign

X. Power Management

XI. Central Computer Form Factor

XII. Semester Results

XIII. Future Work

XIV. References

XV. Appendices

1

1. Introduction

The goal of this project is to create a robotic wheelchair using a Linux computer, several

microcontrollers, LIDAR, and a Controller Area Network (CAN) bus. The robotic wheelchair will

drive autonomously and carry out SLAM (Simultaneous Localization and Mapping) from its

LIDAR, odometry, and other data. This project offers the additional advantage of creating an

opportunity for the Secure Hardware and Robosense research teams to build a research

platform using these technologies.

This semester, progress was made on odometry, motor control, and the Robot Operating

System (ROS) software architecture. The five-way motor controller was tested in order to gain a

better understanding of its functionalities, and this research was documented. In addition, a

new computer was built to provide a smaller alternative to the current central computer, and the

power system for the wheelchair was repaired and redesigned. Specific information on each of

these topics will follow.

2. Prior Work

Prior to this semester, a micro-ATX computer served as the main option for controlling

the wheelchair. All necessary operating system software had been installed and drivers for

CAN hardware had been installed. In addition, CAN communication from within ROS had been

demonstrated on the computer. A buggy odometry code had been developed for Arduino, using

shaft encoders to measure wheel rotation on the wheelchair. A working motor control code

responding to CAN commands had been developed for Arduino, however its functionality and

reliability were limited. Additional details are available in the VIP Secure Hardware final reports

2

for the Wheelchair Team from the Fall 2014, Spring 2015, and Fall 2015 semesters; see

Appendices C, D, and E.

3. Architecture

Figure 1. Target hardware architecture of the overall system

This semester the target architecture was updated, as previously the team had intended

to use one Arduino Uno for both shaft encoders. Now, an Arduino is connected to each shaft

encoder, making identification of information and timing easier. The previous design to connect

camera and LIDAR through an ethernet bus was dropped; both are now connected via USB.

The original communication architecture connecting the Arduinos through a CAN bus remains.

The software architecture used in ROS, as depicted in Figure 3 and detailed in Section 6, was

updated. The hardware architecture interfacing the CAN bus to the wheelchair’s motors in

previous semesters remains, and is depicted in Figure 4.

3

Figure 2. Current hardware architecture of the overall system

Currently only the Arduino for the 5-way motor controller is connected via CAN bus; the

Arduinos for the shaft encoders are connected to the computer by USB. At this time neither the

LIDAR nor Camera is being used. After the system is running with the current layout, steps

toward connecting all microcontrollers via CAN bus and establishing a better priority system can

be taken.

Figure 3. Target software architecture of the overall system

4

Figure 4. Hardware architecture of the driving subsystem

4. Subgroup Division

Due to the growing size of the Wheelchair Team, this semester’s group separated into

three subgroups, namely a Motor Control subgroup (Wesley and Siyan), an Odometry subgroup

(Karvin and Jack), and a Hardware Architecture subgroup (Dan and Graham). This separation

allowed for the team to work more efficiently by spreading the workload evenly amongst team

members. The subgroup division did not prevent team members from assisting other

subgroups, and even other Robosense teams when necessary.

5. Goals

Semester goals for this project included reworking the motor control code and

restructuring the CAN command format for motor control to create a smoother and more reliable

driving system (motor control subgroup), learning ROS and designing a ROS software

architecture for the central computer, and debugging the odometry code (odometry subgroup).

Short-term goals over the course of the semester included building a new central computer

around a mini-ITX motherboard, assisting other teams with microcontrollers, and fixing a flawed

power system (hardware architecture subgroup).

5

6. ROS

Robot Operating System (ROS) is a system of software frameworks used to control

heterogeneous robotic systems. It consists of topics which any number of nodes (elements such

as devices) subscribe (read) or publish (write) to. This project aims to use ROS as the main

mechanism enabling the different systems on the wheelchair to interact. In addition, by using

ROS, the team hopes to ensure that the data being processed can be accessed by anyone

using a peripheral system - such as a graduate student using the wheelchair for research.

6.1 Purpose of ROS

In the target architecture, the central computer is the main processing unit in the

wheelchair system. ROS is used as a tool to allow information to transfer between hardware

components. In ROS, the team this semester hoped to implement features of the following

components:

● Odometry system

● SLAM

● Motor Control

6.2 Initial Setup

Figure 5. Initial organization of ROS packages, nodes, and topics

6

6.3 Current Setup

While ROS is currently installed on both computers (one onboard the wheelchair and

one off the wheelchair) code has been tested and run primarily on the extra offboard computer.

6.4 Target Setup

The target ROS architecture will require some testing, as well as minor additions. The

testing is needed to verify that the odometry package correctly publishes and subscribes to

topics as well as to verify the validity of the data produced by the package.

Sensors are being integrated in ROS to enable future development. After confirmation

of the validity of the instruments on the wheelchair, work will begin on the process of finding a

suitable SLAM algorithm in ROS.

7. Odometry

After testing on the initial odometry setup, it was determined that to solve the identified

issues more processing power would be needed, as well as the ability to calculate wheel

rotation for one wheel in a manner that does not interfere with the ability to calculate wheel

rotation for the other. The solution was to change the hardware architecture of the system.

The hardware architecture would have each shaft encoder connected to its own Arduino,

keeping track of a wheel’s rotation independently. By isolating each wheel’s rotation tracking

system, the error attributed to interrupts attempting to occur at the same time would be avoided.

7

After each wheel’s phase, the information is then send to the central computer. Using ROS, this

data can be combined using a ROS package, and then the resulting odometry data can be

published onto a topic.

7.1 Shaft Encoder Setup

The wheelchair uses two TRD-S2500-BD model shaft encoders mounted on each of the

primary motor driven wheels. Figure 7 provides a depiction of how each shaft encoder

functions. Each shaft encoder has two utilized outputs (labeled A and B) and these outputs

produce a high signal whenever a bar located on the encoder disk passes by an optical sensor.

From these two outputs there are four possible states as depicted in Figure 8.

Figure 6. Each shaft encoder is now connected to a dedicated Arduino

8

.

Figure 7. Representation of shaft encoder hardware It is important to note that the diagram above is inaccurate in the following ways; there are multiple bars on the

encoder disk (the encoder resolution is 2500 therefore, most likely there are 2500 bars as well ), The location of the sensors may be inaccurate, and the direction of the black bar will change depending on if the chair is moving forward

or backward.

Figure 8. Shaft encoder states: each one of the states generated by the encoder

corresponds to a unique set of outputs (for example state a designates when output A is low and output B is high).

The code on the encoder Arduino detects when output A is a high signal and then

checks to see the state of output B. If output B is high then the encoder is in state d which

indicates that the wheel is moving in the forward direction. If output B is low then the encoder is

9

in state C which indicates that the wheel is moving in the backwards direction. Thus, from

outputs A and B the overall motion of either wheel on the chair is able to be determined.

7.2 Prior Issues

The previous semester’s team recorded issues with the odometry system towards the

end of the working semester.

The team noted that when the wheelchair was used, it would not accurately track the

position of the wheelchair as it moved. When shaft-encoders were individually tested at low

velocities, the odometry readings would be accurate - correctly showing the simulated position

of the wheelchair.

During use-case testing (running our odometry system while shaft encoders were

attached to our wheelchair as it was in motion) the odometry system failed to accurately

represent the motion the wheelchair was undergoing. When the wheelchair was moving in

forward in a straight line, the odometry system would represent a sharp turn in an arbitrary

direction. Since the issue was recognized during the last week of the semester, the issue was

not resolved at that time.

7.3 Solution

During the first few weeks of the current semester, testing was done to the identify what

issue in the odometry system caused this error. Initial work to identify the issue was to modify

the shaft encoder code so that the encoders were printing the “encoder counts” to the serial port

of the Arduino, rather than the x and y position of the wheelchair. From this data, information

could be obtained that could suggest the cause of the encoder error. The goal for this was to

determine if the issue was due to the method by which odometry was being calculated or to how

10

motion was being recognized by the Arduino dedicated to keeping track of the odometry

system.

Figure 9. Output of serial port of Arduino dedicated to odometry during testing. Each column refers to the amount of discrete encoder motions detected by each shaft encoder. The left side corresponds to the encoder mounted on the left wheel, while the right column refers to

the corresponding encoder on the right wheel.

The testing mechanism was to compare the amount of discrete encoder rotation

increments detected by each shaft encoder. If the angular displacement was equal (the wheels

would rotate the same amount in relation to each other) the ‘encoder count’ detected by the

right shaft encoder would be the negation of the ‘encoder count’ detected by the left shaft

encoder - this is because each encoder is mounted in opposite orientations.

Through testing it was determined that when the chair was driven straight, the odometry

Arduino would make roughly 15% more motion detections on one encoder than the other. This

is shown by the left encoder detecting roughly 18000 discrete movements while the right

11

encoder detected roughly 21000 discrete movements. If the method of measuring odometry was

accurate, the amount of discrete movements detected by each should have been nearly equal.

After research into how the Arduino was detecting shaft encoder motion, a possible

causation of this error was attributed to the Arduino hardware. In the pre-existing setup, one

Arduino was handling wheel tracking and odometry calculation. In addition, the code utilized to

keep track of wheel motion made use of 2 interrupt functions - each triggered by monitoring one

of the shaft encoder outputs. The issue is believed to have been caused by a combination of the

lower than needed processing power of the Arduino and the mechanism the Arduino uses to

handle interrupt calls.

8. Five-Way Controller

The proprietary five-way controller (DX-5SW from Dynamic Controls) used to directly

control the wheelchair motors was researched in order to better understand its functionalities. A

prior lack of understanding caused several problems driving the wheelchair, as will be further

discussed in Section 9 of this report. The controller was tested by attaching it to a five-way

switch and simulating various situations and inputs by hand. The results of this research are

included in Appendix B. As the product has been discontinued by its manufacturer, official

detailed documentation on the controller was not able to be found. For the purposes of this

project, the information collected during testing is believed to be sufficient.

12

9. Motor Control

9.1 Initial Implementation

The implementation of motor control inherited from previous semesters had several

problems which made it unreliable. First, it did not make any attempt to differentiate between

motor control messages and other messages on the CAN bus. It would have attempted to

execute any message as a wheelchair motor command, which would have made driving the

wheelchair correctly impossible once odometry and other types of messages are sent over the

same CAN bus as the motor control commands. Another problem with the initial driving system

is that it did not allow for a wide enough range of commands to be issued to effectively interface

with the 5-way controller connected as seen in Figure 4. The available commands in this

system are shown in Table 1. This led to an overall lack of control and an unreliable system.

Table 1. CAN message format in initial implementation of driving code

13

9.2 First Redesign

The first redesign of the driving code sought to fix these problems by restructuring the

CAN message format used to communicate commands to the Arduino interfacing with the

five-way controller. The first byte of the CAN messages for this purpose was used to identify the

messages as “driving commands.” If the Arduino noticed a driving command on the CAN bus, it

would then check the last byte of the message for the command type, as shown in Table 2. A

“pulse” function was added to the Arduino code to control the speed at which the wheelchair can

move forward and backward, and specific calls to this function were linked to corresponding

CAN input commands. In addition, an internal state machine was used to keep track of the

wheelchair’s activity, in order to allow it to drive forward without constantly accelerating, and to

allow it to adjust right and left while driving forward and backward. The state machine

implemented is shown in Figure 10. After the first redesign, the wheelchair was able to be

controlled more effectively. However, the implementation of the pulse function caused one

second of latency in some cases, which was identified as a safety hazard. Additionally, it was

decided that the wheelchair should have variable speed control.

Table 2. CAN message format after first re-implementation of driving code

14

Figure 10. Allowed state transitions after first re-implementation of driving code

9.3 Second Redesign

In the second redesign, the Arduino code structure was altered to remove the latency

introduced with the pulse function in the first redesign. Rather than entering a loop when pulse()

is called, several variables were added which track the progress of the pulse function over

multiple iterations of the main program loop. The internal state machine was removed, and

more commands were added to allow the wheelchair’s acceleration to be controlled as detailed

in Table 3. The Arduino code used to control the wheelchair via the five-way controller is

included in Appendix A.

Table 3. CAN message format after second redesign of driving code

15

10. Power Management

After several semesters of different teams installing projects onboard the wheelchair, the

state of the wheelchair’s onboard power system at the beginning of the semester left much to be

desired. While the original wiring scheme provided 24VDC to the motors and proprietary CAN

bus without issue, there was no structure for providing the power necessary for other devices

that the team intended to mount on the wheelchair, including the shaft encoders,

microprocessors, LIDAR, webcam, and central computer. Furthermore, the shaft encoder

prototype system was unorganized; because the encoders require a 12VDC signal, they were

attached to just one of the two series lead acid batteries, creating an unbalanced load. The

encoders were left attached to the batteries at all times, causing leakage current to sulfurize one

of the batteries to point where it could no longer be recharged.

A new power system was designed in the interest of providing power that would be meet

the required specifications. The new system uses standard 16ga color-coded, insulated power

cables with Anderson powerpole connectors. Each voltage level necessary for powering a

device on the wheelchair has its own powerpole connector distribution block. This will also

prevent the risk of battery damage due to unbalanced load. The architecture of this system is

shown in Figure 11.

16

Figure 11. Power system architecture

11. Central Computer Form Factor

It was decided partway through the semester that a smaller form-factor was needed for

the central computer. The computer must eventually fit on the back of the wheelchair, and the

micro-ATX form factor is not ideal for this due to the large size of micro-ATX-compatible cases.

It was also determined that having a more rugged motherboard (such as a mini-ITX

motherboard) would be advantageous since the computer will be mobile in the future. A list of

key specifications for the new computer is listed in Table 4 below. Hardware for a mini-ITX

computer, including a case, was acquired and assembled. A full clone of the Linux file system

currently implemented on the original central computer was created for the new computer using

Clonezilla. Having two computers with which to work is especially beneficial given the large size

17

of the Wheelchair Team, since work can now be distributed across computers more easily. In

addition, having two separate systems gives the team an advantage while debugging. An

efficient system of version control for the Wheelchair Team’s software will need to be

established in the future.

Table 4. Center Computer Key Specifications

12. Semester Results

This semester each subgroup team made notable progress. The odometry subgroup

completely updated the chair’s software architecture. Odometry was moved off of the encoder

Arduinos and onto ROS on the central computer. In order to do this the team had to learn about

publisher/subscriber relationships in ROS as well as deal with a whole slew of message type

issues. The motor control subgroup was able to increase responsiveness, maneuverability, and

18

utility by going through several iterations of design. The final iteration was able to decrease the

lag time in response to motor control commands, increase movement range from 5 commands

to 7 commands, and send labeled commands over CAN bus as to avoid confusion between

motor control commands and any other messages on the CAN bus. The hardware subgroup

designed and assembled the central computer. There are now two computers for code

development and debugging. Using Codezilla the OS from the previous computer was copied

onto the new computer. The new computer is small enough that it fits onto the back of the

wheelchair easily. It was also confirmed that the central computer will run on a Lipo battery. A

new power supply structure was designed to prevent further power leakage, after one of the two

batteries died. It was decided to move a greater portion of the decision-making of the system to

the central computer as opposed to the motor control and odometry nodes. This is due to a lack

of sufficient processing power on the Arduino microcontrollers, as well as

ease-of-implementation.

13. Future Work

The odometry code must be finalized so that it is able to publish correctly onto ROS.

The individual components of the system must be integrated, and the Arduinos connected to the

shaft encoders must be connected to the system’s CAN bus. USB timing characteristics on the

central computer should be researched. The team will need to interface the LIDAR unit with the

central computer and implement drivers to properly recognize and report LIDAR data. Once

these components are assembled, algorithms for autonomous driving and SLAM should be

researched and implemented. Additionally, encryption of the CAN bus and closing of potential

vulnerabilities to hardware tampering should be considered.

19

While rudimentary form of the power system has been constructed at this point, the rest

of the power system needs to be assembled. The team will either need to locate the previous

charging solution for the Lipo batteries or order new charging cables. Power system assembly

will involve measuring out and constructing powerpole cables, building a simple rocker switch

mechanism to interface with the computer’s power supply, and assembling a power panel

consisting of the 24V and 12V powerpole distribution blocks, the linear voltage regulator, the

microprocessors, and a pair of Lipo batteries mounted on a 12”x12” piece of plexiglass.

Additionally, future work will be necessary in order to safely and securely mount the central

computer and power panel on the wheelchair’s rear tray.

14. References

● Robotic Wheelchair Central Computer – Collaboration of Hardware Security Research and Robosense VIP Teams - Wesley Schon Fall 2014 Report

● Wheelchair Group - Wheelchair Team Spring 2015 Report ● http://peak-system.com/Home.59.0.html&L=1 ● https://physics.ucsd.edu/neurophysics/lab/encoderld.pdf

15. Appendices Appendix A. Arduino code for motor control after the second redesign /*Arduino code for motor control Wesley Schon, Dan Pettinger, Siyan Yu Georgia Tech VIP Secure Hardware and Robosense 2016 */ /*NEW FORMAT FOR CAN BUS MESSAGES: * 3 0 0 0 x * ^3 indicates that this is a drive command * * x can be replaced with various numbers to indicate specific command: * 1 = brake p6 * 2 = accelerate forward p2 * 3 = forward p2 * 4 = accelerate reverse p3 * 5 = reverse p3

20

* 6 = right p4 * 7 = left p5 * middle 3 bits are arbitrary. They could potentially be used to include other information along with * driving commands on the bus simultaneously in the future (since this code ignores them) */ #include <SPI.h> #include "mcp_can.h" unsigned char Flag_Recv = 0; unsigned char len = 0; unsigned char buf[8]; char str[20]; bool fwd = false; bool rev = false; int on = 500; //arbitrary numbers for frequency of pulses, need to be changed. int off = 500; int cycles = 5; int on2 = 500; int off2 = 500; int cycles2 = 2; int reverse_count = 0; int pulsecount = 0; bool inc = true; int per1 = 8000; int per2 = 1200; MCP_CAN CAN(10); // Set CS to pin 10 void setup() { Serial.begin(9600); for (int i=0; i<=4; i++) {; pinMode(i+2, OUTPUT); } START_INIT: if(CAN_OK == CAN.begin(CAN_1000KBPS)) // init can bus : baudrate = 1000k { Serial.println("CAN BUS Shield init ok!"); } else { Serial.println("CAN BUS Shield init fail"); Serial.println("Init CAN BUS Shield again"); delay(100); goto START_INIT; } } void loop() { if(CAN_MSGAVAIL == CAN.checkReceive()) // check if data coming {

21

CAN.readMsgBuf(&len, buf); // read data, len: data length, buf: data buf for(int i = 0; i<len; i++) // print the data { Serial.print(buf[i], HEX); Serial.print("\t"); } Serial.println(); ///////////Commenting out the next few lines for now /* for(int i = 0; i<len; i++) { // print the data if (buf[i] == 1) digitalWrite(i+2,HIGH); else digitalWrite(i+2,LOW); //Serial.println("Stuff happening"); */ if (buf[0] == 3) { //if the message on the CAN bus is a driving command switch(buf[4]) { //The last bit on the message holds the specificdriving command, last bit should be (len-1),right? case 1: //brake case digitalWrite(2, HIGH); digitalWrite(3, HIGH); digitalWrite(4, HIGH); digitalWrite(5, HIGH); digitalWrite(6, LOW); fwd = false; rev = false; break; case 2: //Accelerate forward case fwd = true; rev = false; pulse(2, per1, &pulsecount, 20); //20% duty cycle digitalWrite(3, HIGH); digitalWrite(4, HIGH); digitalWrite(5, HIGH); digitalWrite(6, HIGH); break; case 3: //Forward case digitalWrite(2, HIGH); //Wheelchair was already driving forward and then adjusted. Do not re-pulse, just drive all pins high digitalWrite(3, HIGH); digitalWrite(4, HIGH); digitalWrite(5, HIGH); digitalWrite(6, HIGH); break; case 4: //Accelerate reverse case digitalWrite(2, HIGH); digitalWrite(4, HIGH); digitalWrite(5, HIGH); digitalWrite(6, HIGH); pulse(3, per2, &pulsecount, 15); if (reverse_count >= 10 & per2 >= 50) { per2-=10;

22

reverse_count = 0; Serial.print("Period 2:"); Serial.print(per2); Serial.println(); } reverse_count++; break; case 5: //Reverse case digitalWrite(2, HIGH); digitalWrite(4, HIGH); digitalWrite(5, HIGH); digitalWrite(6, HIGH); pulse(3, per2, &pulsecount, 20); break; case 7: //Turning left case digitalWrite(2, HIGH); digitalWrite(3, HIGH); digitalWrite(4, LOW); digitalWrite(5, HIGH); digitalWrite(6, HIGH); break; case 6: //Turning right case digitalWrite(2, HIGH); digitalWrite(3, HIGH); digitalWrite(4, HIGH); digitalWrite(5, LOW); digitalWrite(6, HIGH); break; } // Serial.print(buf[i]);Serial.print("\t"); } Serial.println(); //delay(1000); } } //pulse function to send pulses to reach a certain speed when moving forwards/backwards void pulse(int pin, int per, int* pulsecount, int dc){ if (inc) { *pulsecount++; Serial.print(*pulsecount); Serial.print("\t"); digitalWrite(pin, LOW); if (*pulsecount >= per * dc / 100) { Serial.print("Toggle inc to false"); inc = false; *pulsecount = *pulsecount * (100-dc) / 100; } } else { *pulsecount--; digitalWrite(pin, HIGH); if(*pulsecount <= 0) { Serial.println("Toggle inc to true");

23

inc = true; } } } /********************************************************************************************************* END FILE *********************************************************************************************************/

Appendix B. Research on DX-5SW Five-Way Controller from Dynamic Controls Background

· No useful documentation was found

· Tested to determine 5 way controller responses

Commands and Wheelchair Behaviors

· Left and right :

o Constant signal sent, wheelchair turns at constant rate

· Forward: give constant or pulsed signal until desired speed is reached, then stop sending command

o Signal latches

o There is some noticeable latency, so pulses may be more desirable

o If more forward commands are sent while wheelchair is already in motion, it accelerates further until forward commands cease

o If a Left or Right command is sent when wheelchair is going forward, the wheelchair will turn/adjust course, and resume going forward at previous rate when Left or Right command ends

· Backward: use pulses to drive wheelchair in reverse

o Constant signal drives wheelchair backward but only very slowly, no acceleration

o Frequency of pulses determines wheelchair speed

o An increasing frequency of pulses will increase the reverse speed

o If wheelchair needs to adjust right or left, send Right or Left command, then resume pulsing

o Considerable latency (similar to forward)

· Brake: stops wheelchair

24

o Very little/unnoticeable latency

o Causes forward command to de-latch (only need to press brake once, then when you release the wheelchair remains still)

25

Appendix C. Fall 2014 VIP Secure Hardware Wheelchair Team Final Report

Robotic Wheelchair Central Computer – Collaboration of Hardware Security Research and Robosense VIP Teams

Wesley Schon Georgia Institute of Technology Vertically Integrated Projects Secure Hardware Team 04 December, 2014

26

Introduction

This paper details the hardware and software specifications for the central

computer of an ongoing project to produce an autonomous wheelchair. Information will

be included on the project background, goals, construction of the computer, the

interfacing of the computer with peripherals, compilation/installation of specific drivers,

the operating system, and nuances of communicating with the wheelchair motors.

Background

At the start of this phase of the project, a number of hardware items had already

been obtained, including a Micro-ATX Intel motherboard, Intel Core i3 processor, stock

fan, and a separate CPU fan, two 8GH DDR3 DIMMs (Dual Inline Memory Modules), A

Samsung 250 GB SDD, a 500W ATX 5V desktop power supply, and a 250W output, 6V

to 30V wide input DC-DC car PC power supply. For the CAN communication, CAN

hardware from PEAK Systems had been purchased to interface with both the USB and

PCI ports on the motherboard. In addition, 9-wire cable, resistors, 9-pin shields,

clamps, two Arduino Uno microprocessors, and two Seeed CAN shields for Arduino

were provided. The software platform, Linux Ubuntu 14.0x and ROS Indigo had been

decided upon, as well as the overall architecture, shown in Figure 1. Over the course of

27

the semester, I worked closely with Dan Pettinger, another VIP Hardware Security

Team member this semester. His report more closely covers certain aspects of the

project, such as CAN protocols and Arudino programming.

Goals

This project had several goals. The overall project goal for the Robosense

Wheelchair team is to produce an autonomous robotic wheelchair which makes

decisions based on people that it detects using computer vision, their position, and their

actions. The goal of the central computer team was to build a computer to serve as the

main control system for this robot, to obtain and build the necessary software platform

for this computer, and to facilitate its ability to communicate with other parts of the robot.

The overall current target architecture for this robot is shown in Figure 1. Side goals for

this project included the design, construction, and testing of a physical CAN bus, and

the analysis of the wheelchair’s motor control system.

Figure 1. Target architecture for robotic wheelchair. Completed parts are shown in blue, incomplete parts in yellow, and future goals in red.

Computer Hardware Installation

When constructing a computer, it is important to touch grounded items often to

dissipate any static charge accumulated on the body often to avoid damaging fragile

components. We started with the micro-ATX motherboard, keeping it elevated throughout the

process on the anti-static wrap in which it was originally packaged. We first installed the CPU.

The CPU cover is located near the middle of the board. It can be lifted by unhinging the metal

28

lever on the side and lifting that. The protective plastic that comes with the motherboard can

be snapped out easily, and can be stored away (or discarded). While handling the processor,

touch only the sides. The pins and notches on the processor must be lined up with those in the

shallow processor bay on the motherboard, and the processor should be placed into the bay

gently. The CPU cover is swung back over the processor and locked into place by pushing the

metal lever back down and into its original place (this may take a little bit of force). Next, the

CPU fan with thermal paste can be placed directly over the CPU and locked in place by pushing

the pins on each corner of the fan down through their respective holes on the motherboard. The

wires from this fan can go directly into the motherboard’s fan header. On this motherboard we

used the SYS-FAN header nearest the CPU. The motherboard manual provides details for all the

necessary SATA connections. Next, we installed the RAM. There are four RAM ports on the

motherboard and we used ports 1 and 3. Each stick of RAM needs only to be lined up along the

port and inserted. Clamps on either end of the port are then closed to hold the RAM in place.

For the desktop power supply and the hard drive, we plugged the cables from each into the

necessary motherboard headers as directed in the motherboard manual. All extra cables from

the power supply were bundled using twisty-ties to keep the workspace organized.

After the computer had been constructed, it was turned on by briefly placing a

screwdriver between the two power pins on the F_PANEL header on the motherboard. This

shorts the pins the same way pressing a power button would. The computer powered on

successfully, and Linux Ubuntu was installed from a bootable USB stick. The setup at the time

had two drawbacks. First, keeping a screwdriver on-hand to short the F_PANEL pins to power

29

the computer was impractical. Second, the exposed parts and wires presented a security risk,

because it would be easy for anyone in the area to inadvertently damage the components. A

picture of the computer before mounting in the case is shown in Figure 2. For these reasons, we

purchased a mini-tower case to contain all the components. The motherboard screwed into a

platform in the case at several points that also served to ground the board. Later on, when the

CAN bus was being set up and tested, a PCI-CAN card was installed into the PCI slot on the

motherboard facing the back panel of the tower case.

Figure 2. Central Computer before installation into tower case.

Interfacing Central Computer with Peripherals

In order for the central computer to communicate quickly and robustly with

various peripherals (e.g. motor control and odometry) a CAN (Controller Area Network)

bus has been implemented. Two different interfaces have been attached and tested

with the central computer, namely USB-CAN and a PCI-CAN. Compilation of the

drivers for this hardware is covered in the section Compilation of PCAN Drivers . On

the peripheral side, Arduino UNO microcontrollers using CAN shields from Seeed

Studio serve as interpreters which read CAN messages and communicate directly with

peripherals. The wheelchair also has its own proprietary CAN bus, which connects

directly to a 5-way controller. This controller can be communicated with via an Arduino

UNO, as is explained in the section Driving the Motors of the Wheelchair .

Controller Area Network (CAN) Bus

30

The physical CAN bus consists of a 9-wire cable terminated at each end by a

resistance equal to the characteristic impedance of the cable. At each node, a female

9-pin shield with conductive metal teeth bites down on the cable, allowing any interface

with a 9-pin serial male connector to access the bus. Standardization of CAN-High and

CAN-Low signals is accomplished in the current setup using two 9-pin shields between

the bus line and central computer, and connecting wires from pin 3 on the bus-side to

pin 7 on the computer-side, and pin 5 on the bus-side to pin 2 on the computer-side.

This is shown in Figure 3.

Figure 3. CAN shields shifting the bus pins to the USB-CAN pins. An additional wire

carries GND.

Operating System

The installation of the Linux Ubuntu operating system and ROS are both very

straightforward. In this case, we used Linux Ubuntu 14.04.1 LTS and ROS Indigo. In

order to install Ubuntu, the computer must be booted from a bootable USB drive

containing Ubuntu from the BIOS (the only accessible part of the system without an

operating system). After that, it is sufficient to follow the on-screen prompts. Once

Ubuntu has been installed, ROS can be installed. Ros.org provides a step-by-step

guide for doing this, which is what we used in this project. An internet connection is

required to install ROS. Root permissions are useful to perform these installation steps

but not necessary unless otherwise indicated in the guide (for example, while setting up

repositories). This can be gained by running “ sudo su ” or “ sudo su root ” from the

command line and entering the system password. If root access is not desired, the

31

“ sudo ” prefix to a command allows for commands to be run as root, and requires the

system password to be entered.

Compilation of PCAN Drivers

PCAN (PEAK-CAN) driver installation is necessary to get the CAN hardware

discussed in Interfacing Central Computer with Peripherals working. A .tar file

containing all of the necessary files can be found on the PEAK-Systems website. After

this folder has been downloaded from the website or imported from another system via

USB drive, email, CD, or any other method, the drivers can be installed with or without

an internet connection. It is important to note that there exist two separate versions of

the driver, called chardev and netdev. The netdev version interfaces with the kernel via

a so-called Socket-CAN framework, and will not work properly with our setup for

unknown reasons, causing issues with the system’s ability to receive messages. The

first line of the instructions in Figure 4 ensures that the chardev interface is used, rather

than the netdev. Depending on the system, an error message may be thrown during

the installation stating that “ popt.h could not be found .” If this occurs, it is

necessary to get popt.h for your system before proceeding. This is accomplished by

running “ apt-get install popt ” from the command line as the root user. The

following Figure details the steps necessary to install the drivers.

Figure 3. Installation of the PCAN drivers with chardev interface

After the driver package has been installed, it is necessary to test it. The

package contains drivers for both PCI and USB CAN adapters. In order to test, a

32

Windows laptop and Arduino UNO with a CAN shield works very well. Using the CAN

software already available for use with Arduino UNO, messages can be sent and

received by the Windows laptop without difficulty. In the Linux system, there are two

functions called transmitest and receivetest that can be used to test proper installation,

located in a subdirectory of the installation files taken from the PEAK-Systems website.

By navigating to that subdirectory, the tests can be run. If the Arduino is sending a

message, reception on the Linux system can be tested by running “ receivetest

f=/dev/pcan32. ” If the Arduino is receiving messages, transmission can be tested by

running “ transmitest hello.txt f=/dev/pcan32. ” A .txt file called “hello.txt” is

located in the same directory and contains a standard CAN message that can be

altered. The pcan32 can also be changed to another device if necessary; here, it

represents the USB-PCAN hardware. A list of all available CAN devices can be seen

by running “ cat /proc/pcan ” from the command line, and “ ls –l /dev/pcan* ” lists

all the device nodes.

Driving the Motors of the Wheelchair

The wheelchair’s motors are connected directly to a 5-way controller via a

proprietary CAN bus. This 5-way controller can be controlled by placing a shield over

the serial port and routing wires to it from an Arduino UNO. Pins 1-5 coming from the

controller can be connected to pins 2-6 on the UNO. Other pin configurations may work

if needed, but changes to the current Arduino code would need to be made. The 5-way

controller has five input pins that stay at +5V. In order to “activate” these pins, thus

causing the 5-way controller to drive the motors, the pins must be grounded. This has

33

been accomplished by having the Arduino drive its pins connected to the 5-way

controller pins to LOW. The Arduino has also been set to reference the controller’s

GND.

Initially, the Arduino used inputs from a joystick and relayed them to its own outputs to

the controller in order to drive the wheelchair. We set this up first to allow us to

troubleshoot problems on the controller side without having to worry about CAN errors.

After this was accomplished, the Arduino was connected to a Windows laptop over CAN

and would interpret the incoming CAN signals to drive the controller, and thus, the

wheelchair. A diagram of the setup, including the CAN signals sent from the laptop to the

Arduino, is shown in Figure 5. Some irregularities have been found with the way the

5-way controller drives the motors, and in general, the 5-way controller has worked

inconsistently. The signals coming from the Arduino need to account for these

nuances and should be fine-tuned for the system. The signals going to the 5-way

controller on pins 1-5 correspond to Forward, Reverse, Left, Right, and Brake

respectively. These pins receive signals from pins 2-6 on the Arduino, in that same

order.

Figure 5. Driving the wheelchair over CAN. The joystick was a preliminary setup, the PC a

future goal.

Future Work

Currently, the wheelchair has only been driven over CAN using a windows

laptop. The system consisting of the Arduino UNO and 5-way controller is certainly

adaptable to be used with Linux Ubuntu. The current implementation of CAN on Ubuntu

34

only allows for reception or transmission using the receivetest and transmitest programs

included in the installation of the CAN drivers. This means that the commands being

sent from the computer cannot be quickly changed; it is necessary to edit a text file and

rerun the program in order to change the command. In the future, the computer should

have custom send and receive functions built to be used with the CAN hardware.

These functions can be implemented in a larger program, which will allow for quicker

control on the user’s part. Once this is done, the wheelchair can be driven by the

central computer in the same manner as it has been by the windows laptop. In addition,

the Arduino code controlling the wheelchair’s movement via the 5-way switch can be

refined to provide the user with greater control over the wheelchair’s response. As

more groups associated with the wheelchair project become ready to incorporate their

projects into the greater implementation of the system, it will be necessary to work

closely with them to link their projects with the central computer. This will require the

creation of an addressing system for the CAN bus, as well as the addition of more

nodes to the existing bus. Once more nodes have been added and more data is being

sent over the bus, its ability to correctly arbitrate should be closely monitored and

tested, as to this point arbitration has not been necessary. In addition, size and

efficiency considerations should be made. Ideally, the number of microcontrollers and

wires used should be reduced as much as possible. Multitasking on the

microcontrollers might be necessary if their processing power allows.

35

References

[1] (2002-2007) Peak-System- Technik GmbH and Klaus Hitschler. PCAN-driver for Linux (Online) Available: http://www.peak-system.com/fileadmin/media/linux/files/Installation-en_6.x.pdf [2] (2014) Open Source Robotics Foundation. ROS.org (Online) Available: http://wiki.ros.org/indigo/Installation/Ubuntu [3] (2014) Dan Pettinger (VIP Secure Hardware student from same semester). Report and Presentation. Vertically Integrated Projects, Georgia Institute of Technology. [4] (2014) Wesley Schon. Robosense Central Computer (PowerPoint). Included with this report.

36

Appendix D. Spring 2015 VIP Secure Hardware Wheelchair Team Final Report

Wheelchair Group

Wesley Schon, Cameron Braun, Kendall Davis, Yushan Cai Georgia Institute of Technology Vertically Integrated Projects Secure Hardware Team 17 April, 2015

37

I. Introduction

This paper details progress made on the VIP Secure Hardware/Robosense

wheelchair during the Spring 2015 semester. Background information, goals, progress

made on wheelchair control, ROS, odometry, and potential future work will all be

discussed in detail.

II. Background

At the start of the semester, simultaneous CAN communication had been

established between two Arduino Uno microcontrollers and a central computer built

around a micro-ATX motherboard and Intel Core i3 processor with Ubuntu 14.04 LTS

operating system. The central computer utilizes CAN hardware from Peak-Systems to

connect to the bus via USB or PCI, and the microcontrollers use seeed CAN shields.

The CAN communication was not flexible, as the transmitted CAN messages could not

be easily altered. Using a Windows laptop, Windows software provided by

Peak-Systems, and the USB-CAN adapter, control of the wheelchair’s motors using

CAN signals had already been demonstrated, with some reliability issues. ROS had

been installed on the system as middleware, but had not yet been interfaced with the

CAN drivers. In addition, a shaft encoder for wheelchair odometry had been designed

and prototyped, and an Arduino code with some bugs had been provided by students in

a previous semester. More detailed hardware specifications and more information on

CAN can be found in a report from Fall 2015, titled Robotic Wheelchair Central

38

Computer – Collaboration of Hardware Security Research and Robosense VIP

Teams.

III. Goals

Short-term goals for this project at the start of the semester included debugging

the Arduino code for the shaft encoder, publishing shaft encoder data to the CAN bus,

fixing the reliability issues in the driving system, and interfacing ROS with the PCAN

drivers on the central computer (to allow the computer to send and receive CAN

messages within ROS). Another goal which was conceived later in the semester was to

replicate the work on the central computer into a virtual machine. In the long run, the

wheelchair should be able to drive around on the floor of a building, and to generate a

map using data from shaft encoders (over CAN) and LIDAR (over Ethernet). Figure 1

shows the overall target architecture of the control system.

39

Figure 1. Target architecture of the system. Blue indicates completed work, yellow indicates work in progress, red indicates future work

IIII. Odometry

Odometry is the use of motion sensor data to estimate change in position over

time. The sensors we use are Light-duty Incremental Encoders (Automation Direct part

number TRD-S2500-BD)[5]. These shaft encoders convert the rotational movement of

an axis (in this case, the wheelchair wheels) into a digital signal. The pulses are

communicated over two channels (A and B). The encoder produces 2500 pulses per

revolution per channel, with a maximum response frequency of 200kHz. A rising edge

on channel B indicates clockwise motion, where as a rising edge on channel A indicates

counter-clockwise motion.

Data Acquisition in Shaft Encoder

Channel A is attached to a interrupt line of the

Arduino and channel B is attached to a digital

I/O line. The interrupt routine is triggered on

the rising edges of channel A. The interrupt

routine compares the states of channel B and Figure 2. Visualization of encoder pulses

channel A (which are 90 degrees out of phase)

to determine whether to decrement or increment the counter, as described previously.

Counter values can then be used in conjunction with known values (such as wheel

radius and time intervals) to compute relative position and orientation with the tracking

algorithm. The Arduino board has internal pullup resistors that prevent floating values

on lines.

40

Tracking

A Matlab code was developed to display the position of the wheelchair (relative

to its starting position) on an XY axis. This code takes serial data from the Arudino,

parses it, and plots it. This allowed us to more conveniently see the performance of the

equipment and algorithm in real time, without having to cease testing and plot as a

separate activity. This code also serves the function of auto-saving the serial data,

which previously was a manual process involving copying and pasting into a text

document. The code checks for a serial input once every 10 milliseconds. If no data is

found, then it waits an iteration and checks again. This rate of checking is manageable,

and is fast enough to ensure that all serial data is read (the Arduino outputs serial data

once every 100 milliseconds).

Figure 3. Real time plotting graph in Matlab. Image is not from wheelchair movement, but spinning the

41

shaft encoder.

In each loop of the tracking algorithm, the counter value determined by encoder

pulses are converted to distance covered by the left and right wheels, respectively. The

counters are then reset to zero. Using the below equations, coordinates (x, y) and

direction θ can be computed. This method is outlined in The Rossum Project. [6]

Figure 4. Equations used to calculate position. Implementation on the right. Figure from Lucas, G.W. "A Tutorial and Elementary Trajectory Model." 2000.

Each loop, direction and coordinate data in every loop through its serial port.

Debugging the Tracking Algorithm

A few issues needed to be resolved in the tracking. There was an error in the

tracking algorithm that caused us to receive unexpected XY values. This was due to

using the wheel diameter as opposed to the distance between wheels when updating

the theta value. This has been corrected, but as of the time of writing this document,

has not been tested thoroughly enough to confirm results. Prior to making this

correction, a wrapper function was added to the algorithm that would detect if the

change in X or Y was unexpectedly large (corresponding to speed greater than the

42

wheelchair would realistically experience), and if so, to ignore that data. This wrapper

remains in place, but can be removed or modified as necessary.

There is also an accuracy issue that is due to the inherent limitations of the the

tracking algorithm. The algorithm makes assumptions that are approximately true for

light vehicles that do not undergo much acceleration. However, the wheelchair is quite

heavy, and with a person in it, can easily exceed 200 pounds. Attempting to make better

tracking approximations with some level of acceleration considerations should be

considered in the future.

V. Wheelchair Motor Control

Background information on the method of interfacing with the wheelchair’s

motors can be found in Robotic Wheelchair Central Computer – Collaboration of

Hardware Security Research and Robosense VIP Teams. The previous semester’s

work was considered unreliable because while driving forward the wheelchair would

constantly accelerate and would be unable to brake. The 5-way controller does not

latch all direction commands in the same way. While turning left or right or driving in

reverse, the signal is not latched. While driving forward, the signal is latched until the

emergency brake is applied. It was also found that if a signal on the CAN bus stops

transmitting, and a new signal is not present, the Arduino connecting to the 5-way

controller would continue behaving as if it was still reading the most recent message it

received. Finally, the wiring connecting the Arduino to the 5-way controller was not

correct in the previous semester’s setup. The Arduino would connect to pins 1-5 on the

5-way, with pin 5 corresponding to the emergency brake. However, in a correct setup

43

the Arduino must connect to pins 1-4 and pin 6 on the 5-way, with pin 6 corresponding

to the brake. Combined, these factors created a situation where it seems as if the setup

was correct, except for an issue with the forward motion (because the emergency brake

CAN signal would still cause right, left, or backwards motion to stop, just not for the right

reason). However, the reality was that the emergency brake was never truly being

activated. After these factors were observed and accounted for, reliable control of the

wheelchair via CAN was established. Figure 5 provides a visual representation of this

portion of the system, complete with pin numbers.

Figure 5. Architecture for portion of system responsible for motor control. Green indicates completed work, and gray indicates proprietary portions of the system

VI. CAN Bus Observed Specifications

The minimum cycle time for PCAN hardware is 1ms. Testing validated that at

least 2 Arduinos can be connected and communicate simultaneously with PCAN

hardware at this rate. Additionally, it was found that the PCAN hardware can

simultaneously send at least 6 different CAN messages (using a 1ms cycle time) and

44

still receive Arduino messages. Available baud rates for Arduino include 5, 10, 20, 20,

50, 80, 100, 125, 200, 250, 500, and 1000 kbps. When using a Windows laptop to test

CAN performance or simply to monitor the bus, useful software called “PCAN-View” can

be obtained for free from the PEAK-System website. This software allows multiple

messages to be sent and received from the laptop, and allows messages to be easily

altered. It can be used to monitor the bus in real-time. Figure 6 was obtained using

PCAN-View on a Windows laptop.

Figure 6. CAN bus monitoring example. Most messages displayed were sent from a

Windows laptop using PCAN-View and the PCAN-USB adapter. An Arduino message is observed at time 92.1681s.

45

VII. Interfacing CAN with ROS

In order to perform interesting functions like mapping with the data collected from

the shaft encoder, we needed an interface between the CAN bus and ROS. We used

PCAN-USB adapter to connect central computer to CAN networks. We used built in

driver utilities to test data exchange of the CAN bus with the PC. Once this component

was verified, ROS had to be integrated into the system. To accomplish this, we found a

project on Github that had already written an interface between CAN and ROS

[Care-O-Bot team. Ref 4]. Their implementation included much more features than our

project requires, so we refactored their code to provide a simpler interface to ROS and

improved readability.

Figure 7. Software architecture, showing the interaction of ROS, libpcan, and the

Care-O-Bot code.

46

Virtualization

It was decided towards the end of this semester’s work that it would be prudent

to encapsulate the work of the central computer into a virtual machine. This would

immediately solve the issue of portability, because any laptop could be used as the

central computer for testing purposes. It would also allow team members to work on

more aspects of the project than is currently possible, as the entire software system

could be distributed and taken home. The selected virtual machine for this project is

Nootrix. Nootrix is a Linux virtual machine which comes pre-loaded with ROS, making it

a natural choice for the wheelchair. Detailed instructions for the installation of this

virtual machine are available in Appendix A.

VIII. Future Work

The final goal of this project is to enable the wheelchair to produce a map using

its odometry data and information gathered using LIDAR (which has not yet been

incorporated into the system). LIDAR will supply the computer with data via Ethernet,

rather than CAN, in the current design plan.

There are several pieces of work to be done in the short run. Odometry data

should be converted to fixed point numbers and published to the CAN bus. The data

must be converted into an array of bytes in order to be put on the CAN bus. Once this

data is on the CAN bus, it should be immediately available to ROS. A package to

process the data to perform functions such as mapping needs to be created. The code

47

that serves as an interface between ROS and CAN also needs further refactoring. A

system of data presentation (identification and formatting) for all of the data on the CAN

bus should be conceived and implemented.

Smaller form factors for the central computer should be explored. If possible, a

smaller ATX case should be acquired, as the current one is too large to fit on the back

of the wheelchair. If that is not possible, the team may want to consider a smaller

motherboard, such as mini-ITX.

48

References

1. http://www.peak-system.com/Home.59.0.html?&L=1

2. http://nootrix.com/

3. Robotic Wheelchair Central Computer – Collaboration of Hardware Security

Research and Robosense VIP Teams.

4. Fraunhofer Institute for Manufacturing Engineering and Automation Care-O-Bot

Github:

https://github.com/ipa320/cob_driver/tree/indigo_dev/cob_generic_can/common/i

nclude/cob_generic_can

5. http://www.automationdirect.com/static/specs/encoderld.pdf

6. Lucas, G.W. "A Tutorial and Elementary Trajectory Model." 2000. The Rossum

Project. Web. 22 April 2014.

49

Appendices

Appendix A: Nootrix Virtual Machine

The main desktop in lab is functioning. For future reference, a portable 64 bit VM image

was configured. This is how to obtain it from scratch.

Go to http://nootrix.com/downloads/ and find under section ROS Virtual Machines

rosIndigo64Bits.torrent. If you are using a 32 bit machine, download

rosIndigo32Bits.torrent instead. Then download .ova file from torrent file and import it to

VirtualBox or vmware, etc. I chose VirtualBox because of its popularity. While

downloading .ova file, VirtualBox can be obtained from

https://www.virtualbox.org/wiki/Downloads, selecting the right one for the current

system. Upon installation of VirtualBox, open it and select “File -> Import Appliance” and

open the .ova file that's been already downloaded, untouching any configurations, click

Import. It may take a while. While importing, download Oracle VM VirtualBox Extension

Pack also from the same address and double click the file to import the package. Then

virtual machine with ROS built in should be able to boot. Password is viki. Since

PCAN-USB is used, its driver can be found on

http://www.peak-system.com/fileadmin/media/linux/index.htm. After extracting files to a

50

folder named similar to peak-linux-driver-7.xx, go in the directory and run the following

commands:

make clean && make NET=NO

su -c "make install"

/sbin/modprobe pcan

cd driver && /sbin/insmod pcan.ko

Install ROS package libpcan from terminal using: sudo apt-get install ros-indigo-libpcan.

Download ros_for_can from wiki to catkin_ws/src folder. Under catkin_ws run

catkin_make to build package. To run executable, run rosrun ros_for_can

ros_for_can_write/read in terminal. To further modify ROS package, install vim, sublime

or any IDEs.

51

Appendix E. Fall 2015 VIP Secure Hardware Wheelchair Team Final Report Included with this report

52