VIP - Wheelchair Project Final Report

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(6, LOW);
fwd = false;
rev = false;
break;
case 2: //Accelerate forward case
fwd = true;
rev = false;
pulse(2, per1, &pulsecount, 20); //20% duty cycle
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
break;
case 4: //Accelerate reverse case
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
pulse(3, per2, &pulsecount, 20);
break;
case 7: //Turning left case
break;
case 6: //Turning right case
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

VIP - Wheelchair Project Final Report

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (18)

Semelhante a VIP - Wheelchair Project Final Report

Semelhante a VIP - Wheelchair Project Final Report (20)

VIP - Wheelchair Project Final Report