3. Content
•Green bars at bottom of slides indicates work done by the
Spring 2016 VIP team
•Orange bars at bottom of slides indicates work done by the
Fall 2015 VIP team
•Blue bars at bottom of slides indicates work done by the
Spring 2015 VIP team
4. Motivation
•This project is intended to create a research platform
•The goal of this project is to create a wheelchair that can map
a floor of the TSRB building, while using CAN bus
•The use of a CAN Bus allows other peripheral devices to be
integrated onto the system
5. Background
• Results from prior research teams:
• LIDAR interfaced to system
• Odometry data from Arduinos interfaced with Central
Computer
• Wheelchair motor control established
• CAN Bus set up
8. Subgroups
• Due to increased size of team, 3 main subgroups were formed
to tackle different issues
• This allowed multiple issues to be tackled at once
• When needed assistance was provided by members in other
subgroups
Odometry
Graham
Jack
Karvin
Driving
Siyan
Wes
Hardware Architecture
Dan
Graham
9. Semester Goals
• Goals:
• Solve odometry issues
• Implement SLAM
• CAN data packet design
• Create more sophisticated motor control system
• Shift CAN Bus control to central computer
10. ROS Topic Overview
• Initial redesign of ROS structure separated every operation,
giving access to any data easy for potential peripherals
11. ROS: Adapting System Layout
• After feedback, we simplified our planned ROS layout to reduce the
number of components
• This entailed combining package 2 and 3 into 1 package, this meant
that a single package would:
• Combine the position data from the odometry topic, and the
environmental data from the LIDAR unit
• Conduct SLAM
• Determine and publish instructions for motor control
12. Adapted ROS Topic Overview
LSE N
RSE N
SE
Topic
LIDAR
Node
LIDAR
Topic
Main
Package
PUB
PUB
SUB
PUB
MC
Topic MC N
SUB
SUB
Left Shaft Encoder
PUB
Right Shaft Encoder
LIDAR
Computer
Motor Controller
13. SLAM and Motor Control
• Once Odometry is implemented, the SLAM package will send
data to move the wheelchair, after conducting SLAM with
Odometry and LIDAR data
14. CAN Bus Implementation
•Libpcan allows central computer to send CAN messages (using
PCAN-USB interface)
•CAN Messages are read by Arduino and corresponding
messages are sent to 5 way motor control
15. Shaft Encoder
● There are two outputs A & B.
● Either outputs send a high
signal when a set of bars on
the internal encoder disk pass
an optical sensor.
● From these two outputs there
are 4 possible states based on
the rising edge.
*** The physical shaft encoders contain ~ 2500 bars on the
encoder disk, may have the A & B sensors in a different location
than indicated above, and the encoder disk may not always move
in the direction indicated by the green arrow
16. Data Acquisition
•The code on the Arduinos is used to
record wheel movement.
•If A outputs a high signal then we look
at output B.
•If B is high then we increase the
encoder count, otherwise we decrease
the encoder count (Encoder count is
used to record the change in encoder
values over a period of time)
17. Issues – Odometry in use-case
•During use-case testing (mounted on wheelchair), odometry
will not accurately track the position of the wheelchair
•When shaft encoders were individually tested at low
velocities the odometry readings would be accurate
•Error was unsolved, but attributed to hardware
•Odometry system was working previously
18. Odometry
• At the beginning of the
semester, it was
established that the
encoders were not being
recorded correctly
• The shaft encoders are
flipped on the wheelchair,
so they should produce
opposite readings
19. Issues: Odometry
• Testing and research suggested that the main
cause of odometry errors was due to hardware
limitations
• In order to ensure the odometry was calculated
accurately, all calculations were moved to the
Central Computer
• This way each arduino would have a lighter
workload, and hence be more accurate in their
readings, leading to more accurate odometry
data
20. Odometry
• Currently, our main focus
is constructing the
Odometry package for
the Central Computer
• Reading both Right and
Left Encoder topics at the
correct times have
proven difficult
21. Wheelchair Movement
•Wheelchair is controlled through 5-way proprietary controller
Controller
(Central Computer, Laptop) CAN Arduino
2 1
3 2
4 3
5 4
6 6
5-Way Controller
Wheelchair Motors Proprietary CAN
bus
22. Motor Control - Problems
• The wheelchair was limited in the motions it could do; its
movements were sharp when instructions/commands were
changed and it was not able to move forward without
accelerating constantly
• The initial implementation of the motor control system would
risk misinterpreting CAN messages intended for
non-motor-control purposes
23. Motor Control - Solutions
• Due to the lack of documentation for the 5 way motor
controller, testing was done to reverse-engineer it
• A new command scheme was drafted
24. New Command Scheme for
Wheelchair (First Attempt)
Control byte identifies
message as motor control
message
25. Motor Control
• Took into account new knowledge of 5 way controller
◦ See Appendix B of accompanying report for detailed
information
• Made use of pulsing to control wheelchair speed and
acceleration in forward and reverse states
• Made use of states to keep track of what wheelchair was doing
before turning
• Middle bits can be used to transmit additional data as needed.
28. Power Management
• The previous semester’s team had to replace a battery, due
to the system architecture – only one of the two 12V
batteries were interfaced with the odometry system
• This semester another battery was depleted, and was not
rechargeable
• It was identified that in order to ensure long term operation
of the wheelchair, a better power management system
must be implemented
29. Power Management
• In order to avoid these issues in the future, a power
distribution system was designed
• This would:
• Provide power to the motors, the odometry system, the
motor control system, the central computer, the LIDAR
unit and any other peripherals
• Drain each battery at an equal rate
31. Power Management
● All wheelchair
electronics are
powered by both
batteries
connected in
series
● Load on batteries
is equal
32. Ethernet Implementation
• Work was done to interface the LIDAR unit to the Central
Computer via Ethernet.
• This communication method would reflect the original target
architecture for the Wheelchair.
• The benefits would be:
• Prevent data collisions
• Expandability through time division multiplexing
• However, the current LIDAR-to-PC connection through a serial
to USB adaptor was done due to ease of use.
33. Mobilize Central Computer
• Mount computer to back of wheelchair with intent of making
wheelchair autonomous
• Mini ITX case was chosen vs. Micro ATX for size practicalities
• Easier to attach due to smaller size
• Two computers allow 2 subgroups to work at once
• A PCAN PCI Express card was installed, to enable CAN
communication with the Central Computer
34. Category Specification
Form factor mini-ITX
Case Dimensions 8.27"x7.83"x9.65"
Processor Cores 4
Processor Base Frequency 2 GHz
Memory size 8 GB
Memory Type DDR3L 1333
Ports
PCIe 2.0, mini-PCIe, SATA3 (2), SATA2 (2), VGA, D-Sub, HDMI,
USB 3.0 (4), USB 2.0 (4), Printer Port, COM Port, 7.1 CH audio
Storage type SSD
Storage capacity 250 GB
Wifi Protocol 802.11b/g/n
Input Voltage 6-30VDC
Max Input Current 25A
Max Output Power 250W
Input Connector M4 screw terminal
Output Connector 24-pin ATX
Central Computer Key Specs
35. Mobilize Central Computer
• New computer fits easily
on wheelchair
• Power supply runs directly
off of wheelchair batteries
• Having two computers on
which to test is more
robust
36. Semester Results
• ROS architecture redesigned
• New driving scheme created
• Odometry function moved onto the central computer
• Construction of new central computer
37. Future Work
• SLAM
• Feedback control of wheelchair motion from within ROS
• Encryption of CAN bus, resistance to tampering
• Research on USB timing errors on central computer
