Redesign of the

(1)

MASTER’S THESIS

2006:268 CIV

THOMAS SJÖGREN

Redesign of the

Real Time Software Platform for the Mechweed Robot

MASTER OF SCIENCE PROGRAMME in Space Engineering

Luleå University of Technology Department of Space Science, Kiruna

(2)

(3)

Abstract

This Degree project work describes the work and considerations done when porting the real time platform for the Mechweed robot from QNX to Windows 2000. A big part of this project is about the work and considerations needed to be thought of when programming a real time platform that should be used and maintained by scientists that are not primary programmers. Because of the old platform not being well suited for the current working scientists, this project work grew beyond a simple porting, to instead rewriting almost all of the platform. This work sets a ground for future development of the real time platform as well as enables for the possibility of making interfaces between the real time platform and for example Matlab or Labview, which both are available for the Windows 2000 operating system. These would be great features for the scientists working on this project, since they could easily, while running the robot or directly after a test run, see Matlab graphs and do calculations on the collected data. The tools that were used for porting was the support from the Windows API and a library called Universal Library.

The program code was written mainly in C++ and C, using Microsoft Visual C++ 6. The porting was successful and code was cut down to less then half of the original size, and thus hopefully easier to work with.

(4)

(5)

List of figures

Figure 1 Picture of the robot from the side. picture acquired from Björn Åstrand...4

Figure 2 Message passing in QNX...7

Figure 3 Drawing of the complete design...10

Figure 4 Round robin scheduling...11

Figure 5 Limitation of access to shared objects...14

(7)

1 Acknowledgements

This report is written as the degree project for the Master of Science programme at Luleå University of technology. The degree project was done at the department for intelligent systems at Halmstad University.

I would like to give my warmest thank to Björn Åstrand, my supervisor at Halmstad University firstly for taking me on as a degree project student on his research project and secondly for the help and guidance throughout the work of this project. Also I want to thank Anita Enmark, my examiner for helping me with report writing and with getting me off to a good start with my project. Special thanks also to my parents and my girlfriend, who has supported me well throughout the work. I have many to thank for helping me through the hard times and sharing the good times throughout this degree project.

2 Introduction

The Mechweed project[12] is a science project at Halmstad University aimed at developing an autonomous machine that removes weed with use of mechanical force, rather then herbicides.

The goal is to give farmers that grow ecological crops a cost-effective alternative to having to employ expensive labour for keeping weed away. This also opens the opportunity for the farmers that today don't grow ecological crops, to in the future change to the ecological alternative.

3 Summary

The aim of this degree project was to get an already working real time platform, for the robot ported from QNX[10] to Windows 2000[18]. Since there already existed a real time platform with a defined functionality[12], this functionality was to be met on the new platform as well.

Also, there were some added requirements and wished for new functionality to be added to the code. So mainly, these were the given requirements for the project:

The program shall be:

• written in C++.

• working on Windows 2000.

• portable.

• maintainable.

The functionality of the program must include:

• Three PID regulators.

• Calculator for steering angle using deviation in angle and distance from the beet row.

• Supervision of hardware.

• Graphical user interface showing hardware status.

The functionality of the program should, if possible include:

• An interface to a differential GPS device, allowing for two sources of location data of the robot.

(8)

The work was divided into work with GUI, testing and development of a design. After this initial part, redesigning, coding, redesigning was the cycle going on, all the time until the function specification finally was completed at the end of the project.

As the project reached the end, all of the goals had been reached except one, the interface to the differential GPS. Another goal was to make a Kalman filter[5] with estimator for filtering the data from the forward looking camera. But due to lack of time, this goal was not met during the project. The work of rewriting and making the complete real time platform work has been a very learning experience indeed. The most giving part has been learning how to write documentation for programs as well as learning about the functionality and differences between QNX and Windows 2000.

4 The Robot

The robots task is to clear weed from sugar beet rows with mechanical means. The reason for this is to be able to grow sugar beets without using any chemical substances for holding off the weed from the fields at a low cost. The other alternative, with no chemical substances, is to have actual labour walking on the fields, taking away the weed by hand, which is very expensive. The robot needs:

• a mechanical tool, to clear the weed.

• a tool to identify were the robot is relative to the crops right now.

• a tool to identify what is weed and what is crop.

• a tool to control that the robot steers along the crop rows

• a tool to control that the mechanical tool does not harm plants.

This is the main needs of the robot and according to these, a set of hardware has been used, developed and proved well working for many years. In section 4.1 you see a break-up of the robot into its constituents.

4.1 What does the robot consist of?

The robot consists of a two separate units, the robot itself, and the part with the weeding tool, following behind the robot on a carriage. The weeding tool part has the tool to take away the weed and a motor running this tool. The control of the tool is done from the main part of the robot, consisting of:

• Three computers.

• Two cameras. One down-looking and one forward-looking.

• Three DC motors.

• Two inductive sensors.

• One potentiometer.

• Three encoders.

• One Joystick.

• Two emergency stops.

(9)

The functionality of the parts are:

Row Computer: - Interfaces with the forward looking camera and the control computer.

- Calculates the angle of the beet row in respect to the current direction of the robot, as well as the offset of the robot in respect to the beet row.

Plant Computer: - Interfaces with the downward looking camera and the weeding tool.

- Controls when the weeding tool shall dig up weed, so it will not destroy plants. It uses its interface with the down-looking camera for knowing when to use the weeding tool and when not to.

Robot Computer: - Controls the three DC motors with help of the angle and offset from the beet row received from the Row computer.

- Interfaces with the joystick, used for manual control.

- Interfaces with the potentiometer, the inductive sensors, the three encoders and the two emergency stops.

The cameras: There are two cameras, one mounted on top of the robot looking forward and one mounted inside the robot looking down.

DC motors: There are three DC motors on the robot. Two for control of speed of the back driving wheels. One for control of the steering of both front wheels.

Inductive sensors: There are two inductive sensors on the robot. They are mounted at the front of the robot. Whenever the front wheels steers too much to the right or to the left, the corresponding inductive sensor lead current, and give feedback to the Robot computer.

Potentiometer: There is one potentiometer at the front left wheel measuring the absolute angle of the wheel. It is used to calibrate the steering encoder when the robot starts up.

Encoders: There are three encoders on the robot. One for each DC motor. They are used as relative angle sensors for feedback to the Robot computer.

Joystick: The joystick is interfacing to the Robot computer, allowing the robot to be controlled by joystick, rather then running autonomous.

Emergency stops: There are two emergency stop buttons mounted on the robot, one in the front and one in the back. Pushing any of these causes the robot to halt action and forces the Robot computer to power up the robot again before the robot can start running.

Brakes: The robot is equipped with two brakes, one for each driving wheel.

Control Electronics: There is a set of relays to control the robot.

(10)

Figure 1 shows a schematic view of the robot:

Figure 1 Picture of the robot from the side. picture acquired from Björn Åstrand.

4.2 The parts of the robot concerning this report

The project presented in this report concerns the work of re-designing the real time platform for the Robot Computer. It includes the software for the Robot computer and the software towards all interfacing hardware. Therefore everything interfacing to the Robot Computer are also a part of the work in this project. This is almost all hardware. All parts of the robot concerns this project except for the weeding tool and the down-looking camera. The forward looking camera is not interfaced to the Robot Computer, but the data calculated by the Camera Computer from the pictures are used. The way that the Robot Computer controls the robot is by three hardware interface cards named: DAS08[8], DDA06[7] and QUAD4[9].

These cards support digital input and output, analogue input and output and encoder input and output.

5 The software functionality

The robot has a few basic tasks to take care of. These include controlling three DC motors, two of these should be controlled to keep the correct speed and the third should be controlled to keep a certain angle. This is implemented by using three PID controllers in the real time platform. Also, the robot has to communicate with the Camera Computer, to receive the Row Data. This was implemented by sending a set amount of bytes every time, and for sending commands to the Camera Computer, a small set of commands were given a single byte value each. The robot also has to be able to communicate with the user through a User Interface.

This is to be able to tell the user whenever there has been some error while running the robot and saying exactly what error it is. This user interface is also needed for the user to chose if the robot shall be controlled by the Joystick or be running autonomous.

(11)

6 The old Design

The old design was implemented in a real time operating system called QNX[10]. The code was written mostly in C , but also in C++. It consisted of a set of processes. Some of the processes were concerned with direct hardware tasks they were performing, like controlling the DC-motors or communicating via the serial link. There were also a couple of processes working as message queues, to pass on messages between the processes. The system was divided into many small modules, each having one process as its core. A lot of different classes were used. For example, there were seven different classes for controllers, instead of simply one. The old design and also the hardware work behind the robot can be find in[1] and [2].

6.1 Module based

The design model was module based. This means that the program consists of many

standalone parts who together form the system. Each module can run separately, and be tested separately. The modules communicate with each other using a self built message passing system, QNX proxies. POSIX signals[11] were also used. The idea of using modules is good.

It makes the code less error prone, since you can make sure, module for module, that it works.

At the same time, this can cause the code to become hard to work with. If you want to make a change in the system concerning more then one module, you might have to change the design as well. This is due to the fact that the functionality of all modules are very isolated from each other. If you want some of the modules to work closer together, redesign will be needed.

6.1.1 The modules

The modules in the old system are as follows:

• Row following.

o Speed control.

o Steering control.

• Failsafe.

• Coordinate.

• Interaction.

• Communication.

• Device Drivers.

The modules were arranged in layers. A top layer, including the Coordination and the Interaction module, a second layer including the failsafe module, row following module and the communication module, a third layer with the speed control module and steering control module and the lowest layer with the device drivers for the hardware and the Communication module for communicating with the camera computer.

6.1.2 Row following

The Row following module was launched from the coordinate module. Its purpose was to calculate the new steering angle by using the angle and offset of the beet row, received from the camera computer. It consisted of one process. This module is a higher order module, ruling over the speed controlling and steering controlling modules. The module communicated with the failsafe module and the coordination module.

(12)

6.1.2.1 Controlling speed

The speed controlling module was a sub module under the Row following module. It consisted of a PI controller used to regulate the voltage to the DC-motors for the driving wheels, thus keeping a constant speed of the robot when moving forward through the field.

The module communicated with the failsafe module and the coordination module.

6.1.2.2 Controlling angle

The angle controlling module was like the speed controlling module located under the Row following module, but regulated the output voltage to the steering DC-motor. It used a PD regulator for maintaining correct steering angle. The module communicated with the failsafe module and the coordination module.

6.1.3 Failsafe

The failsafe module has as main purpose to monitor the hardware. It checked if any emergency button was pushed, if steering was within limits and if power was on. It communicates with the coordinator module.

6.1.4 Coordinate

The coordination module was responsible for coordinating all communication between the modules. Proxies were received and triggered other proxies, or took direct action. From here almost all other modules were started. This module communicated with all other modules.

6.1.5 Interaction

The Interaction module was the module that interfaced the real time platform with the user. It communicated with the coordinate module.

6.1.6 Communication

The communication module was responsible for communicating with the serial

communication. It worked at low level and communicated both with the Row Following module and the Coordinate module.

6.1.7 Device drivers

The device drives consisted of three modules, having one process for each of the corresponding three IO cards. They simply polled at a certain frequency, looking for if any new data should be read from the devices and if any new analogue or digital outputs should be changed.

6.2 Operating system

The operating system choice for the old system was QNX[10]. QNX is a real time operating system. It was chosen in competition with a couple of other real time operating systems, and was well known to the developer.

6.2.1 What is a real time platform?

Real time operating systems allow for parallelism, meaning you can run many different tasks at the same time[3]. This is an advantage in applications where you want one task to take care of one special part of your machine and another task to take care of another part. Other important features of a real time operating system are that it has to have very low interrupt

(13)

fast a real time operating system can respond to an external event. Interrupt latency is the time it takes from when an interrupt occurs until an interrupt handler starts running, and scheduling latency is the time it takes from then end of the interrupt handler runs until further code, not inside the interrupt handle, associated with the interrupt can run and respond to the external event. The most crucial property a real time platform must have is reliability.

6.2.2 How does communication work in QNX?

Built into QNX, there are three means for communicating, namely QNX message passing, QNX proxies and POSIX[11] signals. The QNX message passing uses remote invocation. The QNX proxies and the POSIX signals both uses asynchronous message passing, but implemented in a different way. Remote invocation means that the sender must wait for a reply from the receiver before the sender can continue running code. Asynchronous messaging means that the sender can continue running directly after having sent its message(see figure 2).

Figure 2 Message passing in QNX

The left figure describes the asynchronous model, and the right describes the remote invocation model.

As can be seen, both of these communication methods always demands one process to send the message to a specific process. So if you want for example to change the mode that the robot runs in, you need to send one message to each of the processes. This means that the old design incorporated lots of interprocess communication. In the old design all widely important messages were sent to the coordinator module, who then sent QNX proxies to affected processes.

6.3 Ease of future development

The functionality of the old system implemented in QNX was satisfactory. The program worked and was very robust. But the choice of a very parallel solution with an approach were messaging were central for communication introduced some problems. This caused lots of code for each module to be concerned to communication with the other modules, as well as handling signals. The code was rather nested and consisted of very many lines. This amount of code combined with poor documentation of the code made it hard to maintain.

P ro c e s s A P r o c e s s B

S e n d s m e s s a g e

w a its fo r m e s s a g e

re c e iv e s m e s s a g e re c e iv e b lo c k e d

s e n d b lo c k e d

w a its fo r re p ly s e n d s a re p ly

h a n d le s r e c e iv e d m e s s a g e ru n n in g c o d e

r u n n in g c o d e ru n n in g c o d e

r u n n in g c o d e running code

Process A Process B

Sends m essage

waits for m essage

receives m essage receive blocked

running code

running code running code

(14)

7 Development of the new design

Based on the drawbacks of the old code two things were decided to be central in the new design, namely:

• Ease for future development.

• Extended interface towards user.

The reason for the second of these being so important is that when the robot actually is being run on the fields, it is very good to have a fast and easy interface to the user, showing all errors that can appear as well as allowing for changing PID values and testing all outputs and inputs to the robot. The main reason for the first design requirement is that when the scientists will improve the robot with more functionality, it should be as easy and smooth as possible to read through the documentation and find were in the code to add the new functionality without having to rewrite large parts of the system. But also, the system is kept as small as possible, so that if rewriting is necessary, it won't be huge amounts of lines of code having to be rewritten.

7.1 Low level functions

The start up design process was made using the bottom-up principle, in order to make sure that functionality always could be acquired at all times in the new operating system. The work process was trying to understand all functionality of the old real time platform and reading all documentation about how all input and output channels to the hardware worked. After all this was read, testing was started to try to control all channels via the new installed Windows 2000 on the Robot computer. To be able to test all outputs and inputs, a graphical test utility was developed. It consisted of two windows, one showing all inputs, one showing all digital outputs that could be switched and a menu accessing test routines for testing of the analogue output channels. The functionality of the I/O hardware was tested. Some digital inputs did not work according to the documentation, but was left without measures as the requested robot functionality could still be reached.

7.2 Design considerations

Once the connection with the hardware was up and working, it was time to start to make a design. The idea was to implement a couple of tasks running at different frequencies, with one running on high frequency, checking for hardware errors and the rest running on lower frequencies. For communication between the tasks, some kind of communication similar to the protected objects used in ADA[19] was preferred, since it ensures mutual exclusion in changing data, allows for many to read at the same time and has built in functionality that can be used for synchronization. This means that all tasks must share the same memory space, which in Windows means they have to be implemented as threads, which normally have shared memory, or as different processes using a shared memory server process. The objects themselves was thought of as being implemented as C++ classes. Though, as the C++ class does not have built in support for barriers on their functions, the synchronisation functionality of the ADA protected objects can not be used. Beside the threads and the protected objects, an interface to the hardware and an interface to the camera computer had to be implemented. The method for communicating with the hardware, was to simply build a C++ class containing functions for accessing all different hardware channels. For communication with the camera computer, the old code was reused, since it was working and there was no real need for

(15)

rewriting it. Some means of synchronization had to be used. For this purpose no portable solution was found, Windows native support for events was used.

8 The final design

The final design very much looks like the idea in the previous section. It consists of a set of threads, communication objects and interfaces to hardware and camera computer. The synchronization uses Windows native events. The central threads and their responsibilities are:

• Supervisor and control thread.

o Supervises hardware for errors.

o Controls the three DC motors when running autonomous.

o Runs normally at 100Hz

• Steer thread.

o Calculates steering angle when running autonomous.

o Controls the three DC motors when running joystick mode.

o Calls the end switch procedure, when some end switch has been hit.

o Runs normally at 10Hz, depends on when data is received.

• Communication thread.

o Sends and receives data from the camera computer with help of the communication module from the old code.

o Runs normally at 10Hz, depends on when data is received.

• GUI thread.

o Interfaces to the robot user showing status of the robot.

o Allows for choosing to run the robot autonomous or with help of joystick.

o Allows for changing all regulator parameters between runs.

o Runs at undefined frequency, it just updates when a hardware error has occurred, or when the user pushes any of the buttons on the screen.

The design also implemented a number of C++ classes used for communication between the threads, their names and their contents are listed below:

• Steer class

o The mode variable.

o PID controllers.

o Received communication data.

o Flags for when to send command to camera computer.

o Joystick calibration data.

• Supervisor class

o Flags for indicating errors on different parts of the hardware.

o Flags for indicating what thread should run.

(16)

For accessing hardware, a final C++ class was made , named HW. Figure 3 shows a schematic over the complete final design. For more information see appendix B.

The robot Camera

computer

Universal

Library CamSender thread CamReceiver thread

Cam_com thread HW-class

Steer-class

GUI Supervisor

class

Supervisor thread Steer thread

Figure 3 Drawing of the complete design.

Dataflow is indicated with arrows.

Solid lines is autonomous mode, dashed when in erroneous mode and dash dotted when in joystick mode.

(17)

8.1 The controllers - the sensitive part

The system could be implemented as a soft real time system. This because if some deadline is not met, it will not cause any major damage. The thread that was most important to keep at as high frequency and priority as possible, was the supervisor and control thread. If there is some hardware failure, you want to stop the robot fast, avoiding more hardware damage. The tests showed that the interference from the GUI could disturb the regulators. Measures were taken to minimize disturbance and to make the supervisor and controller thread run as cyclic as possible. To avoid instability, the speed regulators has got anti windup[6]. The speed regulators are PI regulators and the steering regulator is a PD regulator. All regulators are implemented as one regulator function call for each of the regulators. All regulator parameters are stored in one C++ class. All the time sensitive code is in one thread. This thread always runs with highest priority and is started up with an offset to the other threads. This minimizes the chances that any other thread wants CPU time concurrently. The problems found during testing were decreased when taking down the priority for the GUI thread and finally eliminated when making the GUI update only when the robot was stopped. This did not reduce the functionality of the GUI.

8.2 The operating system

The operating system was a challenge in itself. Merely because the system gives higher priority for threads that interfaces with the user. Windows 2000 has a heavy core, therefore it is not wise to run many parallel processes, since it would cause considerable time wasted switching between processes. The information in this section of the report comes mostly from [4], but also from discussions with Björn Åstrand at the Department for Intelligent Systems at the University in Halmstad. Windows is made as a desktop operating system. Made to always respond to user at all times. To minimize computation time for underlying working threads are not as important for Windows 2000. As Windows 2000 is not suitable for running lots of parallel processes, the tasks are implemented as threads, running within one process, thus sharing a common memory space. This is what allowed for the easy and nice solution of using shared C++ classes. Also when running threads in parallel there is a risk that when running too many threads, you can't have one of threads running cyclic at 100Hz. Even if the overhead caused by switching between threads is considerably lower then when switching between processes, there is still a risk that it can cause problems.

Scheduling considerations

When running parallel tasks on a single processor, all tasks must share the time of the processor according to some scheduling policy. A usual way of doing it, is by using round robin. In round robin all tasks that wants to run code stands in line and runs a little time each and then the system switches to the next task and so on. This is illustrated in figure 4:

t a s k 5 ta s k 4 t a s k 3 t a s k 2 t a s k 1

r e a d y q u e u e r u n n in g

Figure 4 Round robin scheduling

Illustrates how Round robin scheduling works, which is the normal scheduling for threads with equal priority.

In Windows 2000, every thread is normally given different quanta, meaning different amount of time to run code each time they are allowed to run. The minimum value of this time is

(18)

the ready queue if they want. If you would be running three threads parallel and two of these would take up their whole timeslot, it would be impossible for a thread to run at a frequency of 100Hz. This leads to a definite operating system limitation. There is though a workaround for this, and that is to instead of running a thread, you would be calling a function repeatedly from a special kind of timer. Luckily there is no thread running heavy code, and the deadlines are met if not too many other processes are running(see Appendix A for discussion). Another problem is that Windows 2000 normally would give a thread that updates graphics a higher priority for a short time, causing it to be able to sneak before other threads in the waiting line to run. Windows 2000 also normally would give the foreground window more quanta, thus possibly refusing other threads to run at wanted frequency. Both of these last features on Windows 2000 can be disabled. It is still worth mentioning for people doing similar work that these issues must be given concern.

(19)

8.3 How is communication implemented?

Communication between the threads are both used for synchronization and for exchanging data. The data exchanged is divided into:

Row data:

The data that is received from the camera computer is data concerning how the robot is located in respect to the beet row it is following. The offset is the distance from the robot to the beet row in a direction perpendicular to the robots current driving direction. The angle is the angle from the robots driving direction to the beet row. This data is used to calculate a suitable new steering angle for the front wheels.

Steering angle:

This is the angle calculated by the steer thread for the front wheels. It is read by the supervisor and control thread for each loop and used as reference angle for the PD steering regulator.

Hardware error flags:

When a hardware error has occurred, the supervisor thread sets an event and changes one of the error flags in the supervisor class, to show what hardware caused the error. The GUI thread receives the event and looks in the supervisor class for the error, and then shows the information to the user.

Mode the robot is running in:

The Robot mode is set by the GUI thread in the steer class from the start. All other threads can access this information and change their mode accordingly. The mode can be changed by the supervisor and controller thread when an error has occurred.

Send command flags:

These can be set by any thread. They are used to show the communication thread when to send a command to the camera computer, telling it to start sending or stop sending data.

Thread status flags:

These flags are set by all threads when they start up and are used by the thread to see if it shall continue running. The GUI thread can change these flags to terminate all threads when the user wants to close the GUI window of the program.

All of the above simply uses variables inside C++ classes that are shared by all threads, were some threads sets the variables and most of the threads simply read the variables. To ensure that only certain threads can write to some special variables, the friend declaration is used inside the class combined with not having any public function for changing these limited access variables. What the friend declaration does is that it allows the thread declared as a friend to manipulate private data, that is not accessible from the outside. The mechanism is illustrated in figure 5.

(20)

Public access

private variables

get friend access

normal thread

friend thread Figure 5 Limitation of access to shared objects

The figure shows how access limitation is done in this project, with help of the C++ friend declaration.

The meaning was to make an object similar to the ADA protected objects. The implemented objects are not exactly the same, but at least some similarities can be seen:

• Everyone can read all data at any time.

• When someone shall change data mutual exclusion is ensured.

The mechanism used for synchronization is the Windows native events. Events are special objects created in one of the threads. They are used for synchronization. Thread can do waits for an event. When the event is signalled all threads waiting for the event are put in the ready queue, ready for execution. There were two events used in the program, one for synchronizing the communication thread with the communication module, when data had been received, and one for the steer thread synchronizing with the communication thread for when the data had been successfully stored in the steer class.

9 Results and discussion

At the start of this project, lots of work was put into reading and trying to understand a very big real time platform implemented on the QNX operating system. From the beginning of reading into all documentation, it was clear that the old model was made unnecessarily big and unnecessarily too generally coded. So it was decided it was time to reprogram everything.

After this new design had been finalized it ended up at no more then 26 source files having a total of 218kb of code and comments. In the old design, there were 142 files and 801kb of code and comments. So the code is approximately one fourth in amount of lines and one fifth in amount of files. Having brought down the code to this size while still maintaining functionality, does further maintenance and improvement of the code much easier. Keeping the code short and easy maintainable has many advantages. It gives most likely smaller executables. It has much lower risk of runtime errors, since you do not depend on as many other files in the build environment as earlier. It is also a big advantage for the future developer who will implement new functionality for the design, since he needs to read less lines of code. And because the code is so short, it is possible by only editing a few files, to change most of the design structure.

Another big advantage of the new design is that the code is developed from a perspective of writing code that is close to the actual hardware. In the threads, direct hardware calls, and direct changing of communication variables is done in a way that it can be easily seen what happens. This makes it easier to maintain readability of the code for people that hardly has

(21)

When having too much object oriented code, you always run a big risk that the developer is more focused on making pretty interfaces to make the code as abstract and encapsulated as possible, were the actual work of the tasks are split up into many small parts that can be time consuming to find and put together.

The old design is very good for larger real time applications. For example for a real time platform for space, the old model could well have been used. But still, it's extensive use of message passage should preferably be changed to the better means of communication used in the new design, were shared protected objects with different access rights for different threads is used. The only real case were message passing is good, is in distributed systems, where you need to send a copy of the data to another physical computer. The main reason why the new message sharing design is better is that it allows for easier schedulability calculation.

10 Conclusion and future prospects

The main conclusion you can draw from this project is that you don't need a real time operating system for running this real time system. A desktop operating system with support for parallelism, like Windows 2000 works. This makes it easier for the robot user to run the robot, since he or she can use an operating system he or she is familiar with. But if you have a hard real time system, it is strongly advisable that you use a real time operating system, as well as when you have a real time system that demands responses at less then 10ms. This limit being around the limit were you can not trust the periodicity of threads in Windows. The reason for the advice not to use Windows 2000 for a hard real time system is that a hard real time system is never allowed to fail, and Windows 2000 can sometimes, if you start too many programs, be too slow to respond in time on a time critical interrupt. It is also important that if you program for Windows 2000, you always make sure to set up the quanta's and the priorities correctly, otherwise chances are that your system might get unstable.

For future work with this project, when the planned implementation of an interface to GPS is done, it would be great for stability also to implement a Kalman filter with estimator.

Implementing both these things would most probably lead to great enhancements in the performance of the robot. Other improvements for the future could be to build an interface towards Matlab, so that you can see Matlab graphs displaying data while the robot is running.

Though, care must be taken when this is done, since there are risks that graphs can cause disturbances for the control loops. All of the new features would of course demand lots of new testing. Also possible future additions would be to integrate the hardware testing program into the robot program, for easier and faster diagnostics, as well as to build real feedbacks for all relays on the robot.

No matter were the Mechweed project goes in the future, this project has shown that the program controlling the robot real time platform works well running under Windows 2000 and all requirements of functionality has been met.

(22)

References:

[1] Becker, B., (1999), Development of the Real Time Software for an Agricultural Robot

Halmstad, Halmstad University. Diploma Project in Technical Computer Science [2] Becker, B., (1998), Development of the Process Hardware and the Device Drivers

for an Agricultural Robot

Halmstad, Halmstad University. Final Project In Technical Computer Science [3] Burns, A and Wellings, A., (2001), Real-Time Systems and Programming

Languages

Harlow: Pearson Education Limited, ISBN: 0-2017-2988-1

[4] Solomon, D and Russinovich, M.,(2000), Inside Windows 2000, third edition Redmond: Microsoft Press, ISBN: 0-7356-1021-5

[5] Kalman, Rudolph Emil, (1960) A New Approach to Linear Filtering and Prediction Problems (2006 09 01)

http://www.cs.unc.edu/~welch/kalman/media/pdf/Kalman1960.pdf [6] Franklin et al,(2002), Feedback Control of dynamic systems 4th edition,

New Jersey, Prentice Hall, ISBN: 0-1303-2393-4 [7] DDA06 (2006 09 01)

http://www.measurementcomputing.com/PDFManuals/pcim-dda06-16.pdf [8] DAS08 (2006 09 01)

http://www.measurementcomputing.com/PDFManuals/pci-das08.pdf [9] QUAD4 (2006 09 01)

http://www.measurementcomputing.com/PDFManuals/PCI-QUAD04.pdf [10] QNX (2006 09 01)

http://www.qnx.com/developers/docs/qnx_4.25_docs/qnx4/

[11] POSIX signals (2006 09 01)

http://www.qnx.com/developers/docs/momentics621_docs/neutrino/lib_ref/s/signala ction.html

[12] Mechweed project (2006 09 01)

http://islab.hh.se:8080/islab/islab/projects/mechweed.html [13] Matlab (2006 09 01)

http://www.mathworks.com/products/matlab/

[14] Labview (2006 09 01) http://www.ni.com/labview/

[15] Windows 2000 API (2006 09 01) http://msdn.microsoft.com/

(23)

[16] Universal Library (2006 09 01)

http://www.measurementcomputing.com/pdfs/universal-library.pdf [17] Microsoft Visual C++ 6 (2006 09 01)

http://msdn.microsoft.com/visualc [18] Microsoft Windows 2000 (2006 09 01)

http://www.microsoft.com/windows2000/

[19] Ada reference manual (2006 09 01) http://www.adahome.com/rm95/

Appendices:

There are two appendices in this report. Appendix A discusses the schedulability of the system. Appendix B is a complete function specification for the program.

Appendix A: Schedulability

Schedulability can be studied in many ways. The problem is that it is impossible in this system to predict what other programs might run on the computer at the same time at the same priority, thus taking up CPU time. Though there is a formula derived by Liu and Layland[3]

saying that for n periodic tasks with unique periods, all tasks will meet their deadlines if the CPU utilization, U in the formula, is:

∑

=

−

≤

=

n

i

n i

i T n

C U

1

) 1 2 (

/ (1)

Where Ci is worst case execution time and Ti is period time for the task with index i.

The thread that runs the most code is the supervisor and controller thread. There were measurements done on the execution time of this thread. Running the thread 10000 times, an average of 0.2ms per loop was acquired. The other threads were never timed, but since the code for all of them is shorter, they most likely run for a shorter amount of time. To assume an extremely bad case, we assume the execution time to be 1ms per loop for all threads. When talking all threads, we talk about the three periodic threads, namely the supervisor and controller thread, the steer thread and the communication thread. Inserting these values in equation (1) gives:

∑

=

= + =

+ +

= +

=

3 1

015 . 0 210 / 100 3 100 10

) 1 1 1 / (

i

i T

C

U (2)

0.78 ) 1 2 (

3 ³ − = (3)

Since 0.015 clearly is less then 0.78, the CPU usage is far from it's limits. This leads to the following conclusion:

If good care is taken to not running processor heavy code at the same time as the program, ensuring that all threads makes it's deadlines shall be no problem at all.

(24)

(25)

Utfärdare /Issued by Datum /Date Beteckning / Ref. Sida / Page

Thomas Sjögren 2006-09-04 1 (31)

Ärende / Subject Dokumenttyp / Document type

funktionsspecifikation

Function specification

Godkänd av / Approved by

Appendix B function specification

Filename : Funktionsspecifikation.doc

Latest revision : 1.0

Written by : Thomas Sjögren

Written date : 2006-04-17

Distribution

Reviewer : Björn Åstrand

For further information : Björn Åstrand

(26)

funktionsspecifikation

1 INTRODUCTION ...4 1.1 SUMMARY...4 1.2 REFERENCES...4 1.3 DEFINITIONS...4 1.4 CHANGES BETWEEN DIFFERENT REVISIONS OF THIS DOCUMENT...5 2 GOALS REACHED DURING PROJECT ...5 2.1 DEMANDS NOT FULFILLED...6 2.2 WISHES AND POSSIBLE FUTURE EXTENSIONS...6 3 SPECIFICATION ...7 3.1 FUNCTION DESCRIPTION...7 3.1.1 Limitations ...8 3.2 DIVISION INTO SUB FUNCTIONS...8 3.2.1 Main ...9 3.2.2 Communication module ...10 3.2.2.1 cam_receive ...10 3.2.2.2 cam_send ...10 3.2.2.3 comm_shutdown...10 3.2.2.4 comm_startup ...10 3.2.2.5 CamSender...10 3.2.2.6 CamReceiver...10 3.2.2.7 Synchronization in the Communication module...11 3.2.3 Cam_com thread ...12 3.2.4 Supervisor thread ...13 3.2.5 Steer thread ...14 3.2.6 Synchronization between the Communication thread, the Steer thread and CamReceiver...15 3.3 INTERFACE TO USERS, PROGRAMS, LIBRARIES OR OS/HW...15 3.3.1 GUI ...15 3.3.1.1 Startup...17 3.3.2 INI-interface...17 3.3.3 BOOST ...17 3.3.4 Test-GUI...18 3.4 STATUS/ERROR HANDLING TOWARDS USERS, PROGRAMS, LIBRARIES OR OS/HW...18 3.5 ALGORITHMS AND DATA STRUCTURES RELEVANT TO THE FUNCTION...20 3.5.1 HW class ...20 3.5.1.1 The private members...21 3.5.1.2 The member functions ...22 3.5.2 Supervisor class ...24 3.5.2.1 Private member variables:...24 3.5.2.2 Public member functions: ...25 3.5.2.3 Friends and control: ...25 3.5.3 Steer class ...25 3.5.3.1 The members: ...25 3.5.3.2 The functions: ...26 3.5.3.3 Friends and control: ...26 3.5.4 The Controller_vars structure: ...27 3.5.5 The COM structure: ...27 3.6 THE IO STRUCTURE...28

(27)

funktionsspecifikation

4 BASE FOR DECISIONS ...28

5 ATTACHMENTS...28 5.1 KNOWN ISSUES...28 5.2 THE BUILD ENVIRONMENT...29

List of Figures

Figure 3-1 Flowchart over Main thread...9 Figure 3-2 Flowchart of Communication thread...12 Figure 3-3 Flowchart for the Supervisor thread...13 Figure 3-4 Flowchart of the Steer thread...14 Figure 3-5 Flowchart for Startup function...17 Figure 3-6 All private and public members of the HW class...21 Figure 3-7 Constructor of HW class...22 Figure 3-8 The Endswitch procedure...23 Figure 3-9 The HW class...24 Figure 3-10 The Steer class...25 Figure 3-11 Controller_vars struct...27 Figure 3-12 COM struct...27 Figure 3-13 The IO structure...28 Figure 5-1 Tree view of the complete build environment...31

(28)

funktionsspecifikation

1 Introduction

1.1 Summary

The main purpose of the program is to control the speed and steering of the robot. The program uses the input from another computer that is connected to a forward-looking camera. The program also has a graphical user interface that includes a status display showing the health of the robot. Also attached to the program is one test program that allows for an easy access to all hardware of the robot and with some test-routines included.

The goal is that this program is a ground for further development for the platform, so if the final version within this project is not perfect, it must be viewed at as a beginning of a remake of the design.

1.2 References

[1] DDA06 data sheet fall 2005 [2] DAS08 data sheet fall 2005 [3] QUAD4 data sheet fall 2005

[4] Becker, B., (1999), Development of the Real Time Software for an Agricultural Robot Halmstad, Halmstad University. Diploma Project in Technical Computer Science [5] Becker, B., (1998), Development of the Process Hardware and the Device Drivers for

an Agricultural Robot

Halmstad, Halmstad University. Final Project In Technical Computer Science [6] Burns, A and Wellings, A., (2001), Real-Time Systems and Programming Languages

Harlow: Pearson Education Limited

[7] Solomon, D and Russinovich, M.,(2000), Inside Windows 2000, third edition Redmond: Microsoft Press

1.3 Definitions

Thread A Thread is a subprocess used in Windows 2000(c). Inside a process, you can have many threads. All threads share the same common memory.

DAS08 DAS08/JR, one of the hardware interface-cards used by the robot. DAS08 is used for digital output, to control relays. This card is made by Measurement Computer(inc)

(29)

funktionsspecifikation

DDA06 DDA06, one of the hardware interface-cards used by the robot. DDA06 is used for analog output, to the DC-motors. This card is made by Measurement Computer(inc) BOOST The BOOST library is a big C++ library developed for increased portability of C++

code and for more easier readable code. BOOST is constantly being more and more improved by a big community of C++ developers, many of these members of the group forming the ANSI C++ standard. Thus, writing code that uses BOOST is likely a very good thing to do for the future.

UL Universal Library, a library downloadable from www.measurementcomputing.com, this library is developed especially for usage with the hardware interface cards developed by measurement computing, as are all cards used in this project.

HAL Hardware Abstraction Layer, the interface between the higher level design in this project and the functions accessing the hardware. In this project UL is used as one HAL and above that HAL, there is another HAL implemented with the C++ class named HW.

INI-file A standard format for files used to initialize programs.

Overlapped call An overlapped call to read IO causes the read operation to run by itself and allows the calling function to keep running. Usually the caller later will wait for an event that the overlapped read sets when finished. Then it reads that return of the call to the overlapped read.

1.4 Changes between different revisions of this document

This is version 1.0 the first and also latest version of this document.

2 Goals reached during project

The following goals has been reached:

• The robot can be controlled from Windows 2000.

• A complete test suite has been developed for easier diagnostics.

• A graphical user interface has been developed which allows for the user to see when the robot is stopped, what is the cause and also test to see for example if the problem that lies outside of the robot has been resolved before restarting autonomous operation again.

• The complete solution has been proved to work correctly under Windows 2000, and deadlines of all threads are met. This assumes that no other heavy workload is on

(30)

funktionsspecifikation

• All important variables can be changed using an ini-file that is read in at start of program.

2.1 Demands not fulfilled

The targets that was not successfully reached are listed below:

• No extensive testing.

• No implementation done for allowing input from differential GPS data.

• No estimator for usage with a Kalman filter, this was not a demand from the start though.

2.2 Wishes and possible future extensions

Future improvements that would be a great asset would be:

• Extensive testing and implementation of a Kalman filter using both a calculated signal from GPS and from the forward looking camera.

(31)

funktionsspecifikation

3 Specification

The program takes care of information coming in via analogue channels, digital channels and a serial link and with help of these and of digital and analogue outputs it controls the robot, either in an autonomous mode or in a mode were a joystick controls the robot. For the autonomous mode there are regulators for keeping correct speed of two driving wheels at the back of the robot and keeping correct angle of the two front wheels.

As the purpose is to control a realtime system with this program it is very important to think that the GUI is not the priority and that the realtime loops are to be on highest priority. They have deadlines they really should try to meet. If they do not meet the deadlines, normally nothing happens, but it can cause instability to the controllers.

To access the hardware, a HAL-library called UL is used. Between UL and the threads there is another HAL implemented through a C++ class named HW.

To read in ini-files and also to be able to save ini-files, a small library containing a couple of files was developed. The usage of this ini-library is attached to this documentation.

For most of the code to be as portable as possible, the Boost.Thread library has been used, which is a portable multi-threading library.

3.1 Function description

The program consists of one main function and six associated threads. It also consists of three C++

class objects. The threads are the following:

• The GUI thread that takes care of input and choices from the user and displays status for the user on screen. This thread is called GUI.

• The Steer thread takes care of the steering, it has a couple of different ways in which it works.

It takes care of steering from either the joystick or from information from the other computer, which is accessed through the Communication threads. When using information from the other computer, it calculates a new steering angle. This thread is called Steer.

• The Communication threads are actually three threads, two of these is part of the old design, as a part of its own Communication module. The third is the current programs interface to the module. This thread is called Cam_com. This thread merely receives and sends messages to the other computer through the Communication module. But in case of loss of incoming data for a too long time, this thread has the ability to block all other threads and notice the user via the GUI.

(32)

funktionsspecifikation

thread makes sure the robot stops and the GUI will indicate what error occurred. The thread also takes care of controlling all DC-motors with help of the PIDs included in the steer_obj.

In a more sequential manner, this is what happens when the program starts up:

• The program first starts up and starts running the communication module.

• After this, all other threads are started and the GUI comes up.

• Once the GUI is up, the user has the ability to chose whether to start running the robot in joystick mode or it autonomous mode. The user can also chose to test if the communication with the computer controlling the forward looking camera work.

3.1.1 Limitations

The main limitations on the program are that the number of programs running at the same time. Since if too many programs run at the same time, they can cause the supervisor thread to become laggy and inconsistent in its controlling loop, thus causing instability on the feedback system.

3.2 Division into sub functions

The program is divided into seven threads:

• The Main-thread.

• Two threads in the Communication module.

• The higher level Communication thread.

• The Supervisor thread.

• The Steer thread.

• The GUI thread.

All above threads are explained in the coming sections except for the GUI thread who can be find in section 3.3.1

(33)

funktionsspecifikation

3.2.1 Main

What Main does is startup everything and then just wait until the user pushes the SHUTDOWN button in the GUI thread. All code for Main is found in the file Main.cpp. On the right you can see all steps(Figure 3-1):

First the three global objects used among all threads are created.

And each one of them does appropriate initializations in it's constructor.(more on the classes in 3.3 and 3.5)

After this the, three OS-specific settings are done. First the base priority of the Process is set, then the scheduling quanta granularity is changed to 1ms and finally priority boost is disabled. The reasons for these settings is for making the Supervisor thread run as undisturbed as possible and also for running on as correct frequency as possible. More on these can be find in the other part of the report considering Windows 2000.

Then the steermode property in the Steer class is set to halt. This is so that when all threads are started up, they will not start running the robot.

Now the Communication module is started, which means that its two threads starts running and that the communication link is established.

After this the higher level thread, Cam_com is started, which uses the Communication module to communicate with the forward looking camera computer.

Then the rest of the threads are started and initialized. More on each initialization in the coming sections.

After all of these threads are started, Main just waits until all threads has finished running it's code and then it resets the scheduling granularity to windows standard.

Setting Process Priority Class

Disabling Process Priority Boost

Sets the quanta granularity in scheduling to 1ms

Sets the mode in steer instance to

halt Creates a global

instance of HW

Creates a global instance of steer

Creates a global instance of supervisor

Starts up communication

module

Starts up the Steer Thread

Starts up the supervisor thread

Starts up the GUI thread

Initilizes thread variables and then

enters it’s loop

enters it’s loop Initilizes the Serial

Link and then starts the receive and send threads

Starts up the Cam_com thread

(34)

Thomas Sjögren 2006-09-04 10 (31)

funktionsspecifikation

3.2.2 Communication module

The Communication module is code that is taken from the old design, but was not well documented aside from in the code. Therefore it follows a more easier to understand documentation here:

The files included in the Communication module are Camera.c, Camera.h, Comechw.cpp, Comechw.h, in.c och in.h.

The "motor" that drives the module consists of two threads, one sending serial data and one receiving serial data, the have the name CamSender and CamReceiver. The main functions used from outside the module are cam_receive, cam_send, comm_shutdown and comm_startup. Below follows explanations for what the functions used from outside does and then how the threads works.

3.2.2.1 cam_receive

Returns the last received data from the other computer. If there is no working link the data returned here is unknown. To actually know when there has been data received, you need to wait for the two events, FinReadWakeCam_com and FinReadWakeSteer to be in signalled state. Those are set to signalled state by CamReceiver when it has received some data.

3.2.2.2 cam_send

Copies the passed argument, which is the message to be sent, to a local send-variable named send_data. Then the function sets the SendEvent which is the Event CamSender always waits on.

3.2.2.3 comm_shutdown

Calls the function release_resources which closes some of the synchronization objects and then checks if the two module threads are currently running. If any or both are running, then the EndEvent is set, which causes both CamReceiver and CamSender to close down after they are confirmed finished threads, the rest of the synchronization primitives are closed.

3.2.2.4 comm_startup

Opens up the serial link using COM1, creates the synchronization objects. If there was any error creating some synchronization object or setting up the serial link, then it does just as in comm_shutdown, it calls release_resources.

3.2.2.5 CamSender

The thread just waits for any of the two events EndEvent and SendEvent. If EndEvent is received, then CamSender simply closes down. If SendEvent is received, then first the data put into the local send_data variable is copied to another local thread variable. Then _cam_send is called with this new variable, _cam_send finds out what kind of message is sent(just a command or if it is data also), and then calls another function which calls another function, which finally sends the message in the correct way. In that final step it also the message is divided up into 8bit pieces.

3.2.2.6 CamReceiver

(35)

Thomas Sjögren 2006-09-04 11 (31)

funktionsspecifikation

in read_chars, is complete. When the event is set, it causes read_chars to keep running and finally _cam_receive returns the received data to the thread. Now the thread copies the data to the local variable that cam_receive always reads from. After this, the thread sets the two Events FinReadWakeCam_com and FinReadWakeSteer to signalled, which allows Cam_com and Steer to both go out of their wait-states.

3.2.2.7 Synchronization in the Communication module

Below is an attempt to explain how the synchronization is done in the Communication module:

There are two important Mutexes, ReceiveMutex and SendMutex as well as two important Events, SendEvent and ReceiveEvent.

The Mutexes are there so that when CamSender or CamReceiver is running code, cam_send or cam_receive will not interfere. So if cam_send is called when CamSender is sending a message, then cam_send will have to wait until it copies its message to the temporary variable were the message is stored until being sent. For cam_receive its so that it has to wait until it copies the received message, until the new received is stored there by CamReceiver.

The ReadEvent is used only inside readchars and indicates a read operation on the serial channel is complete. The SendEvent is used by cam_send to show for CamSender that it is time to send newly loaded data.

This shows why the ReadEvent can not be used for outside to indicate it is time to call cam_receive.

If cam_receive starts running code before read_chars finishes code, then cam_receive locks the ReceiveMutex and copies the old data, instead of the new data.

Redesign of the

MASTER’S THESIS

THOMAS SJÖGREN

Redesign of the

Real Time Software Platform for the Mechweed Robot

Abstract

Table of Contents

List of figures

1 Acknowledgements

2 Introduction

3 Summary

4 The Robot

4.1 What does the robot consist of?

4.2 The parts of the robot concerning this report

5 The software functionality

6 The old Design

6.1 Module based

6.1.2.1 Controlling speed

6.1.2.2 Controlling angle

6.2 Operating system

6.3 Ease of future development

7 Development of the new design

7.1 Low level functions

7.2 Design considerations

8 The final design

8.1 The controllers - the sensitive part

8.2 The operating system

8.3 How is communication implemented?

9 Results and discussion

10 Conclusion and future prospects

References:

Appendices:

Appendix A: Schedulability

∑

∑

funktionsspecifikation

Appendix B function specification

funktionsspecifikation

Table of contents

funktionsspecifikation

List of Figures

funktionsspecifikation

1 Introduction

1.1 Summary

1.2 References

1.3 Definitions

funktionsspecifikation

1.4 Changes between different revisions of this document

2 Goals reached during project

funktionsspecifikation

2.1 Demands not fulfilled

2.2 Wishes and possible future extensions

funktionsspecifikation

3 Specification

3.1 Function description

funktionsspecifikation

3.2 Division into sub functions

funktionsspecifikation

funktionsspecifikation

funktionsspecifikation