A proposal of a generic Matlab-Arduino interface for use in the AGV lab - Een voorstel voor een generieke Matlab-Arduino interface voor het AGV lab

(1)

Delft University of Technology

FACULTY MECHANICAL, MARITIME AND MATERIALS ENGINEERING

Department Marine and Transport Technology Mekelweg 2 2628 CD Delft the Netherlands Phone +31 (0)15-2782889 Fax +31 (0)15-2781397 www.mtt.tudelft.nl

This report consists of 92 pages and 6 appendices. It may only be reproduced literally and as a whole. For commercial purposes only with written authorization of Delft University of Technology. Requests for consult are only taken into consideration under the condition that the applicant denies all legal rights on liabilities concerning the contents of the advice.

Specialization: Transport Engineering and Logistics Report number: 2014.TEL.7895

Title: A proposal of a generic Matlab-Arduino interface for use in the AGV lab

Author: M.L. van Blijswijk

Title Een voorstel voor een generieke Matlab-Arduino interface voor het AGV lab

Assignment: Research assignment Confidential: no

Supervisor: dr. R.R. Negenborn

(2)

Delft University of Technology

FACULTY OF MECHANICAL, MARITIME AND MATERIALS ENGINEERING

Department of Marine and Transport Technology Mekelweg 2 2628 CD Delft the Netherlands Phone +31 (0)15-2782889 Fax +31 (0)15-2781397 www.mtt.tudelft.nl

Student: Assignment type: Research

Supervisor (TUD): Dr. R.R. Negenborn Creditpoints (EC): 15 Specialization: TEL

Report number: 2014.TEL.7895 Confidential: No

Subject: A proposal of a generic Matlab-Arduino interface for use in the AGV lab Overall project goal: Inventing and developing a new type

of amphibian transport system, that will provide seamless transport over both water and land, and that will enable large numbers of fully autonomous transport vehicles to operate together with large numbers of human controlled vehicles.

!

Societal relevance

Roads are becoming increasingly crowded and congested. To prevent transport delays from becoming excessive due

to the increasing amount of cargo to be transported, alternative ways of transporting goods have to be invented. Waterways still have some transport capacity available; transport over water can, however, not reach every final destination: the last kilometers often have to be traversed over roads. An unwanted switch then has to be made, causing a disruptive event in the transport process when cargo has to be moved from one type of vehicle into another at expensive cargo transfer terminals.

We propose to stimulate the common investigation into the design of a new transport system that does not suffer from these drawbacks. A transport system consisting of a large number of controlled hovercraft-like transport vehicles, which can (semi-) autonomously in coordination with one another, and in symbiosis with existing human controlled transport, efficiently transport cargo. Such transport vehicles have the advantages of being highly adaptable, cost effective, and environmentally friendly. Moreover, the real-time and (semi-) automatic control of the different vehicles will provide the means to maintain a desired level of safety and service, and to make the best use of the available capacity. The control schemes will be designed for efficient interaction with humans and human operated vehicles, as those are and will stay omnipresent.

Assignment

This research assignment contributes to the recently approved project “Amphibian”. A model will be produced to control and monitor vehicles wirelessly. This assignment will answer the following research questions upon completion:

• How can a generic Matlab-Arduino interface for wireless monitoring and control of a vehicle be best implemented?

• What are different methods of wireless communication between Matlab and Arduino and which would be best suited for use?

• What kind of protocol should be used for the communication between Matlab and Arduino? • What would be a basic strategy for control of a hovercraft?

• What are the boundary conditions and limitations of the program?

(3)

Preface

This research has been carried out as part of the curriculum of the master Transportation Engineering and Logistics. It took place between November 2014 and January 2015 by Maarten van Blijswijk at the Faculty of Mechani-cal, Maritime and Materials Engineering of the Technical University of Delft. I would like to thank my supervisors and all other people that have helped me during the process of the research. Without their help the result would not be the same.

All the program files described in this report will be placed in a Drop-box folder that is accessible for staff and students that perform research in the AGV lab. For more information about permission to this folder M.B. Duinkerken can be contacted. Videos made of the models during different test runs are available as well.

(4)

(5)

Abstract

A solution to the challenge to combine the transport over land and water is given in the project ”Amphibian”. A hovercraft-type vehicle can be used for the last kilometres of transport. This report contributes to this project by taking the first steps in the model set-up of a hovercraft in the AGV lab. In the AGV lab multiple vehicles are tested in a controlled environment. All these vehicles are equipped with an Arduino board to send commands to the actuators on the vehicle. The Arduino platform cannot be easily adjusted to new test settings. This can be easily done when the control tasks are taken from the Arduino and are place into Matlab. The goal of this research is to propose a solution for this challenge and by doing so formulate an answer to the following question:

How can a generic Matlab-Arduino interface for wireless monitor-ing and control of a vehicle be best implemented?

The setting in which the interface has to operate has been evaluated together with the hardware options. The main tasks and functions of the interface were evaluated to come to the requirements and basic structure. These two have led to the lay-out of the Matlab and Arduino programs. Following this the interface was put through its paces using different test scenarios, in which the requirements were addressed. Finally the performance of the in-terface was tested using a line following program, which could be compared to the actual performance of one of the vehicles.

In conclusion the interface has to operate with a Matlab program that per-forms all the calculations. The Arduino merely acts as an intermediate sta-tion that collects sensor data and sends actuasta-tion commands. The program is generic since all the control algorithms are in Matlab, which are dedicated for each vehicle. XBees are used as wireless communication channel.

(6)

Introduction

Roads are becoming increasingly crowded and congested. To prevent trans-port delays from becoming excessive due to the increasing amount of cargo to be transported, alternative ways of transporting goods have to be in-vented. Waterways still have some transport capacity available; transport over water can, however, not reach every final destination: the last kilome-tres often have to be traversed over roads. An unwanted switch then has to be made, causing a disruptive event in the transport process when cargo has to be moved from one type of vehicle onto another at expensive cargo transfer terminals.

A solution for this challenge is proposed in the project ”Amphibian” which investigates the use of a hovercraft-type of vehicle as a transport system for the last kilometres of transport. Just like the Automated Guided Vehicles (AGV) autonomous operation of these vehicles is wanted, for cost effective-ness, overall efficiency and adaptability. This assignment contributes to this project by giving the first steps in the model set-up of a hovercraft in the AGV lab at the Faculty of 3mE of the TU Delft (Figure 1.1).

(9)

Upon completion this research assignment answers the question:

How can a generic Matlab-Arduino interface for wireless monitor-ing and control of a vehicle be best implemented?

In order to answer this research question the discussed sub questions are: 1. What are different methods of wireless communication between Matlab

and Arduino and which would be best suited for use?

2. What kind of protocol should be used for the communication between Matlab and Arduino?

3. What would be a basic strategy for control of a hovercraft?

4. What are the boundary conditions and limitations of the hovercraft program?

First a description of the AGV lab is given. In this chapter the lay-out of the lab, vehicles in the lab and the available sensors and actuators are shown. This is done to give an impression of the setting and possibilities of the lab in which the interface has to operate. Besides this an answer will be formulated to the first sub question.

Following this chapter the generic Matlab-Arduino interface will be elabo-rated in Chapter 3. The requirements to which the interface has to comply are given together with the basic structure. From the basic structure the pseudo-code is derived and from this the actual Matlab and Arduino pro-grams. These two programs have to communicate with each other using a communication protocol, which is described next. Here the second question is answered.

Chapter 4 covers some tests executed using the Matlab-Arduino interface. First the maximum speed of the serial communication is discussed. This is followed by the speed test at a fixed frequency. After this the velocity test of the AGV and hovercraft are given. These test all contribute to the evaluation of the requirements to which the interface should comply. In Chapter 5 the interface is tested further by implementing a line following program on all the vehicles. Each vehicle is discussed and the adaptations to the standard hardware set-up are noted (if needed). Besides this the control algorithm is stated and the possible improvements are given. At completion this chapter will give answers to the third and fourth question.

Hereafter the compliance of the interface to the set requirements is evalu-ated, followed by the conclusion in which the answers to the research (sub) questions are given. Finally the possible areas of future research resulting from this research assignment.

(10)

Chapter 2

Description of the AGV lab

This chapter will give an introduction to the AGV lab and the setting in which this research takes place. First the lab itself is discussed. Followed by the different vehicles that are present in the lab. After this the available sensors and actuators are given. The different methods of wireless commu-nication are elaborated next. The last section will cover the conclusions that can be drawn from this chapter. In this conclusion an answer to the following research question will be formulated:

What are different methods of wireless communication between Matlab and Arduino and which would be best suited for use?

2.1 Lay-out of the lab

The AGV lab is situated in a section of the research space of the Maritime and Transport Technology department which is situated in a part of the basement of building section B at the Faculty of 3mE [3mE 2015]. The des-ignated space for the AGV lab is placed in the far left corner of the basement when one is entering through the main entrance. The lab can be divided into two parts, the office space and the experimental space, in which the different models can be tested. Figure 2.1a shows the space reserved for testing in the foreground of the picture and the work places in the background. In Figure 2.1b the reserved space for the AGV lab can be seen, the lay-out of the whole basement can be found in Appendix A. The stated space for the AGV lab is 6.6 x 4 metre, but because of different cupboards and tables the actual empty space is 5 x 4 metres.

(11)

(a) Overview of the test space. • DRSN XT plein op elke penant een kabelgoot met E/D ^ D •Miergebruikr plaatpPOef kw + afvoef 1^^2650 pantry 3 . werktafels buigproef r lifthal bsh T.R. Testbank transporttpllen 380V RFID lab 3.0x5.0m Transportband 4.0x5.0m AGV lab 6.6x4.0m NBh=max 2950 NOODUIT water

Kelder toren B

Nieuwe situatie Plattegrond

toren B

KOI

werk 1313 werk 1313 tekening B-N/H-K01 scln. 1:100 versie scln. 1:100 concept datum 18-06-2014 rev. datum

1

A R C H 1 T E C T E N \ V E R H E I J E N V A N R I J S W I J K K N A P P E R S D E H A A N

(b) Floor plan of the lab. Figure 2.1: A detailed view of the AGV lab test space.

2.2 Line tracker

The line tracker is an off the shelf Arduino based robot that is able to follow a line, it is known under the product name Arexx AAR-004 [Conrad 2015]. It is shown in Figure 2.2, both the top-side and bottom view. The components used to build it are the board itself, two motors and wheels, a power source, a caster wheel and two infra-red sensors. The length is 180 mm, it is 120 mm wide and 40 mm high. The top speed of the line tracker is 0.1 m_s.

(a) Top-side view. (b) Bottom view. Figure 2.2: The line tracker.

(12)

2.3 AGV

The AGV is developed in the AVG lab at the Faculty 3mE of the TU Delft. The lenght of the model is 620 mm, the width 140 mm and the height 240 mm. The wheelbase (distance between the wheel sets) is 310 mm. The AGV model is a 1:25 scaled down version of the AGVs that can be found on various container terminals. The top speed of the model is 0.3

m

s. On top of the AVG (see Figure 2.3) the power source (a battery) is

placed alongside the Arduino and a breadboard (connection for different sensors and such). This top, which acts as a chassis, is made from a sheet of aluminium. Underneath the chassis the drive and steering mechanism is mounted, this can be see in Figure 2.4. There are two sets of wheels with a independent steering mechanism, the drive motor could be adjusted independently from each other, but this is not the case in the set-up. Both the drive motors are controlled at the same time. The control wires from the motors are attached to the Arduino so that the Arduino can control the AGV.

Figure 2.3: Top-side view of the AGV.

(13)

2.4 Hovercraft

The hovercraft model is a 1:10 scale version of a racing hovercraft, known as the Ikarus Dragstair Race Hovercraft [Conrad 2015]. The length of the model is 450 mm, it is 250 mm wide and 215 mm high. Out of the box a radio controller is supplied to control the speed, lift height and direction. These variables can be controlled through the adjustment of three servos or motors, namely the propulsion and lift motor and the steering servo. The propulsion and lift motor are connected to a propeller to provide the displacement of air needed for the movement. The steering servo is attached to a twin rudder system to provide accurate steering. At max speed the hovercraft can reach 11 m_s in its current form. The power comes from a 7.4 V LiPo (Lithium Polymer) battery. A 3000 mAh version is installed, which gives an operational time of nearly 20 minutes. Since the hovercraft is not suitable for use with the Arduino out of the box some changes have been made. The hovercraft is expanded with a power connection for the Arduino. The connectors to connect the Arduino to the hovercraft have been soldered to the Arduino to provide a durable and easy way of connecting the two. Figure 2.5 gives an impression of the model from different angles.

(a) Top-side view. (b) Top view without cover.

(c) Back view with steering flaps. (d) Connection to the Arduino. Figure 2.5: The hovercraft model.

(14)

2.5 Available sensors and actuators

Besides the different vehicles present in the AGV lab there are other compo-nents that are suitable for the Arduino platform available for use. Table 2.1 gives an overview of the available sensors and actuators [Parallax Inc. 2015] [SparkFun Electronics 2015] with their purpose and some characteristics.

Table 2.1: Overview of the different available sensors and actuators.

Name Purpose Type Range

Ping))) Distance Digital 3 m MaxSonar Distance Analogue 6.45 m ADXL335 Accelerometer Digital ±3 g MAG3110 Magnetometer I2C ±1 T LPY503AL Gyroscope Analogue ±30◦_s

IMU 9 DOF I2C

-QRE1113 Line sensor Analogue

-LED Output -

-The first two sensors are both able to measure the distance to an object, but one is digitally read, the other analogue. The analogue version has got the advantage that it requires less code to function and has got a higher range, the digital is more accurate. The four following sensors are all part of the same family, they are known as Degree of Freedom (DOF) sensors, the IMU is a combination of the accelerometer, magnetometer and gyroscope and provides a complete package. Some of these DOF sensors are read through I2C, this is a type of serial connection (similar to CAN-BUS). The advantage of this is that only two wires are needed to control the sensor (instead of six for the IMU), but the downside is that it requires more code and is slower in operation that an analogue sensor. The line sensor can be used for detecting a black line on a white surface (or vice versa). Finally there are some LEDs available, these are the only actuators present in the lab (besides the motors of the vehicles). A selection of these sensors and actuators is shown in Figure 2.6.

Figure 2.6: Sensors and actuators in the AGV lab (1 = gyroscope, 2 = line sensor, 3 = Ping))), 4 = magnetometer, 5 = MaxSonar, 6 = LEDs).

(15)

2.6 Wireless communication

The communication between the Arduino and Matlab has to be wireless, this is a requirement following from the fact that the interface will be used to control a vehicle. This vehicle has to be able to move freely throughout the available space and a wire would limit that. This section will discuss a couple of options for the wireless communication, but is not intended to give a complete overview of all the available options. The methods that will be discussed are Wi-Fi, Bluetooth and XBee. These three have been chosen because they are widespread methods for wireless communication (WiFi and Bluetooth) and / or that it has been used in other Arduino projects with succes before. This section is based upon[PCWorld 2015] and [Stack Exchange Inc. 2015].

Wi-Fi

Wi-Fi is a tried and tested method of wireless communication between de-vices for indoor use. It is used by laptops, tablets, phones and many other personal electronic devices. This is mainly caused by the fact that Wi-Fi has become a fast and reliable connection method. The main components in a Wi-Fi network are the centralized router and multiple receivers that are connected to the different devices in the network. The range of the network is depended on the power of the router and is typically 60 metres. A larger range can be easily obtained by the addition of more routers. In this way a meshed grid is created to ensure a good signal everywhere. The advantage of Wi-Fi is the communication speed, which can be as high as 250 M bit_s (maximal supported bandwidth). The main drawback of using Wi-Fi is the power consumption. This is relatively high since it operates at high speeds over relatively long distances.

Bluetooth

Bluetooth is, alike Wi-Fi, a tried and tested method of wireless communica-tion in personal electronic devices. Bluetooth networks are composed of two devices that can communicated directly with each other, a centralized router is not needed. The upside of this is that it is less complicated than a Wi-Fi network, but the range cannot be enlarged by adding more routers. The range of a typical Bluetooth network is 60 metres, but is heavily depended on the capabilities of the Bluetooth device. The communication speed can be as high as 25 M bit_s 1 but is depended on the device as well. This lower data speed means that the power consumption is lower too.

1

(16)

XBee

The XBee and XStick [Digi International Inc. 2014] are low powered mod-ules that are widely used in the Arduino world for wireless communication. This low power consumption is an advantage since the models in the AGV lab are battery operated, less power used means longer battery life. But it is a disadvantage too because the low power means that the distance over which information can be send is smaller. The range stated by the manu-facturer is 30 metres which should be sufficient in the lab, but this is most likely measured under perfect circumstances (no obstacles). The maximum transmission speed for these devices is 250 kbit_s , but when taking interfer-ence into account this drops to 115.2 kbit_s . Another advantage of the XBee is that all the hardware is available and that it has been tested and used before in the AGV lab [Gerritse 2014]. The XBee and XStick can be seen in Figure 2.7.

(17)

2.7 Concluding remarks

This chapter has given some information about the setting of the research. The available space was shown, the vehicles that are present in the AGV lab where elaborated and an overview of the available sensors has been given. An overview of the main characteristics of the different vehicles can be found in Table 2.2.

Table 2.2: Overview of the three vehicles in the AGV lab. Line tracker AGV Hovercraft

Length [mm] 180 620 450

Width [mm] 120 140 250

Height [mm] 40 240 215

Scale [-] 1:1 1:25 1:10

Speed [m_s] 0.1 0.3 11

Motors [-] 2x drive 1x drive lift and propulsion Servos [-] - 2x steering 1x steering

Besides this outline of the situation in the AGV lab one of the research questions has been answered, it was stated as follows:

What are different methods of wireless communication between Matlab and Arduino and which would be best suited for use?

Three different methods of communication between Matlab and Arduino have been evaluated: Wi-Fi, Bluetooth and XBee. The main properties of these methods can be seen in Table 2.3.

Table 2.3: Overview of the different wireless communication options. Wi-Fi Bluetooth XBee

Range [m] 60 60 30

Speed [M bit_s ] 250 25 0.11 Power consumption [-] high average low

Since the vehicles in the AGV lab are all battery operated a system with a high power consumption is not ideal. This would limit the test time on a battery charge. The range of all the methods is suitable for use in the AGV lab, when taking a look at the available space a range of 10 metres would be sufficient. The data that will be send between Arduino and Matlab will be most likely plain text, the data size of these commands will be several bytes; the very high speeds of Wi-Fi and Bluetooth is not needed for this system. When taking this into account, combined with the fact that the XBee has been used before in the AGV lab, it is the best option for the wireless communication between Matlab and Arduino.

(18)

Chapter 3

Generic Matlab-Arduino

interface

The design of the generic Matlab-Arduino interface will he given in this chapter. First the requirement to which the interface is subject to are shown. From these requirements the basic structure and the basic functions of the interface follow. From the structure and functions the final program can be made via the pseudo-code. This is followed by the communication protocol needed for the correct communication between Matlab and Arduino. The concluding remarks of this chapter are given last. Here the following question will be answered:

What kind of protocol should be used for the communication between Matlab and Arduino?

3.1 Requirements of the interface

The multiple vehicles shown in the previous chapter all have their own unique characteristics concerning control. These result in a different way of operation when designing a program for the control of them. To handle this nature the interface has to comply with the following requirements. Generic

Since it is called a generic Matlab-Arduino interface it has to be able to run on the vehicles in the AGV lab present and Matlab can control them. This has to be done without any alterations to the Matlab or Arduino program. Adaptable

Because of the generic nature of the interface the addition of actuators and sensors should not be a problem. Furthermore the Arduino program has to handle all different sensors and actuators available that are made for the Arduino. An overview of the available actuators and sensors in the AGV

(19)

lab was given in Section 2.5. The maximum number of sensors or actuators is limited to the number of pins of the Arduino (6 Analogue and 12 Digital).

Ease of use

The interface has to be easy to use and adapt. This requires a clear format and comprehensive manual that covers the possible (known) problems and difficulties.

Sampling frequency

The Matlab-Arduino interface uses wireless communication to transfer the sensor data and send the actuation commands. The minimum frequency at which this communication has to take place is 10 Hz. The value of 10 Hz is obtained by calculating the maximum distance that can be covered by each vehicle between two successive measurements. At this frequency and top speed the line tracker moves around 10 mm and the AGV almost 30 mm. The hovercraft is able to cover 1.1 metres in between steps which is too much. The assumption has been made that the top speed of the hovercraft is not feasible looking at the available space (5 x 4 metre), therefore the speed will be similar to the speed of the AGV.

3.2 Basic structure

The basic structure of the generic interface can be found in Figure 3.1. This type of control structure can be seen as centralized control, there is one central control program that does all the calculations, which is Matlab. Matlab receives measurements from and sends actions to the Arduino. It does not perform any calculations, measurements or actions, it only acts as a collection and distribution point that sends the data and commands in the correct format. The end point of the control structure is the vehicle. The vehicle provides the Arduino with measurements (sensors) and performs the actuation commands (actuators) send from the Arduino.

(20)

Below Matlab, Arduino, the sensors and the actuators are shown with their main tasks in the control structure. These tasks are used as a starting point for the actual Matlab and Arduino programs.

Matlab [The MathWorks Inc. 2014]

• Receive input data from the Ar-duino;

• Determine actuation com-mands;

• Send actuation commands to the Arduino;

• If applicable: store input data. Arduino [Arduino 2014]

• Collect input data from the sen-sors;

• Send input data to Matlab; • Receive actuation commands

from Matlab;

• Send actuation commands to the motors.

Sensors [Famosa Studio 2015]

• Measure physical variables; • Different types of sensors can be:

distance, speed, acceleration, lo-cation, etc.

Actuators [Automation Tech 2015]

• Perform actuation commands; • Different types of actuators can

(21)

3.3 Pseudo-code

This section gives the first translation from the main tasks of the Matlab and Arduino shown on page 13 into an actual program. This first step is known as the pseudo-code. It is the description of the main tasks in a programming style language.

Matlab pseudo-code

The main tasks of the Matlab program are: • Receive input data from the Arduino; • Determine actuation commands;

• Send actuation commands to the Arduino; • If applicable: store input data.

These tasks have to return in the pseudo-code for it to work as intended. Besides this different statements are needed for the smooth operation of the different vehicles. The resulting pseudo-code can be found below.

1 Load vehicle parameters 2 Define runtime

3 Open serial connection 4 Initiate vehicle

5 While time runtime

6 Receive data f rom Arduino 7 (Store data)

8 Determine actions 9 Send actions to Arduino 10 Terminate vehicle

11 Close serial connection

1 The vehicle connected has to be loaded into the program. 2 The test length can be limited

by defining the runtime.

3 The communication channel be-tween Matlab and Arduino has to be opened.

4 The initial actuation commands have to be send to the vehicle. 5 This is the program loop, it is

true while the current time is lower than the runtime.

6-9 The tasks of the Matlab pro-gram are inside the loop. They are executed during the run. 10 When the test is concluded the

vehicle has to be stopped. 11 When the vehicle is stopped the

communication channel can be closed.

Matlab does not like to be stuck in an endless loop. To prevent this the while-loop is added to the program. But there are other ways of resolving this issue, it could run for a number of steps, or until the user gives a signal. The time depended loop is chosen because it is easier to understand for most people than a number of steps and it is less complicated than the user signal routines.

(22)

Arduino pseudo-code

The main tasks of the Arduino program are given in the pseudo-code shown below.

1 Read data from sensors 2 Send data to Matlab 3 Receive data from Matlab 4 Actuate vehicle motors

1 Collect input data from the sen-sors.

2 Send input data to Matlab. 3 Receive actuation commands

from Matlab.

4 Send actuation commands to motors.

The proposed Matlab and Arduino program will satisfy the set requirements. The Arduino program is not depended on the type of vehicle: it is generic. The Matlab program is made generic by first selecting the correct vehicle before starting the actual control loop. As long as the Arduino has got space left for more sensors and actuators the can be added to the Arduino. This means that it is adaptable to the users needs.

(23)

3.4 Detailed code

The pseudo-code discussed in the previous section is given in more detail in this section. The complete Matlab code can be found in Appendix C, the Arduino code in Appendix D.

Matlab code

Only the main loop is shown in this section. The different run parameters have been loaded before this loop is activated. The first thing that happens in the code is the opening of the serial communication channel. Followed by the selection correct vehicle parameters. After this the initiation com-mands are send to the Arduino. This is followed by the timing loop of the program (which will be shown next) and the program is concluded with the termination of the vehicle and the closing of the serial port.

1 %% Loop for the different vehicles

2 Openserial; 3 pause(2); 4 5 if vehicle == 1 6 command = '<0b,0c>'; 7 Senddata; 8 ParameterHovercraft; 9 elseif vehicle == 2 10 ParameterAGV; 11 end 12

13 servoA = initial.servoA +p.DservoA;

14 servoB = initial.servoB +p.DservoB;

15 servoC = initial.servoC +p.DservoC;

16 [command] = Initiate(p,initial,frequency);

17 Senddata;

18

19 while (timer < testlength)

20 ... 21 end 22 23 [command] = Terminate(t,p); 24 Senddata; 25 26 Closeserial;

(24)

The while timing loop takes places as long as the timer of the program is smaller than the test length. In order to time the loop a tic toc is used (Matlab timer). The first function of the loop is to receive the data from the Arduino. The received data is evaluated for the correct vehicle model by the controller of that vehicle. This controller has as output the commands that have to be send to the Arduino, which takes place after they are known. Finally the timer is stopped and the loop counter is increased with one.

1 while (timer < testlength)

2 startLoop = tic;

3 stopID = 0;

4 Receivedata;

5 % The following if loop checks for received data, 6 % if there is none the program is stopped before

7 % an error occurs. 8 if stop 9 ... 10 end 11 12 if vehicle == 1

13 [command, servoA,servoB, p, counter] = ...

14 ControllerHovercraft(sensorZ, sensorY, sensorX,...

15 p , initial, servoA, servoB,counter , straight);

16 elseif vehicle == 2

17 [command,servoB, servoC, p] = ControllerAGV(...

18 sensorZ, sensorY,sensorX, p, initial,servoB, servoC);

19 end

20 Senddata;

21 endLoop = toc(startLoop);

22 if stopID ~= 4

23 timer = timer + endLoop;

24 end

25 j = j+1;

(25)

Arduino code

The main loop of the Arduino program is shown in this section. The loop is the part of the program that is executed over and over again. Here the dif-ferent subroutines that contain the difdif-ferent tasks of the program are called upon. The program is made from two subroutines, actuateVehicle and send-Data. The first subroutine checks the serial connection for commands from Matlab. These commands are evaluated and the commands are send to the proper actuators. When it is finished the boolean sensor becomes true and sendData can be executed. It is used for the collection of sensor data and the sending of this data to Matlab. In this part of the Arduino program the actual frequency timing takes place. An interval time is checked to ensure that the time step is correct.

The last if statement in the loop is used to stop the vehicle from moving when the communication between Matlab and the Arduino has not taken place for more than 1 second. When the communication frequency is lower than 1 Hz, this time has to be larger. Otherwise the stop command will be send every second, even when this should not be the case. This part works for both vehicles, but is not ideal. The hovercraft requires the lift and propulsion motors (B and C) to be at 0, whilst the AGV steering servos (B and C) stop accepting values lower than 45 or higher than 135. When the program is uploaded for one vehicle this can be altered to suit the vehicle.

(26)

3.5 Communication protocol

The communication between Matlab and Arduino will be performed by the XBee and XStick (Section 2.7). To ensure that the whole packages of data will be transmitted over the serial connection between the XBee and XStick a communication protocol has to be used. The basis for this protocol is the ZigBee protocol [ZigBee Alliance 2014] that is used by the XBee and XStick. This protocol is used for personal networks built from low powered digital radios. But it is far from complete, a true communications protocol must define the syntax, semantics and communication synchronization. These are not part of the ZigBee protocol. The part of the ZigBee protocol that is used is the firmware on the XBee and XStick, for this firmware there are three options:

Coordinator The basis of the network, stores all the information about the different network settings.

Router Device can execute commands from the coordinator as well as sending commands to other devices.

End Device Device can execute commands and provide feedback.

The different settings can be altered by using the appropriate computer program, a manual for this can be found in Appendix B.

Syntax

The syntax of the protocol describes the boundary conditions to which a command has to comply to be considered correct. It can be seen as the form in which the command has to be put in order for both Matlab and Arduino to make sense of it. As could be seen in the previous section the communi-cation between Matlab and Arduino takes place by means of strings in the following form: ”< 90a, 90b, 90c, 100f, 1s >”. This is the correct syntax for Arduino to read the whole string. The Arduino program starts evaluating the command when a ”<” is received and stops when ”>” is received. In between these two operators are the commands to the actuators and pro-gram variables.

From Arduino to Matlab the syntax is different, between each sensor output a space has to be inserted and after the last output a new line has to be made by the Arduino. Matlab reads one whole line at a time and breaks the string into parts indicated by the space.

Semantics

The semantics of the communications protocol define the meaning of cer-tain expressions. When the syntax is correct, the semantics define what the actions will be resulting from the commands. Matlab searches for a space

(27)

between two values and the user has to tell Matlab to which variable the value belongs.

The Arduino is programmed to search for a number and a letter before a comma. This combination of a number and letter describes the action (num-ber) and address (letter). When the command ”< 90a, 90b, 90c, 100f, 1s >” is evaluated the ”a”, ”b” and ”c” are actuators, ”f ” is the frequency (a wait time in milliseconds) and ”s” is the request for a sensor measurement.

Communication synchronization

The XBee cannot handle incoming and outgoing commands at the same time. Therefore the communication has to be synchronized. This synchro-nization is guaranteed by the start and stop operator in the Arduino code and because Matlab reads a whole line before continuing. These two meth-ods ensure that the entire command is read and processed before the next step can start.

3.6 Concluding remarks

This chapter has given the different requirements to which the interface has to comply (generic, adaptability, ease of use and sampling frequency), it has stated the structure of the program and the actual program following from this basic structure. An answer to the following research question has been formulated:

What kind of protocol should be used for the communication between Matlab and Arduino?

The base of the protocol will be the ZigBee protocol since the XBees use it. Some additions to it have to be made to ensure a correct operation of the system. These additions are the definition of a good syntax,

”< 90a, 90b, 90c, 100f, 1s >” from Matlab to Arduino and space separated values from Arduino to Matlab. The semantics have to be entered in the Arduino and Matlab program such that the commands arrive at the correct addresses. And the communication must be synchronized in such a way that the whole commands have to be read before the program continues. This is achieved by the addition of unique end of command operators.

(28)

Chapter 4

Testing the Matlab-Arduino

interface

This chapter describes various tests using the Matlab-Arduino interface. By executing these tests a better insight is given into the performance of the interface under various conditions. First the maximum speed of the serial communication is discussed. This is followed by the speed test at a fixed frequency. After this the velocity test of the AGV and hovercraft are given. These test all contribute to the evaluation of the requirements to which the interface should comply. This is covered in the concluding remarks.

4.1 Maximum sampling frequency of the XBee

The XBee system can be configured to the need for speed of the user by altering the Baud rate. The standard options are 1200, 2400, 4800, 9600, 19200, 38400, 57600 and 115200 bps. This section describes the effect of higher Baud rates on the measuring frequency of the Matlab-Arduino inter-face. With the results of this test one of the requirements of the interface can be evaluated (sampling frequency).

For this test the Arduino is disconnected from the vehicle and is used with power from a wall socket. The Ping))) sensor is attached to the Arduino via a breadboard and jumper wires. The XBee shield with a XBee is placed on top of the Arduino. The generic interface is running on the Arduino which sends the collected data to Matlab. The fact that the Arduino is discon-nected from a vehicle does not affect the validity of the test. The Arduino program receives a command string from Matlab which contains actuation commands of the motors and servos. The Arduino has to evaluate these commands and send them to the correct address. Even if no actuators are connected to these addresses the time it takes is the same.

(29)

For each Baud rate three test are executed of 20 seconds, in these test Matlab requests a measurement from the Arduino of the distance of the Ping))) sensor. Matlab receives this measurement together with the time stamp. From these time stamps the time step is calculated and for all these steps the average frequency, average time step and deviation from the average is derived (for each measurement). The deviation is calculated with a standard Matlab function which is based on Equation 4.1. This type of standard deviation is used for discrete random variables.

σ = 1 n − 1 n X i=1 (xi− x)2 !1₂ , where x = 1 n n X i=1 xi (4.1)

The results of this test can be found in Figure 4.1 (page 24). As can be seen in this figure the mean value of the time step is relatively stable for the three runs, but the deviation differs more. Especially for the lower frequen-cies the variation in the deviation is rather large. There are two possible explanations for this, the serial connection is lost temporarily or that the Arduino program gets suck somewhere. The latter is unlikely because that would occur also at the higher frequencies.

The three measurements are combined in an overall look on the effect of the Baud rate. The resulting data can be found in Table 4.1 in numerical form. As can be seen in this table the minimum time step that can be achieved seems to be 50 ms. Since the frequency is solely depended on the time step the maximum measuring frequency is nearly 20 Hz. Furthermore the change in frequency is rather small for the large Baud rates: the Baud rate increase threefold (38400 to 115200), but the frequency increases only 9% (18.20 to 19.83).

Table 4.1: Combined communication data of the three measurements. Baud Rate [bps] Time step [ms] Deviation [ms] Frequency [Hz]

1200 337.00 8.41 2.97 2400 192.13 16.01 5.20 4800 118.62 11.46 8.43 9600 84.38 7.41 11.85 19200 65.35 7.85 15.30 38400 54.94 9.11 18.20 57600 51.51 7.82 19.41 115200 50.44 7.99 19.83

When taking a look at the deviation from the time step a peak can be seen at slow connections and at 38400 bps. The uncertainty of the peak at 38400

(30)

is quite low since all the three measurements have resulted in nearly the same value, but at lower frequencies the deviation varies for the three mea-surements (Figure 4.1). Therefore no decisive conclusions can be derived from these data points. Only the data points for Baud rates large that 9600 are valid for such a small data set. Beside this it has to be noted that the deviation shown in the graph is the actual deviation and is not normalized for the length of the time step. The higher frequencies have got a much larger deviation in percentage than the lower frequencies.

When taking all the data into account the Baud rate for the Matlab-Arduino interface is 57600 bps. This is nearing the maximum frequency of the pro-gram and gives a slightly lower deviation in time step compared to the highest Baud rate. Another reason for the lower Baud rate is that too high Baud rates can lead to loss of data, this is described in literature and by users of the XBee interface.

It is furthermore advised to execute a new speed test when the program is changed significantly. The new structure of the program could mean that the test results shown in this section are not valid any more.

This section has shown the maximum frequency of the program. When the maximum frequency is not needed a test with a fixed frequency can be executed to show the performance of the high Baud rates at a lower frequency, this will be discussed in the next section.

(31)

(32)

4.2 Fixed sampling frequency of the XBee

This section will give the effect of fixing the sampling frequency for the dif-ferent Baud rates. When the maximum frequency of the interface is not needed it might be useful to know what the performance of the different Baud rates is on a fixed frequency. A better evaluation can be made in this way of the optimal communication speed. The results from this test are used to evaluated the sampling frequency requirement.

The set-up for this test is similar to the one described in the previous section, but differs on some distinct points. The Arduino is still disconnected from the vehicle and is powered from a wall socket. Instead of the Ping))) sensor one or more line sensors are connected to the Arduino. The communication with Matlab is done through the XBee.

The test length remains at 20 seconds. Three fixed frequencies are evaluated in this test namely, 5, 10 and 15 Hz. The effect of sensors is evaluated as well, for each frequency one, two and three analogue line sensors are at-tached to the Arduino and the data from these sensors is send to Matlab, together with the time stamp. The time stamp is evaluated by Matlab and the average frequency and the deviation (Equation 4.1) is calculated from the time step.

The results from this test can be found in Figure 4.2 for one sensor, Fig-ure 4.3 for two sensors and FigFig-ure 4.4 for three sensor. All the FigFig-ures have the same lay-out, the top graph shows the achieved frequency and the bot-tom graph the standard deviation of the time step.

All the nine frequency graphs show a trend that can be expected, more sensors mean a lower frequencies and higher Baud rates are more capable of running at higher frequencies. But there are some results that stand out concerning the deviation. The deviation of one sensor @ 10 Hz for 1200 bps is nearly 20, whilst the other are not higher than 10. This is caused by one data point that is twice as high as the rest. When this point is not taken into account the standard deviation falls to almost 9 ms. The overall trend of the deviation lines is not always as expected, it should descend over the Baud rate, but can suddenly rise. The most likely explanation for this is that the serial communication channel gets ’lost’ momentarily and the program has to catch up again. The higher frequencies have less difficulties coping with this nature since the program is finished before the next time step has ended.

(33)

Figure 4.2: Communication frequency for one sensor.

(34)

Figure 4.4: Communication frequency for three sensors.

4.3 AGV velocity test

Using the Ping))) sensor the speed of the AGV has been determined. The calibration of this sensor can be found in Appendix E. The main purpose of this test is to gain a better understanding of the velocity and acceleration profile of the AGV.

The used test set-up can be found in Figure 4.5. The AGV is equiped with the ping sensor facing forward, aimed at a big black box which is the refer-ence plane. When the test is started the Arduino receives a command from Matlab to drive in a straight line at max speed. During the driving the sensor measures the distance to the reference plane at maximum frequency and sends this data together with the time stamp to Matlab. After 5 sec-onds Matlab sends the termination command to the Arduino and the test is concluded. To generate a large enough dataset the test is repeated 10 times.

(a) Set-up of the AGV with ping sensor. (b) Measuring plane, a big black box. Figure 4.5: AGV velocity test using ping sensor.

(35)

The test data coming from the Arduino is the distance and time stamp of the measurement. These are used to calculate the velocity and acceleration of the AGV. This is done using three different methods shown in Table 4.2. The first method is the normal way of calculating velocity and acceleration from time and distance. The second methods involves increasing the step between the two data points to increase the stability of the curve. The third method uses the results of the second method to calculate the average of three surrounding measurements.

Table 4.2: Three methods of calculating velocity and acceleration.

Method 1 Method 2 Method 3

The results of these calculation methods can be found in Figure 4.6 and Figure 4.7. In these figures all the test runs are plotted with the mean value given in black. As can be seen in the velocity figure the first method re-sults in a wide spread of values, this is reduced by the use of bigger steps and made even better using the three point average routine. For all plots the spread in the acceleration is quite large (compared to the velocity), but the trend becomes much more clear when applying the third method. The mean line of the third graph shows the path that is expected, high initial acceleration and after almost a second steady state.

Figure 4.8 shows for the ten data sets the mean value for the velocity and acceleration at steady state. The mean value is taken from one second until the test end. When all these results are combined the steady state value of the velocity is 0.308 m_s and for the acceleration 0.019 m_s2. Using

the Matlab function cftool the functions for the first part of the mean lines are determined. The resulting function for the velocity can be found in Equation 4.2 (t ≤ 700ms) and the acceleration in Equation 4.3 (t ≤ 850ms). This is for the third method, when the time is higher than 700 (or 850) ms the steady state part kicks in.

v(t) = −5.741 × 10−7t2+ 8.124 × 10−4t + 6.573 × 10−3 (4.2)

a(t) = 9.068 × 10−3t5− 1.574 × 10−2t4− 6.044 × 10−3t3

(36)

Figure 4.6: Velocity graph for the three methods (10 runs), black is the average.

Figure 4.7: Acceleration graph for the three methods (10 runs), black is the average.

(37)

(38)

4.4 Hovercraft velocity test

The same way as described in the previous section the velocity of the hover-craft is tested. Both the Ping))) sensor and the MaxSonar distance sensors are used because of their different specifications (range and sensitivity). The calibration of these sensors can be found in Appendix E. The main purpose of this test is to gain a better understanding of the velocity and acceleration profile of the hovercraft.

The used test set-up can be found in Figure 4.9. The Hovercraft is equiped with the sonar or ping sensor facing forward, aimed at the wall which is the reference plane. When the test is started the Arduino receives a command from Matlab to move in a straight line at a speed of 90 towards the wall (the speed range is 70-130) and the frequency is set to 10 Hz. During the movement to the wall the distance is measured and send together with the time stamp to Matlab. After 7 seconds the test is concluded for the MaxSonar, 5 seconds for the Ping))) sensor. This difference in test length is caused by the lower range of the Ping))) sensor. To generate a large enough dataset the test is repeated 10 times. The method shown in Table 4.2 is used for the evaluation of the velocity and acceleration.

(a) Hovercraft with ping sensor. (b) Measuring plane, the wall. Figure 4.9: Hovercraft velocity test using ping sensor.

The results for the velocity test of the MaxSonar sensor can be found in Figure 4.10. The top graph shows the result of the normal method, the middle graph the increased step and the bottom graph the three point aver-age method result. This last velocity graph of the sonar sensor shows that the velocity of the hovercraft climbs to 3 m_s in nearly 200 ms. This is fol-lowed by a steep deceleration to 0.5 m_s, to end up at almost 1 m_s at the end. This velocity profile does not make sense when considering a vehicle that is accelerating from standstill with a constant thrust. Since the velocity profile is useless the acceleration profile of the MaxSonar sensor is not evaluated. Figure 4.11 and Figure 4.12 show the test results for the Ping))) sensor.

(39)

Figure 4.10: Sonar sensor velocity graph (10 runs), black is the average.

The lay-out of the figures is the same as described above. The three point average velocity profile shows a gradual climb in velocity over time until the test ends. The maximum value is almost 0.8 m_s. There is only one problem, the hovercraft has most likely not reached a steady-state velocity. The steepness of the velocity profile starts to decrease which indicates that it is nearly done accelerating, but this is not certain. When taking a look at the acceleration profile belonging to the velocity it is nearly zero at the end of the test, while it has been positive for the first part. This is an indication that the maximum velocity has been reached, but it could also be a measurement error. This could be solved by performing a test with a longer run time, but the range of the Ping))) sensor restricts this.

(40)

Figure 4.11: Ping sensor velocity graph (10 runs), black is the average.

(41)

4.5 Concluding remarks

This chapter has shown several tests carried out with the Matlab-Arduino interface in order to gain a better insight of the performance of it. These tests contribute to the evaluation of the requirements as well. The require-ments were given in Section 3.1.

Generic

The generic nature of the interface is tested in all the tests shown in this chapter. The different tests all use different sensors or different vehicles. The Ping))), line and MaxSonar sensor are tested on a stand-alone Arduino, the AGV and the hovercraft. All these tests have been carried out successful and that proves that the interface is generic for these sensors and vehicles. Adaptable

This requirement is added to ensure that the interface is able to run with different sensors and actuators. In Section 4.2 the interface was used with one, two and three line sensors attached to it. This has not resulted in any problems, the interface is adaptable concerning sensors. The AGV and hovercraft do have some different actuator arrangements (AGV two steering servos, hovercraft one; motors are vice versa), this difference has not affected the interface. Therefore it can be stated that the interface is adaptable con-cerning actuators.

Ease of use

This requirement has not been tested in this chapter. 10 Hz sampling frequency

The Sections 4.1 and 4.2 have shown the sampling frequency of the interface under various conditions. The maximum sampling frequency of the interface is 19.83 Hz (@ 115200 bps). The 10 Hz criterion has been met for 19200 bps when three sensors are attached.

(42)

Chapter 5

Line following using the

Matlab-Arduino interface

In order to test the interface on the different vehicles in the AGV lab a line following program is made. Line following is one of the most basic methods of autonomous operation of a vehicle. Besides this it can be compared to the actual performance of one of the vehicles (the line tracker). Each vehicle is discussed and the adaptations to the standard hardware set-up are noted (if needed). Besides this the control algorithm is stated and the possible improvements are given. This chapter contributes to the evaluation of the requirements. Besides this the following two research questions are answered in the concluding remarks:

What would be a basic strategy for control of a hovercraft?

What are the boundary conditions and limitations of the hovercraft program?

5.1 Line tracker

The sole purpose of the line tracker is to follow a line. Therefore no ad-ditional hardware is needed to make it suitable for this task. The changes made to the interface are given next.

Arduino adaptations

The Arduino on the line tracker is built into the robot. Most of the wires are put into the circuit board to make it more durable, but this means that the layout of the robot can not be changed easily. This is where problems occur when trying to use the Arduino part of the interface, the way of controlling the motor is fundamentally different for the robot and the interface. The Arduino program on the line tracker is adapted to work by defining multiple cases on the Arduino (left, right, forward and stop) which can be

(43)

selected by Matlab. The adaptation to the Arduino program is shown next as pseudo-code [Gerritse 2014]. The actual Arduino program file can be found in Appendix F.

Check serial buffer for received signals if signal = 0: Stop driving

if signal = 1: Turn right if signal = 2: Turn left if signal = 3: Drive straight if signal = 4: Suspend

Matlab adaptations

Because of the changes in the control of the motors the way of sending the commands have to change too. The only thing Matlab has to provide to the Arduino is which case it wants to be executed. This is done by sending the number shown in the code for each case (0,1,2,3,4). When Arduino receives one of the numbers is will automatically know which command to execute.

Performance of the interface

The performance of the interface on the line tracker is compared to the performance of the original program. For both cases the line tracker is ordered to follow a line for 20 seconds. The number of times that the line tracker loses the line (excluding the end of the line) and the cumulative time is noted for each run. The test set-up can be seen in Figure 5.1. This test is executed ten times, five times facing left, five times facing right.

(44)

The results of this test can be found in Table 5.1. The first two columns give the data for the baseline, after that the interface is shown. As can be made up from this table the baseline outperforms the interface almost a fac-tor ten. The main reason for this is the sampling frequency of the baseline program is 100 Hz, this can not be achieved by the interface because of the delays in sending/receiving data and executing the Matlab loop. The actual frequency achieved by the interface is only 17.24 Hz.

Table 5.1: Number of misses and cumulative miss time for the three cases. Run Baseline Interface Corrected baseline

# time # time # time

1 1 1,65 12 16,49 12 18,03 2 1 1,38 12 16,41 12 17,32 3 1 1,36 8 13,61 12 17,33 4 2 4,43 11 15,35 13 17,56 5 1 0,91 10 14,21 13 17,82 6 1 1,41 11 15,31 10 16,64 7 1 1,21 10 14,84 14 17,49 8 1 0,92 13 16,61 13 17,09 9 2 1,78 11 14,61 11 17,06 10 2 2,65 11 14,34 9 14,69 µ 1,30 1,77 10,90 15,18 11,90 17,10 σ 0,48 1,06 1,37 1,05 1,52 0,94

A new experimental set-up has been made that overcomes this problem. The Arduino program used in the baseline is altered to match the average sampling frequency of the interface. This test is executed ten times, five facing right and five facing left on the same line. The results from this test are shown in the last two columns of Table 5.1.

In Figure 5.2 the results of the data of the three tests is shown together with the mean for each test. The Matlab interface performs better than the frequency corrected baseline, it loses the line less often and the cumulative time is lower. The corrected baseline works with a fixed frequency generated by a delay in the program, the Matlab interface has the same average value, but the frequency ranges from 15 to 20 Hz. And the probability that the sensor detects the line is higher for the faster sampling times.

(45)

Figure 5.2: Cumulative miss time for each run with the mean value.

Possible improvements

The line tracker does not work properly when controlling it with the Matlab-Arduino interface. Besides this the generic program is not compatible with the line tracker, it requires changes to the program to work. There are two options to make the generic interface work on the line tracker. The first is to break the line tracker apart and make the hardware suitable for the use with the interface. The other option is to alter the software to work with the line tracker. This is the most likely solution but it is not favourable because it would require the adaptation of the AGV and the hovercraft to work the same way as the line tracker (other motors, more wires, less control). The lower sampling frequency of the interface can be corrected by changing the spacing between the two sensors. This would give the program more slack time to perform the measurement and detect the line. The easiest option would be to lower the speed of the line tracker, but this can not be done since the motor control only supports LOW (0) and HIGH (1) commands.

(46)

5.2 AGV

The AGV is a platform that can be used to house different types of sensors. These sensors are not attached to the AGV and have to be installed in a durable manner. The interface needs no work, the Arduino program can be used as is and the Matlab program has got AGV specific files that are called upon. To give a good overview of the control of the AGV the Matlab controller is given.

Hardware adaptations

To make a line following AGV it has to be expanded with multiple line sensors. Two would be enough (like the line tracker), but three sensors give a better control of the vehicle. These sensors have to be connected to the Arduino by means of jumper wires and have to be in a fixed position (a couple of mm above the ground) connected to the AGV; a sensor bracket has to be designed and built to house the sensors. This has resulted in the line sensor bracket shown in Figure 5.3.

(a) Front view of line following AGV. (b) Side view of line following AGV.

(c) Top close-up of AGV bracket. (d) Bottom close-up of AGV bracket. Figure 5.3: Different views of the AGV sensor bracket.

(47)

The bracket can be attached to the AGV by means of tape, this makes it easy to remove when it is not needed any more. The line sensors can be placed in one of seven positions using a screw. The height of the sensor beam can be adjusted by moving the front (vertical part in the picture) up when the holding screws are loose and fixing it in the desired position. The fine adjustment of the sensor height can be done by placing some washers between the sensor and the aluminium angle profile.

Matlab controller

The controller for the AGV uses the input from the three sensors to define the actions that have to be taken. The controller functions are shown in pseudo-code next. The actual Matlab controller can be found in Appendix F. The main functions are to keep moving straight ahead while the center sensor sees the black line and turn when one of the other two sensors sees it.

if Center sensor = black Straight

if Right sensor = black Turn left

if Left sensor = black Turn right

With this controller the AGV can follow the line without any problems. It has to be noted that the steering angle and the drive speed are correlated. Higher speeds require less steering compared to lower speeds. A combination of that has been proven to work is a speed of 135 combined with a steering angle of 30 degrees.

The line following AGV works with the proposed adaptations to the hard-ware and settings for the speed and steering angle. The only point of im-provement is executing more tests to determine the correlation between the speed and the required turning angle.

(48)

5.3 Hovercraft

The hovercraft is a RC-model that is adapted to work with the Arduino. Therefore some work is needed to make is suitable for line tracking purposes. The same applies for the interface as with the AGV, the Arduino program operates without adaptations, and the Matlab program has got the specific files built in. To give a good overview of the control of the hovercraft the Matlab controller is given.

Hardware adaptations

Alike the AGV a sensor bracket has to be made for the hovercraft. The initial idea was to use the same bracket for both vehicles, but this was un-successful. The bracket is too heavy for the hovercraft and it did not achieve lift-off. Another less heavy bracket has to be designed for the hovercraft. The aluminium angle profiles are replaced by wooden skewers and it is fixed with duct tape and steel wire. This set-up can be seen in Figure 5.4.

(a) Front view of the sensor bracket. (b) Bottom view of the sensor bracket. Figure 5.4: Hovercraft sensor bracket.

This bracket is light enough to be lifted by the hovercraft, but it is not as stiff and sturdy as the aluminium one. This makes it more difficult to adjust the height of the sensors and is therefore less accurate.

Matlab controller

The controller for the hovercraft works in the same way as the AGV, but differs on some points. The sensor data from the Arduino is processed and based on this data the actions are determined. The only difference is in the fact that the hovercraft has got a dynamic steering algorithm built in that could be used to control long lasting curves. The controller functions are shown in pseudo-code next. The actual Matlab controller can be found in Appendix F.

(49)

if Center sensor = black Straight

if Right sensor = black Turn left

if Left sensor = black Turn right

Dynamic steering algorithm

Opted settings for controlling the hovercraft

The hovercraft is tested extendedly in the AGV lab using two different set-ups. The first is the small circle (radius is 1 metre) that can be seen in Figure 1.1. Since the performance of the hovercraft was not satisfactory in this set-up, a half circle has been made with a large turn radius (2 metre), to test the influence of the radius on the performance. This test set-up is shown in Figure 5.5. This section will give some information about the different settings that have been tested during the research, both for the small circle and the large.

(50)

These different control parameters and settings have been tried for the small circle:

• Propulsion power set low (80) and lift power around 100. Different steering angles;

• Combination of the previous with adaptive propulsion power when the turn takes more time (both adding power and lowering), in 2 to 4 steps;

• Changing to adaptive steering, in 2 to 4 steps;

• Combination of adaptive steering and adaptive propulsion power, in 2 to 4 steps;

• Lowering lift power to increase drag.

These different control parameters and settings have been tried for the large circle:

• Propulsion power set low (70 to 90) and lift power around 100. Steering angle is fixed to 78 (maximum).

• Lowering lift power to increase drag.

• Lowering propulsion power to reduce speed.

• Adaptive propulsion power when the turn takes more time (both adding power and lowering), in 2 to 4 steps.

• Changing to adaptive steering, in 2 to 4 steps.

• Combination of adaptive steering and adaptive propulsion power, in 2 to 4 steps.

• Combination of adaptive steering, adaptive propulsion power and adap-tive lift, in 2 to 4 steps.

The best results have been recorded for the large circle test using a simple controller. In this controller the adaptive part is not used at all and the only thing that is changed is the steering angle. The reason that this simple controller works best is that different circle radii require different settings for the adaptive counters (counter1,2,3) and are depended on the propulsion and lift power. The only downside of these settings is that the speed of the hovercraft is very low (80). Attempts have been made to increase the speed by increasing the propulsion to 81, but it resulted in a vehicle that was out of control within seconds.

(51)

The set-up of the hovercraft shown above is far from perfect. On the hard-ware and the controller side of the vehicle some improvements can be made. The sensor bracket is not stiff enough to provide a stable basis for the sen-sors. There might be some variation in the height of the sensor which asks for a alteration of the threshold of the sensors. Preferably a sort of sensor bracket is used that is not fixed to the hovercraft, but that can move in the vertical direction independently from the hovercraft. In this way the distance from the ground to the sensor is fixed and the sensor data can be evaluated more precisely.

The controller of the hovercraft works, but is very limited. When the speed or the steering angle is changed it does not work properly any more. After numerous observations of the hovercraft performing test runs it became clear that it is unpredictable. The first seconds (depending on the speed) of operation everything works as it should be. But the error in the angle between the hovercraft and the line becomes increasingly bigger; the hovercraft overshoots the line. This continues until the overshoot becomes too large and the hovercraft looses the line all together. Besides this not only the settings of the servos is of impact on the performance, but the state of the battery and the roughness of the surface it is riding on change the performance too, for example.

The controller can not cope with any kind of disturbances since it works on the principle of feedback. When the hovercraft has a turning rate that is too high, the controller does not know that. Therefore some additions have to be made to the controller and / or hovercraft. An additional controller sequence can be made that predicts the turning speed (and acceleration) of the hovercraft and tries to limit it, which can be implemented via Model Predictive Control (MPC). The use of more sensors with a feedback loop could be another improvement of the controller. A sensor that might work is a gyroscope which measures the turning speed.

A proposal of a generic Matlab-Arduino interface for use in the AGV lab - Een voorstel voor een generieke Matlab-Arduino interface voor het AGV lab

Preface

Abstract

Contents

Chapter 1

Introduction

Chapter 2

Description of the AGV lab

2.1

Lay-out of the lab

Kelder toren B

toren B

KOI

1

2.2

Line tracker

2.3

AGV

2.4

Hovercraft

2.5

Available sensors and actuators

2.6

Wireless communication

2.7

Concluding remarks

Chapter 3

Generic Matlab-Arduino

interface

3.1

Requirements of the interface

3.2

Basic structure

3.3

Pseudo-code

3.4

Detailed code

3.5

Communication protocol

3.6

Concluding remarks

Chapter 4

Testing the Matlab-Arduino

interface

4.1

Maximum sampling frequency of the XBee

4.2

Fixed sampling frequency of the XBee

4.3

AGV velocity test

4.4

Hovercraft velocity test

4.5

Concluding remarks

Chapter 5

Line following using the

Matlab-Arduino interface

5.1

Line tracker

5.2

AGV

5.3

Hovercraft