Autocart Senior Design

8/16/2019 Autocart Senior Design

1/37

Sonoma State University

Department of Engineering Science

AutoCart

Jorge

Inocencio

Chanbora

Uch

Richard

Duong

May 19, 2016

Adviser: Dr. Farid Farahmand

http://projectautocart.wix.com/mysite

Submitted to the Department of Engineering

Science in partial fulfillment of the

requirements for the degree of:

Bachelor of Science in Electrical

Engineering

http://projectautocart.wix.com/mysitehttp://projectautocart.wix.com/mysite


2/37

Abstract

Autonomous vehicle technology is the future of transportation because it willallow the movement of people and goods without the need for human drivers.This will lead to an increase in the speed and transportation of people andgoods. Currently all autonomous vehicles require the use of an expensive arrayof sensors and powerful computers to navigate autonomously. The AutoCartis a golf cart that has been converted into a semi-autonomous vehicle, andwill investigate the possibility of a low-cost semi-autonomous shuttle vehiclethat navigates specific pre-defined routes on a campus. It will use a variety of sensors including a GPS, magnetometer, LIDAR, ultrasonics, etc.

1


3/37


4/37

Contents

1 Introduction 71.1 Literature Review & Existing Patents . . . . . . . . . . . . . . . 71.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.4 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.5 Key Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.6 Marketing Requirements . . . . . . . . . . . . . . . . . . . . . . . 101.7 Engineering Requirements . . . . . . . . . . . . . . . . . . . . . . 10

2 Implementation 11

2.1 Project Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2 Bill Of Materials . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3 Module Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4 Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 System Testing 18

3.1 Build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 Design Process 21

4.1 Hardware Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.1.1 Motion Control . . . . . . . . . . . . . . . . . . . . . . . . 234.1.2 Object Detection . . . . . . . . . . . . . . . . . . . . . . . 234.1.3 Path Tracking . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2 Software Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.2.1 MCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.2.2 Arduino Mega 2560 . . . . . . . . . . . . . . . . . . . . . 24

4.2.3 LabVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5 Survey Responses 28

6 Future Work 28

6.1 Steering System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.2 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.3 Object Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7 Conclusion 30

8 Source Of Funding 30

9 Appendix 33

A Instructions For Use 33

A.1 Turning the AutoCart System ON . . . . . . . . . . . . . . . . . 33A.2 Turning the AutoCart System OFF . . . . . . . . . . . . . . . . . 33

3


5/37

B Motion Control Module 34

B.1 Circuit Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

B.2 C code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

C Power Distribution 36

4


6/37

List of Figures

1 AutoCart System Architecture . . . . . . . . . . . . . . . . . . . 122 Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 Sensor Network Test Plan . . . . . . . . . . . . . . . . . . . . . . 154 GPS Path Tracking System Test Plan . . . . . . . . . . . . . . . 165 Test Setup to Characterize LIDAR and Ultrasonic Sensors . . . . 166 Ultrasonic test results: distance vs distance read . . . . . . . . . 177 LIDAR test results: distance vs distance read . . . . . . . . . . . 178 GPS to Computer Wiring . . . . . . . . . . . . . . . . . . . . . . 189 Raw GPS Data in RealTerm . . . . . . . . . . . . . . . . . . . . 1810 testing results for various system tests . . . . . . . . . . . . . . . 1811 Front View of the Sensor Array . . . . . . . . . . . . . . . . . . . 1912 Field of View of the Sensor Array . . . . . . . . . . . . . . . . . . 2013 Angle of Bumper . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

14 Finished cart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2215 Inside of the finished cart . . . . . . . . . . . . . . . . . . . . . . 2216 Flowchart for MCM implementation code . . . . . . . . . . . . . 2517 Block diagram of how the data is processed . . . . . . . . . . . . 2618 Harversin: Distance between two points . . . . . . . . . . . . . . 2719 Forward Azimuth: Heading between two points . . . . . . . . . . 2720 LabVIEW User Interface . . . . . . . . . . . . . . . . . . . . . . . 2821 Circuit Schematic of the Motion Control Module . . . . . . . . . 3522 Power Distribution and Safety Switches . . . . . . . . . . . . . . 36

5


7/37

List of Tables

1 List of key components . . . . . . . . . . . . . . . . . . . . . . . . 102 Bill of Materials . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 MCM packet format . . . . . . . . . . . . . . . . . . . . . . . . . 344 MCM example packet . . . . . . . . . . . . . . . . . . . . . . . . 34

6


8/37

1 Introduction

A quick mode of transportation is a necessity in a large facility in order forstudents and faculty to move quickly across large areas which are inaccessibleto ordinary vehicle. An autonomous mode of transportation will allow peopleto move very quickly around campus without having knowledge of the campuslayout and will facilitate transportation of materials or equipment around thefacilities.Creating an autonomous system presents many technical challenges such asfinding the right systems to detect people and objects and creating a programto stay on track by controlling the vehicles systems. An autonomous system candrastically reduce the amount of time it takes to traverse large campuses andfacilities, in addition it can move people and equipment without the need for adriver. It can also serve as a way to transport people who are unfamiliar withthe campus such as visiting parents and lecturers. An autonomous system such

as this can showcase the university’s engineering program. Looking at a broaderscope, autonomous vehicle technology can be used to drive through areas thatare too dangerous for humans to drive in, to alleviate truck drivers for hours ata time, and to caravan a group of autonomous vehicles together with only onehuman driver leading the way.

1.1 Literature Review & Existing Patents

The current automobile market has already implemented many automated safetysystems know as Advanced Driver Assist Systems (ADAS). Current ADAS sys-tems include adaptive cruise control, emergency braking systems, lane driftwarnings, adaptive speed control, blind spot detection, self-parking, etc. All of these systems add some level of autonomy to vehicles and are beginning to bewidely adopted by vehicle manufacturers. The two main forms of implementingautonomous functions are sensor based and connectivity based. Sensor based so-lutions use Artificial Intelligence along with cameras, GPS, RADARs, LIDARs,ultrasonic sensors, and inertial measurement units to continuously monitor thevehicles position and surroundings. Connectivity based solutions use Vehicleto Vehicle (V2V) communications to relay traffic, road, and driving conditionsto surrounding vehicles. With this information it is possible for vehicles to beaware of traffic patterns and vehicle behavior in city roads where 360◦views areimpossible or difficult to achieve. The convergence of these two technologies iswhat will enable autonomous vehicle technology [2]. Most current autonomoussystems use sensor based solutions, because of this fully autonomous cars arestill in their infancy and are mostly being designed and tested in universities and

by large companies like Google and Tesla. There is only one fully autonomousvehicle ready for sale on the market, this vehicle is not intended to be used onpublic roads [1].One of the most successful and complex autonomous golf carts is the SMARTgolf cart. This golf cart is the product of Singapore-MIT alliance for Researchand Technology. The SMART cart was designed and built by a team of 19 pro-

7


9/37


10/37

our design because the entire system will run off of the golf carts 36V electricsystem. The size of our system is also of minimal concern. The mechanical

structures needed to control the steering will be the biggest challenge for usbecause of a lack of mechanical engineering skills. Finally, the limited budgetis a large challenge because many of the sensors need for implementation areextremely expensive.

1.3 Methodology

Our team will solve the proposed problem by using GPS waypoints to move thecart through campus, while it is traveling from waypoint to waypoint the cartwill be scanning for objects and calculating to see if a collision is imminent orprobable, if the AutoCart detects an approaching object it will try to gentlysteer away from it or if it cant, it will stop altogether. To do this our cart willuse a GPS receiver, an object detection system, and LabVIEW to perform thecontrols and calculations needed for the semi-autonomous functions. In orderto make our project as affordable as possible we will attempt to use readilyavailable and low price parts.

1.4 Challenges

Challenges that we face with this project is how we can bypass the fail-safes inthe cart without compromising the carts features. Meaning if we remove thefail-safe preventing the cart from moving without a driver in it, the cart willstill be able to be used without a driver. Issues that had been brought up beforewere that there were issues installing the mechanism to apply the brakes of thecart. Another system that needs to be implemented would be manual controls.This would either require the system be installed so that a user could operatethe vehicle without risk of damaging the installed system, or a simple set of electronic controls that would act as emergency overrides. Itd also be ideal tohave the system be small enough as to not take up the space of the drivers seat.The system will be exposed to the elements so a level of weatherproofing willbe required. This means that the system is rugged enough to take some hits,withstand wind, and survive water damage. This system should ideally last aslong as the cart as well. As for cost and installation, those two things will befairly high because the system is invasive and requires some time to prepare.This vehicle will be using GPS so the accuracy of the data we require will befairly important. As GPS can be accurate to within a few feet this should notbe a problem when it comes to its ability to navigate. Though itd be ideal forthis system to have object detection to better improve its accuracy and increase

safety for the passengers and pedestrians. The steering, braking, and acceler-ation also need to be very precise so that it can navigate properly as well asavoid dangerous situations.Finally, the system should not significantly affect the battery life of the golf cart.

9


11/37

1.5 Key Components

The AutoCart system uses the following key components.

Table 1: List of key componentsComponent NameMotion COntrol PCBArduino MegaArduino ShieldFeedback Rod Linear ActuatorsAdafruit Ultimate GPS Breakout - 66 channel w/10 HzHC - SR04 Ultrasonic sensorTriple-axis Magnetometer (Compass) Board - HMC5883LLIDAR-Lite 2 Laser Rangefinder

Stepper Motor

1.6 Marketing Requirements

As a requirement for the project, we had to include 10 marketing requirementwhich would emphasize some of the key aspects of the AutoCart System.

• The AutoCart system should cost under $1000.

• The AutoCart should be app controlled.

• The AutoCart system will be modular.

•

The AutoCart System will not significantly reduce battery life.

• The AutoCart system will be safe for the riders and for pedestrians.

• The AutoCart system will have warnings and lights to alert pedestriansthat it is in use.

• The AutoCart system will be well documented so future students canresume the work.

• The AutoCart will stop if it does not know how to proceed.

• The AutoCart system will be well documented.

• The AutoCart system can be a platform for future Senior Design Projects.

1.7 Engineering Requirements

• The AutoCart will have an emergency kill switch that turns the autocartoff.

10


12/37

• The AutoCart will acquire a GPS signal within 10 seconds of start-up.

• The AutoCart will STOP within 5 seconds of losing GPS connection.

• The AutoCart will not exceed 5 mph during peak pedestrian traffic hours.

• The AutoCart’s steering will be controlled with a PI controller.

• The AutoCart will have a GPS receiver and antenna to find its position.

• The AutoCart system will be dust proof.

• The AutoCart system will be water proof.

• The AutoCart GPS will be accurate to 3 meters.

• The AutoCart will be able to stop within 5 seconds after being commanded

to stop

• The AutoCart will be able to detect moving objects up to 10 ft away usingultrasonic sensors.

2 Implementation

The AutoCart system will be implemented by breaking down the key systemsinto smaller systems. The system is broken down into a motion control module(MCM), an object detection systems, and a GUI and path tracking system. Thedescription of each system is included below.

Motion Control Module

The Motion Control Module (MCM) controls the electric motors and actuatorsthat drive the cart. In particular, it controls the accelerator, the brake, and thesteering. The MCM is commanded by a laptop running Labview. The MCM in-terfaces with the existing electrical system, speed controller, and safety switcheson the cart. In addition to this, the MCM is its own self-contained PCB whichcan be used for other projects in the future. The Motion Control Module isimplemented using a PIC18F14k22.

Object Detection System

The cart will feature three forward facing sensors. There will be two HC-SR04ultrasonic sensors mounted on the left and right of the front of the cart closerto the ground. The third sensor, a LIDAR-Lite 2 laser range finder, will bemounted on the middle of the bumper at the top and will provide a 90 degreesweep. This sensor array will provide data on objects nearby and send a messageto the mcm dictating what course of action to take. These instructions includebraking, decelerating, and turning to avoid any objects in the carts path. Thepurpose of the two low ultrasonic sensors is to cover the area that the LIDARcannot see. The rear and side sensors are not necessary as the cart would not

11


13/37

utilize the reverse function and the side sensors would not make much of a dif-ference. A button will be enclosed with the LIDAR and it will serve as the

starting point for the LIDAR. This means that when the system starts up theLIDAR will sweep into the button and when the button is pressed, the systemwill know that the LIDAR is at its starting position.

GPS and Path Tracking

This GPS Path Tracking system consists of GPS receiver and an magnetome-ter(digital compass). The path of the AutoCart traveling is pre-defined. Dis-tance between current location and the next waypoint is monitored at all times.The compass provides the direction of travel. The outputs include speed, dis-tance to the next waypoint in straight lines, target heading, current heading,and the error in heading. The speed and the decision to make a turn are sentto motion control module.

All of the previous systems have to interface with each other for the AutoCartto function correctly. The different systems communicate via different serialinterfaces. An overall system architecture is shown below.

Figure 1: AutoCart System Architecture

12


14/37

2.1 Project Schedule

Figure 2: Schedule

The schedule above was our projected schedule at the beginning of theproject. Overall we did not meet the schedule very effectively. The mechanicalmodifications time line took a lot longer than expected. The reason for this wasa lack of appropriate tools and equipment in order to make the modifications.The steering in particular took much longer than we initially assumed and wasultimately not successful in implementation. Finally, our projected scheduleallotted four weeks for the inter-module communications. In practice howeverwe successfully completed this part of the project in less than two weeks.

13


15/37

2.2 Bill Of Materials

Table 2: Bill of MaterialsComponent Quantity Unit Price100W DC-to-DC power Supply 1 45.95DC motor Driver H bridge 2 6.88DC motor 1 72.99drive sprocket 1 13.45Roller Chain 1 14.99Chain Links 1 6.99PIC16F877A-E/P 2 5.44H Bridge board 1 6.99compass and accelerometer 1 20.82Arduino Mega 2560 1 45.76

Arduino Mega Shield 1 8.32GPS Antenna 1 12.95SMA to uFL/u.FL/IPX/IPEX RF Adapter Cable 1 3.95LIDAR-Lite 2 Laser Range finder 1 114.89Enclosures 1 30.00TOTAL 410.37

2.3 Module Testing

For proof of concept we developed the following tests.

Motion Control System Test Plan

A PIC18 is used to control 1 DC motors while outputting a PWM Signal.One DC motor is simulating the brake actuator. The second motor will controla DC and the PWM signal will be used to control the accelerator pedal. Thesecond DC motor will simulate the steering control, in addition to this thesteering motor circuit will have a feedback mechanism so the micro-controllerwill know the steering angle of the steering wheel. This will allow for accuratesteering. The test will be considered successful if all 3 outputs can be controlledby sending commands via a serial interface and if the steering angle can becontrolled accurately.Object Detection Test Plan

A PIC18F45k20 will be tested to observe the data coming from an ultrasonicsensor and after testing with one sensor, a second sensor will be introduced andtested to determine how accurately it can place an object within both of the

sensors fields of view. From there more sensors will have to be introduced totest whether or not they can all be active at the same time, or whether or notthere are enough ports to run all the sensors or not. Measuring the batterylevels will also be tested and sent to the LCD screen.

14


16/37

Figure 3: Sensor Network Test Plan

GPS Path Tracking System Test Plan

The components includes 3.3/5V power supply, Arduino Uno R3, GPS re-ceiver, Triple-Axis Magnetometer and and an LCD. The Arduino is connectedto GPS receiver via UART, connected to Magnetometer via I2C, and also con-nected to LCD via I/O ports. As the AutoCart is traveling, the distance fromcurrent location to the next way is monitored at all Time. As soon as it reachesor are getting very very close to the waypoint, the compasss bearing will make adecision whether to make a turn or not. The decision is sent to Motion ControlModule. The speed, current location and heading will be displayed on LCD.

15


17/37

Figure 4: GPS Path Tracking System Test Plan

2.4 Test ResultsObject Detection Test Result

The ultrasonic sensor did not work on the PIC18F45K20, because it requiredadditional power to drive it. The echo pin needed to be stepped down from 5Vto 3.3 V, and the trigger pin needed to be stepped up from 3.3V to 5V. Thedatasheet states that the range for the sensor is between 2 and 400 centime-ters with a 15 degree angle. When transmitting data an 8 MHz crystal wasnecessary as testing has shown that using USART or any other transmissionprotocol will affect the clock speed. After trying all of these adjustments, wewere unable to get the ultrasonic sensors to operate off of the chip. We thenproceeded to try using a PIC16F877A. Further testing and research revealedthat the PIC16F877A was not an ideal component as it did not support serialtransmission, so the use of an Arduino UNO, followed by an Arduino Mega,was needed to be able to process all the data incoming from the two ultrasonicsensors and the LIDAR-Lite 2 laser range finder.

Figure 5: Test Setup to Characterize LIDAR and Ultrasonic Sensors

The results yielded an approximate +10cm off, refer to figure 7, the actualdistance for the LIDAR-Lite 2 laser range finder with a zero degree of drift dueto the LIDAR’s sensing method being a ”single” point of light. The LIDAReasily reads out past 10m, ranged at about 40m, but was not tested beyond

16


18/37


19/37

GPS Test Result: To display GPS coordinates and time on computerComponents: Adafruit Ultimate GPS Breakout - 66 channel w/10 Hz, TTL

Serial-USB Converter, Module, Computer

Figure 8: GPS to Computer Wiring

Realterm-Time(UTC)=07:40:33,Latitude:3825.3849N,Longitude: 12243.3128W

Figure 9: Raw GPS Data in RealTerm

3 System Testing

In order to verify the completion of our engineering requirements we developedand performed the following tests.

Figure 10: testing results for various system tests

18


20/37

3.1 Build

This section describes the design of the three key systems, the Object Detection,the GPS system and the Motion Control.Object Detection

Originally, the sensor array would utilize four HC-SR04 ultrasonic sensors,with two in the front of the cart and two in the back. This setup did not havethe required range to stop in time if an object did show up in the cart’s pathand we do not have a way to switch the cart into reverse automatically. Weremoved the rear sensors and have included a LIDAR-Lite 2 laser range finderto remedy the range issue. Due to the LIDAR’s single point scanning, we placedit on a stepper motor, rotating at 90 degrees, to make up for this. Issues arosewith the stepper motor’s rotation speed being affected by the additional sensors.The motor would rotate at the designated rate when all sensors were triggered,but would rapidly decline in speed when one, or more, of the ultrasonic sensors

went out of range. This problem was due to the ultrasonic sensors having towait for the pulse to return resulting in longer delays depending on the rangeof the object or lack of object. To correct this, we reduced the number of timesthe ultrasonic will pulse to twice every cycle. To ensure the position of theLIDAR without the use of an encoder, we introduced code and a button thatwould be pressed when the system boots up. This is one time run code and willdeactivate as soon as the button is pressed.

Figure 11: Front View of the Sensor Array

19


21/37

Figure 12: Field of View of the Sensor Array

The cart’s bumper is sloped at a very small angle, so the enclosure will needto be crafted/mounted with this small angle in mind.

Figure 13: Angle of Bumper

The enclosure for the ultrasonic sensors will be made of a pre-built junctionbox. Modifications will need to be made to the box in order to allow for thespeakers and wires to come out of the box. The LIDAR enclosure will be made

from a different pre-made box that has a window to allow for the LIDAR toread properly. The only modifications that will need to be made are to securethe motor to the box, these modifications include adding a shelf to create a levelsurface to mount the motor to and a wall to mount the button on.

GPS System

20


22/37

The guidance system of the cart relies on a GPS module for location and acompass module for the cart’s direction. A GPS module is the obvious choice,

over manually writing in directions, for a system like this as it allows for moreaccurate and more reliable instructions. GPS also allows us to program morepaths more easily as well. The compass will also assist in maintaining an accu-rate bearing, ensuring that the cart will reach its proper destination.

Motion Control

The motion control system would control the acceleration, steering, andbraking of the cart. To manage the acceleration, we would use pulse widthmodulation because the accelerator basically served as a variable resistor, vary-ing the amount of voltage that would be allowed through when the pedal isdepressed. The steering was originally going to be controlled by a stepper mo-tor or a servo, but was changed to a DC motor because acquiring a stepperor servo strong enough to turn our wheel would have been beyond our bud-get. The DC motor is attached to a chain to provide more torque allowing ourweaker, more affordable motor to turn the wheel. The DC motor and chainare mounted on the dashboard of the cart, with the chain being mounted un-derneath the steering wheel, allowing for the user to assume manual controlif necessary. The brake will be handled my a linear actuator pushing on theshaft that has replaced the brake pedal. The reasoning for the shaft is becausethe actuator could not supply enough force alone to initiate the brakes. Theaddition of the shaft also allows for the user to manually apply the brakes aswell. The actuator is attached to the underside of the dashboard of the cart andretracts to apply the brakes. A bracket has been mounted to the actuator sothat the user can apply the brakes without worrying about the actuator’s shaftpreventing braking.

4 Design Process

The following section describes our build process and our design choices andtrade offs in the project.

21


23/37

Figure 14: Finished cart

Figure 15: Inside of the finished cart

22


24/37

4.1 Hardware Design

Due to the large nature of the design, a description of the hardware used toimplement each of individual systems is included below.

4.1.1 Motion Control

The MCM is its own self-contained module on its own PCB. It is implementedusing a PIC18F14k22. The MCM also includes: a 5 volt regulator used to stepthe 12 volts in into 5 volts. A PWM to DC filter which is implemented usingtwo MOSFETs and a filter. An H-bridge which is used to control the brakingactuator. And one UART serial line in.A more in depth description is available in the appendix as well as in the projectCD.

4.1.2 Object Detection

LIDAR

The LIDAR-Lite 2 laser rangefinder was the obvious choice for sensors as thissensor type is popular with current autonomous systems and this specific com-ponent is popular with hobby drones. The characteristics that make this sensorideal are its reliability and its quickness of scanning the sensor’s described area.Our sensor was single point and capable of reaching out up to 40 meters andbecause it uses light to determine distance, it can receive this data extremelyquickly, much faster than the HC-SR04 ultrasonic sensors which can take overone full second to receive the return signal. To make up for the single pointscanning, the sensor was mounted onto a stepper motor and swept at a ninetydegree angle. To act as a starting point a button was installed and must be

pressed by the sweeping sensor before it begins scanning the area. Its repetitionrate is between 1-500 Hz. This sensor also could be powered by the ArduinoMega because it only requires 5 volts and approximately 100 mA to operate. Italso has two interfaces to read distance, I2C and PWM.

Ultrasonic Sensor

We used HC-SR04 ultrasonic sensors as a type of fail safe for the LIDAR as it isnot always looking forward. To make up for this we placed two ultrasonic sen-sors, one on the left and one on the right of the front of the cart, to ensure thatany object in front of the cart while the LIDAR is looking away will be caught.Due to the ultrasonic sensors relying on sound waves for distance measurementits range is much shorter, at approximately 4 meters, due to wave attenuation.

This also results in a much longer return time, making this sensor fall short asthe main sensor, but making it suitable for a secondary sensor due to their lowcost. These sensors can also be powered off of the Arduino Mega because theyrequire 5 volts and about 15 mA to power. This sensor operates at 40 Hz andworks by sending out a 10 microsecond pulse and records the time it takes to

23


25/37


26/37

Figure 16: Flowchart for MCM implementation code

(latitude,longitude,speed,current heading,lidar’s angle, li-

dar’s distance, ultrasonic’s distance1, ultrasonic ’s dis-

tance2)

4.2.3 LabVIEW

OverviewLabVIEW (short for Laboratory Virtual Instrument Engineering Workbench)is a system-design platform and development environment for a visual program-ming language from National Instruments. It is used for processing because itis a user-friendly program that is able to interact with external serial devices

25


27/37

such as Arduino board [12]. The parallel programing allows multitasking pro-cess which is need in this project. The LabVIEW that we use is version 2014

Service Pack 1 with Visa driver installed in order to communicate through USBport.

Data Processing

When the data is coming in the USB port, LabVIEW reads buffer one byteat a time and translate them into an array of numbers. Each index representseach data from each sensor. These data is then displayed and plotted on graphsfor visualization.The unique feature about labView is that it can understand Cscript or Matlab script using script function [13]. In this case, we use C scriptand haversin formula to calculate distance to waypoint and its bearing usingour predefined waypoint and GPS location. Figure 17 shows the block diagramof data processing.

Figure 17: Block diagram of how the data is processed

Formulae

In navigation world, Haversine formula is very useful for finding the geographicdistance between the two locations on Earth. The assumption of using thisformula is that the Earth is a perfect sphere, but since it it not, the result maybe off a little bit[14]. Given the earth radius of approximately 6,371 km, thedistance between the two points (lat1,lon1) and (lat2,lon2) can be calculated asshown in Figure 18.Since the two points is measuring in a straight line, the heading between thesetwo points can be calculated using a formula known as Forward Azimuth.Azimuthis the angle a line makes with a meridian, measured clockwise from north[15].The formula is shown in Figure 19.

Features

Figure 20 is a screenshot of the LabVIEW front panel that is being used as ouruser interface.

• A user can select a predefined waypoint from a dropdown menu and itslocation will be displayed in longitude and latitude

26


28/37

Figure 18: Harversin: Distance between two points

Figure 19: Forward Azimuth: Heading between two points

• Data visualization: Current time and date, speedometer, distance to way-point, heading, live path tracking plot, live object detection plot

• LED indicating the incoming data from Arduino

• LEDs for lidar and ultrasonic sensors indicating detected objects

•

Manual Remote Control Mode using a keyboard• Autonomous Mode

Autonomous Mode

The unique feature of this user interface is the ability to switch between manualmode to autonomous mode at all time with ease using a shortcut keyboardbutton ’esc’ that we implemented. While in autonomous mode, the cart willmove forward at a medium speed. The cart will only stop under three followingconditions:

• when the cart is within 3 meters radius of the waypoint OR

•

when an object is detected by a lidar within 5 meters at angles +/-20degrees from the center OR

• when ultrasonic sensors detect an object within 3m at a lower level

Another unique feature is that when the cart stops during autonomous mode, itwill automatically switch to manual mode and the cart will remain still, waiting

27


29/37

Figure 20: LabVIEW User Interface

for a user input. The user can either switch back to autonomous mode or controla cart using a keyboard in manual mode.

5 Survey Responses

The survey was done on hard copies.There were 10 people taking part in the

survey on Autonomous Golf Cart project. Eight out of ten were students andfaculties from SSU. The others were random people from outside the school. 80%of the people have heard of a similar product out there in the market, while 20%who were not on campus, have never heard of it before. Majority thought thatthis device would be beneficial to the society, but 50/50 showed interest in thisproject. 30% would pay less than $500, 40% would pay in the range of $500-$1000 and the other 30% would pay in the range of $1000-$2500. 70% wouldpurchase this or similar device for their workplace/campus. Majority wouldthink that this device would ideally range in more than 1 km. Some suggestionsto improve this device would be: GPS, speedometer, cellphone interface, solarpower, object detection, and voice activated. We thought the overall responseswere good and they had given us a green light to work on this project especiallywhen majority would purchase this device for their campuses.

6 Future Work

The AutoCart system was a massive project that required lots of time andfunding. We have left the project in a state where future work could be done

28


30/37

by students from various fields and disciplines. We have identified 3 key areaswhere the AutoCart could be improved: Steering System, User Interface, and

Object Detection. In addition to identifying these areas we have also created abasic implementation plan.

6.1 Steering System

The steering system should be implemented using a 12-36 VDC electric motorand a gearing system which could provide at least 15 ft-lb’s of force. Such a highamount of torque is required because the cart does not have a assisted steering.In addition, the steering has to allow the user to take control at any time,this requirement makes wormgear type motors unsuitable for this application.Finally because of the lack of assisted steering, the system should NOT steerwhen it is not in motion. Our research has shown that a stepper motor wouldbe ideal for the system. Controlling the motor will require the use a closedloop control system which could be used to control the speed of rotation andthe steering angle. To accomplish this, a rotary encoder or some other form of feedback must be used. Finally, the steering has to have a way to disengage, if a stepper motor is used, this can be accomplished by simply turning the powerOFF.

6.2 User Interface

The LabVIEW interface can be improved by adding a feature such as live video.It can be done using a USB camera connected to the computer. By using VisionAcquisition software in LabVIEW, a user is able to see the front view of thecart on the computer screen. In addition, any useful data on the screen canbe deployed to the web server given the computer is connected to the internet.Using Data Dashboard App (currently available in iTunes and Google PlayStore) and the computers IP address, you can create a custom dashboards todisplay the live data and deployed LabVIEW Web services on indicators, suchas charts, gauges, textboxes, LEDS and such. This would be convenient forsharing data with other people without the need to be at the cart. For manualcontrol mode, we can add an external USB device such as a joystick (recognizedby LabVIEW) to control the cart instead of using a keyboard. It makes a userfeel like controlling an RC cart. Turn Left/Turn Right buttons could also beadded to the user interface to give a full control of the carts navigation.

6.3 Object Detection

The current object detection system can be improved by either providing thesystem its own processor, a faster processor, or by replacing the arduino megawith something that can handle multi-process. Any of these changes would in-crease the rate at which the stepper motor moves allowing for less objects to getby the LIDAR as it sweeps and increase the number of scans we can perform persweep; with the increase in number of reads per sweep we also get a smoother

29


31/37

sweep from the motor potentially resulting in a reduction in false positives. Asof now the stepper motor moves slowly because the system is waiting for multi-

ple processes to complete before it can make the next step. It has to retrieve theGPS data, compass data, and LIDAR data each step and because the GPS andcompass take a bit of time to receive it severely reduces the speed the motorcan sweep.

The system could also be improved by replacing the sensors with better moreaccurate sensors. There are LIDARs that can cover a larger area and couldremove the need for the ultrasonic sensors. Other options involve replacingthe ultrasonic sensors with more LIDAR, or using an xbox kinect for objectdetection. Along with optimizing the front sensors, side and rear sensors wouldalso be required as the cart reaches autonomous function.

7 Conclusion

The AutoCart was a very ambitious project which was restrained and sloweddown by a lack of funding and time. In spite of this however, we met over 90%of our engineering requirements. Unfortunately the engineering requirementwe failed to achieve was the automated steering. As of now the AutoCart onlyautomates the braking and acceleration. The future work for this project is veryexciting as we have at least successfully laid down the necessary groundwork fora a future project.

8 Source Of Funding

Our project proposal was selected to receive a funding of $750 from SOURCEaward of Sonoma State University. This amount of reward will be spent wiselyon electrical components and necessities for our project. We, as a group, wouldlike to thanks SOURCE award and its committees for the generous support tohelp our project moving forward to accomplish the goal. I hope to see SOURCEaward being giving. to students future projects.

30


32/37


33/37

[15] mathworks.com (2016). Directions and Areas on theSphere and Spheroid. Retrieved 18 May 2016, from

http://www.mathworks.com/help/map/directions-and-areas-on-the-sphere-and-spheroid.html

32


34/37


35/37

B Motion Control Module

The motion control module controls the controls of the AutoCart. The MCMis controlled via a 9600 baud serial connection. The module accepts a 6 Bytewide packet which is formatted in the following way.

Table 3: MCM packet formatContent Start of Packet Acceleration Brake Steering End of PacketLength in Bytes 1 1 1 2 1

Start of Frame: Start of Packet character0x24: ’$’ this symbol denotes the start of a packet

Acceleration: Acceleration control

0x00: Stop/no acceleration0x0F: Slowest possible speed0xF0: Medium speed0xFF: Full speed

Brake: Brake control0xXX: Brake OFF0xFF: Brake ON

Steering: Steering Control0x00FF: Turn Left0xFF00: Turn Right0x0000: Hold position

End of Packet: End of Frame Character0x23: ’#’ this symbol denotes the end of the frame

Example packet:

Table 4: MCM example packet0x24 0xFF 0x00 0xFF00 0x23

This packet commands the module to full speed, brake off, and turn left.

34


36/37

B.1 Circuit Schematic

Figure 21: Circuit Schematic of the Motion Control Module

35


37/37

B.2 C code

The Code for the MCM implements a Finite State Machine (FSM), to runthrough the controls of the cart. the MCM is controlled via a serial UARTconnection running at 9600 Baud. In addition to being serially controlled, theMCM can be controlled through a GUI in Labview. Only a code flowchart is in-cluded here, for the actual code refer to the website or to the documentation CD.

C Power Distribution

The existing golf cart uses 6 6V lead-acid batteries in series to create a 36Vsource. These batteries are then tapped at 24V to create a 12V source for thelights and horn because of this, the chassis is ”grounded” at 24V with respectto the batteries. The golf cart had two safety switches installed one was apressure switch underneath the drivers seat that opened if no one was sittingin the seat, this safety mechanism had to be removed for our system. Theother safety mechanism is a microswitch installed in the acceleration pedal, thisswitch unlocks the electric motor when the accelerator is slightly depressed.To overcome this issue we installed a SPDT switch which could bypass themicroswitch as needed.

Figure 22: Power Distribution and Safety Switches

36

Date post:	06-Jul-2018
Category:	Documents
Upload:	richard-duong
View:	214 times
Download:	0 times

Autocart Senior Design

Documents