A simple MATLAB simulation for camera based control of ...data.mecheng.adelaide.edu.au/robotics/€¦ · robsim A simple MATLAB simulation for mobile robots 5 1. Introduction This

robsim

A simple MATLAB simulation for

camera based control of mobile robots

F. Wörnle, May 2008

robsim A simple MATLAB simulation for mobile robots

2


3

Contents 1. Introduction........................................................................................................ 5 2. Using robsim ..................................................................................................... 9

2.1 The windows of robsim .................................................................................9

2.2 Tracking the robot........................................................................................15

2.3 Defining a new robot ...................................................................................26

2.3.1 Loading a new representation ..............................................................26

2.3.2 Capturing a new robot representation using the camera......................32

2.4 Training the vision system to “see” specific colours ...................................35

2.5 State estimation............................................................................................38 Appendices ............................................................................................................. 39

Appendix A – TODO list.......................................................................................41 References.............................................................................................................. 43


4


5

1. Introduction This document describes a small set of MATLAB m-scripts which can be used to learn about camera controlled mobile robots. The central simulation is robsim, a GUI based m-script which gives access to all available elements of the simulation environment (Figures 1-1 and 1-2).

Figure 1-1 Mobile robot simulation robsim – main GUI


6

Figure 1-2 Trace output window of robsim Robsim has been written to assist students of robotics and mechatronics degrees in developing algorithms for the control of mobile robots based on visual feedback from a ceiling mounted camera. The simulation provides a virtual environment, which closely resembles the real environment of the laboratory. Replacing the live stream of images from the camera by simulated images, the students can develop their robot control algorithms off-line, without the need for access to the actual hardware such as the camera and/or other laboratory equipment. The resulting algorithms can then be verified using real robots. The seamless integration of robsim with the camera control toolbox FireWire Vision Tools (www.mecheng.adelaide.edu.au/robotics/ -

Downloads → FireWireVision), ensures a close match between simulation and the real application. In fact, the image processing algorithms developed off-line should


7

perform much the same as when applied to a stream of live images from the real camera. A number of callback functions have been implemented for the definition of a robot model, an optional on-line parameter estimator as well as the actual controller algorithm. These callback functions are called at various stages of the main simulation loop. The use of callback functions has the advantage of separating the code of the control algorithm (to be written by the students) from the code of the simulation itself (remains unaltered). To install the simulation, simply extract the contents of the archive to a local folder and run the central m-script robsim. Robsim is distributed as ‘Free Software’ under the terms of the GNU General Public License Agreement. This grants potential users the right to copy, re-distribute and/or modify the code to suit their individual needs. The present release of robsim has been developed and tested using MATLAB R2007a. Comments and bug reports are always welcome. Please direct your feedback to: Frank Wornle (fwornle @yahoo.co.uk) May, 2008


8


9

2. Using robsim

2.1 The windows of robsim

This chapter is a short tutorial of how to work with robsim. It is intentionally kept brief to highlight the main features of the simulation without mentioning every little detail. This is because both writing as well as reading manuals are extremely boring activities. Users are therefore encouraged to simply “have a wee play” with robsim to figure out its abilities and limitations. The simulation is launched by issuing robsim at the command line prompt. When running for the first time, robsim loads the default robot image file robot.jpg and computes 36 rotations (0° to 350°). These 36 robot phases will later be used when simulating the robot. Upon calculating the robot phases, the background is initialized. At present, the image file background.jpg is loaded and the brightness of the rightmost third of the image is reduced to 80% of the original value. This is to simulate a shadow area – the image processing algorithms need to work under varying lighting conditions. The thus produced background image is then stored in the global display variable displ.myBGdat0. Customizations of the provided background image can be obtained from modifying this variable. For this, the simulation calls the callback function adjustBackground.m, which provides the user with a mechanism for placing objects and other visual markers in the work area. As an example, the default callback function adjustBackground simply draws a red square somewhere near the top of the workspace. Once the image of the robot as well as of that of the background has been loaded into the MATLAB workspace, the simulation initializes an outline representation of the robot. The latter provides information about the orientation of the robot as well as its centroid. At this stage, the main GUI window of robsim should look as shown in Figure 2-1.


10

Figure 2-1 Starting robsim – main GUI window Following the display of the robot, robsim opens the traces window in which the history of the true robot position (centroid, x and y) as well as its true orientation

(angle φ) are plotted. The colour chosen to represent the real values in these plots is pink (or, more posh, ‘magenta’). Figure 2-2 shows the traces window for a robot which is simply spinning around its central axis (the default behaviour). When the ‘tracking’ button is pressed, these graphs also show the traces of the measured robot position and orientation. The latter is found by analysing the image using the command ImgProcSilent from the FireWire_VisionTools toolbox. This command has been included in the distribution of robsim. The measurements are plotted in green. When the image processing algorithm is unable to determine the position and/or orientation of the robot, the last valid measurement is used instead. In this case, the display colour is switched to black.


11

In addition to the actual measurements, the corresponding error variables

(“measurement minus true value”, ∆x, ∆y and ∆φ) are displayed, together with the respective error distributions.

Figure 2-2 Traces window of robsim Note that, in Figure 2-2, a systematic error is made in measuring the centroid coordinates of the robot: The measured centroid coordinates oscillate around the invariant true values. This is because the processed images are simply rotated copies of one another (the 36 robot phases). Therefore, the relative measurement error remains invariant throughout the entire simulation, e.g. always “a tiny bit left of the true centre”. Rotating the robot thus leads to the observed oscillatory behaviour of the centroid error.


12

A similar effect can be observed in the orientation error, where the error log appears in form of a saw-tooth waveform. This can be explained with the finite number of robot phases (36) and the thereby causes granularity in the orientation (10°) of the displayed robot. Thus, when the true angle increases linearly, the orientation measurement error also increases linearly, until the simulation switches to the next discrete display angle (+10°). This happens, when the angle of the true orientation goes through the mid-point between two adjacent display angles (e.g. at 15°, 25°, 35°, etc.). At this moment in time, the error switches from approximately +5° to near -5°. This is what can be observed in Figure 2-2. Following the display of the traces window, robsim opens a further window for the display of information about the optional online parameter estimation (see Figure 2-3). When the online parameter estimation is switched on the latter logs the time histories of the parameter values as the robot drives around. This is useful information when studying the behaviour of various online estimation algorithms. The true values are indicated using small crosses. Note that in Figure 2-3, the convergence is extremely slow – if the observed behaviour can be considered ‘convergent’ at all. This is due to the fact that the robot is currently just spinning around its centroid and, therefore, many dynamic modes of the robot model do not get excited. The attempt of estimating the model parameters from this inadequate excitation is doomed to fail.

Figure 2-3 Online parameter estimation, spinning robot This quickly changes as the mode of operation is switched from ‘spin’ to ‘drive around’ (Figure 2-4). The estimated parameters now tend towards their true values – some anyway. As with every system identification procedure, both convergence rate and identificability strongly depend on the chosen input signal driving the robot.


13

Figure 2-4 Online parameter estimation, random walk motion To stop the simulation, close either the main GUI window of robsim or the trace window. Upon closing robsim a batch estimation of the parameters is performed using the longest available log variable record. The results of this estimation, as well as the corresponding online parameter estimation are displayed in the MATLAB command window as well as in an additional figure window (see Figure 2-5): ------------------------------------------------------------------

True value Batch estimate Online estimtate

------------------------------------------------------------------

a1X = 1.9375 a1Xest = 1.9385 a1XestRLS = 1.9527

a2X = -0.9375 a2Xest = -0.93862 a2XestRLS = -0.95351

b1X = 0.20833 b1Xest = 0.17938 b1XestRLS = 0.75591

b2X = 0.20833 b2Xest = 0.1128 b2XestRLS = -0.43936

d1X = 8.3333e-006 d1Xest = 0.11881 d1XestRLS = -0.41628

a1Y = 1.9375 a1Yest = 1.9412 a1YestRLS = -2.2845

a2Y = -0.9375 a2Yest = -0.94145 a2YestRLS = 3.5295

b1Y = 0.20833 b1Yest = 0.15193 b1YestRLS = 18.6412

b2Y = 0.20833 b2Yest = 0.14606 b2YestRLS = 2.1016

d1Y = 8.3333e-006 d1Yest = 0.085587 d1YestRLS = 31.9378

a1P = 1.8333 a1Pest = 1.7789 a1PestRLS = 0.50359

a2P = -0.83333 a2Pest = -0.77939 a2PestRLS = 0.50504

b1P = 0.030556 b1Pest = 0.023695 b1PestRLS = 0.10292

b2P = -0.030556 b2Pest = -0.019917 b2PestRLS = -0.094762

d1P = 0 d1Pest = -0.0027178 d1PestRLS = 0.0071078

------------------------------------------------------------------


14

Figure 2-5 Batch estimation of the robot parameters Note that, in this case, it appears that the batch parameter estimation yields fairly accurate results, while the online parameter estimation (recursive least squares, RLS) clearly hasn’t converged yet. Also note that, at present, the parameter estimation is applied to the true coordinates and orientation of the robot. In a real world application this would, of course, have to be based on the measurements, as the ‘true values’ would not be known – which is why the model parameter estimation was performed in the first place… To conclude this chapter it should be pointed out that the current simulation step can be made visible by activating the radio button Animate GUI. With the GUI animation switched on, the name field of the current callback function appears yellow. Depending on which functionalities have been activated (e.g. ‘tracking’, ‘parameter estimation’, etc.), the sequence of steps is as follows: Only called once at the beginning of the simulation: Definition: Robot model (robotModelDef.m) Parameter estimator init (myParameterEstimatorInit.m)


15

Called at every step of the simulation: Evaluation: Robot model (robotModelEval.m) Parameter estimator (myParameterEstimator.m) – optional Measurement (measurePosNOrientation.m) – optional State estimator (stateEstimator.m) – if present Controller (robotController.m) Exchange of information between these callback functions and the simulation as well as from one callback function to another is to be done using global variables. The following variables are available and can be used within the callback functions: displ all display related data (eg. the current view of the camera, the

background image, maximum work area, etc.) rModel the parameters of the robot model rState the state variables of the robot model rInput the input variables of the robot model measmt the measured robot position and orientation as well as other

information related to the measurement procedure sysID the log variables used for recursive and batch mode parameter

estimation simVars general simulation state machine controls myHndl collection of all accessible graphics handles scriptList collection of all callback function edit boxes

2.2 Tracking the robot

Press the “Tracking” button to apply the image processing algorithms to the simulated stream of camera images. This enables the ‘measurement’ callback function. Press the “Edit” button next to the edit box of this callback function. The MATLAB editor should open with the default measurement function loaded (measurePosNOrientation.m, see Figure 2-6). Notice that the call to the image processing command imageProcSilent receives as input the current view of the simulated camera (displ.myBGdat). Global variable displ includes all vision related information. The operation of the measurement callback function can be studied by placing a breakpoint at the beginning of the function (as has been done in Figure 2-6) and then single-stepping through the code. Use the workspace browser to examine the contents of global variable displ and see how it is processed. The image data can easily be visulized using the display menu of the workspace browser (Figure 2-7).


16

Figure 2-6 Default measurement callback function

Figure 2-7 Examining global variable displ using the workspace browser The default measurement callback function first processes the current (simulated) view of the camera using imageProcSilent. See the manual of the toolbox FireWire

Vision Tools (www.mecheng.adelaide.edu.au/robotics/ - Downloads → FireWireVision) to learn about this command and its call-up parameters.


17

For each of the specified colours to be detected (here: red and blue), the entries of global variable measmt are populated. Once all image related data has been extracted from the return variable of imageProcSilent, the callback function performs a simple analysis of the contents of measmt to establish the new centroid coordinates of the robot as well as its orientation (Figure 2-8).

Figure 2-8 Global variable measmt provides measurement information For details of how these values are established see the corresponding section of the default measurement callback function measurePosNOrientation.m (line 70 ff.): % Analyse measurement results (robot detection)

if(measmt.numColsDetected == 2)

(…)

Note that the boundary box information shown in Figure 2-8 (bbx1, bbx2, bby1, bby2) will only be different from NaN (‘not a number’ – boundary boxes are switched off) when the button “Bndry box (on)” is pressed in the main GUI. In this case, the main simulation window displays the boundary boxes around the detected objects as found using imagProcSilent: Figure 2-9 shows this situation for the detected objects corresponding to the information given in Figure 2-8. Notice that the measured orientation of the robot is visualized through a green line starting at the detected

centre of the robot and pointing to the left at the detected angle of φ = 172.69°.


18

Figure 2-9 Displaying boundary boxes around detected objects The algorithm of the default measurement callback function (measurePosNOrientation.m) first detects up to two objects in the specified colours (red, blue).The robot is deemed “detected” if at least one object has been found in each colour and the centroids of these objects are separated by approximately 43 pixels. This criterion, of course, will only work with the “default robot image” shown in Figure 2-9. When a different robot image is loaded the robot detection algorithm will almost certainly have to be modified. The same holds for when the colour definition is altered or when the hardware parameters of the camera change (eg. brightness, gain, etc.). Once a suitable pair of objects (red, blue) has been found, a connecting line is drawn from the blue object to the red object. The robot orientation is defined by the line which is perpendicular to and includes the centre point of the connecting line (see Figure 2-9). The centre of the robot is defined as the point on this line which has an


19

offset of approx. 14 pixels to the centre point of the connecting line. This value has been determined empirically. While experimenting with new measurement algorithms it might be useful to plot traces of the centroids of the detected objects. Click on the button “Object trace (on)”. The logged evolution of the x- and y-coordinate (traces window) should now include the coordinates of the detected objects (Figure 2-10). Note that this feature is currently limited to the two biggest objects.

Figure 2-10 Centroid traces of the two biggest objects in each colour At this stage, a few comments should be made about the error distributions shown on the right-hand side of the traced window. These histograms are calculated from the


20

longest available record of valid measurements (75 in Figure 2-10, statsIdx). When visual noise is added to the image prior to running the measurement callback function it can happen, that the chosen algorithm is unable to detect the robot. In this case the algorithm has been programmed to return the last valid robot centroid as well as the last valid orientation. However, robsim is made aware of the fact that these are old data values by setting the global variable measmt.measurementIsvalid to zero (= invalid). The traces window reflects this lack of information by displaying the returned (old) values using a black dot. This is shown in Figure 2-11 for the case of uniformly distributed added noise (40%) as well as for the same level of white Gaussian noise (Figure 2-12). In both cases and in accordance with the central limit theorem of statistics the error distribution eventually approximates a bell curve (Gaussian distribution).

Figure 2-11 40% of uniformly distributed additive visual noise


21

Figure 2-12 40% of white Gaussian noise Open the controller callback function (default: robotController.m, Figure 2-13).

Figure 2-13 Default robot controller callback function


22

At present, this callback function simply implements a random walk behaviour of the robot. No use is made of the measured robot position – note that the latter could easily be accessed by changing the line global rInput;

to global rInput measmt;

This way, the contents of global variable measmt can be used by the algorithm within this callback function. The same hold for all other global variables (see section 2.1 for a list of global variables currently available in robsim). Figure 2-14 shows a section of the defining equations of the robot model used for parameter estimation and/or state estimation (eg. using a Kalman filter). The callback function ‘Definition: Robot model’ is called once at the beginning of the simulation to initialize all model parameters. The model used in robsim generally fits differentially driven 2-wheeled mobile robots. The implemented equations are due to a publication by Pereira et al. [1].

Figure 2-14 Defining the robot model parameters In the cited publication, Pereira and his co-authors describe an experiment in which a ceiling mounted camera is used to identify the parameters of the assumed robot model. This model (equation 2.1) is based on a 3-dimensional state vector using as

states the robot centroid coordinates x, y as well as the robot orientation θ. The driving functions are assumed to be voltages u1 and u2 which are applied to the left

and right DC-motor of the robot, respectively. Empirical scaling factors α1,2 and β1,2 relate the applied voltage to the steady-state torque of each motor. It is assumed that the dynamics of the motor are much faster than those of the robot.


23

+

−

=

+−

+

+

2

1

2

1

21

21

21

22

)sin()sin(

)cos()cos(

00

)cos(2

0

)sin(2

0

00

00

00

ββ

αα

θα

θα

θα

θα

θθ

θ

θω

u

u

r

L

r

Lrr

rr

y

x

F

yxmF

yxmF

y

x

I

m

m

v

v

&

&

&

&&

&&

&&

&&

&&

(2.1) Note that this model is essentially a set of second order differential equations for the linear displacement variables x and y (robot position) as well as the rotational

displacement variable θ (robot orientation). The physical parameters of the robot are defined as follows:

m : mass [kg] → 0.3

I : moment of inertia → 0.1

Fv : viscous friction coefficient (x, y) → 0.1

Fω : viscous friction coefficient (θ) → 0.1

r : wheel radius [m] → 0.11

L : wheel base [m] → 0.03 Using the following approximations for the differential terms

2

)2()1(2)(,

)1()(

T

kxkxkxx

T

kxkxx

−−−−≈

−−≈ &&&

(2.2)

(and similar expressions for y and θ), the above equation can be solved for x, y, and θ:

( )

( )

( )

( )

++

−+

−

=

−−−−

+−

+−

−−−−−

+

−−++

rrk

r

ku

r

ku

kkykykkT

m

kxT

m

kxkkkT

m

T

F

T

m

kxkkkT

m

T

F

T

m

v

v

212211

2

2

22

22

)(cos)1()1(

...)(sin)]1()()][1()([2

...)2(

...)1()(sin)]1()([2

2

...)()(sin)]1()([2

ββθ

αα

θθθ

θθθ

θθθ

(2.3)

(with similar expressions for y and θ).

Assuming that the orientation of the robot (θ) does not change too much in between subsequent sample steps, i. e. θ(k)- θ(k-1) ≈ 0, the above expression simplifies to:


24

( )

++−

−+

−

=−

+−

−−+

+

rrk

r

ku

r

ku

kxT

mkx

T

F

T

mkx

T

F

T

m vv

212211

222

)1(cos)1()1(

...)2()1(2

)(

ββθ

αα

(2.4)

(with similar expressions for y and θ). Formally, this can be viewed as a ‘linear-in-the-parameters’ one step ahead predictor equation for the x-position:

( )( )( ))1(cos

...)1()1(cos

...)1()1(cos

...)2(

...)1()(

1

22

11

2

1

−

+−−

+−−

+−

+−=

kd

kukb

kukb

kxa

kxakx

X

X

X

X

X

θ

θ

θ

(2.5) Knowledge of parameters a1

X, a2X, b1

X, b2X and d1

X is fully sufficient to describe the motion of the robot using the proposed model. Note that the physical parameters (m,

I, Fv, Fω, L, r, α and β) are implicitly contained in these parameters; it is thus not necessary to measure these parameters explicitly. This is advantageous, as some of these parameters are notoriously difficult to determine (e.g. the friction coefficients of the motors).

Note that similar equations can be written for y and θ:

( )( )( ))1(sin

...)1()1(sin

...)1()1(sin

...)2(

...)1()(

1

22

11

2

1

−

+−−

+−−

+−

+−=

kd

kukb

kukb

kya

kyaky

Y

Y

Y

Y

Y

θ

θ

θ

(2.6) and

θ

θ

θ

θ

θ

θ

θθ

1

22

11

2

1

...)1(

...)1(

...)2(

...)1()(

d

kub

kub

ka

kak

+−

+−

+−

+−=

(2.7)


25

When choosing the robot parameters care must be taken that the discrete-time system remains stable. It can be shown that each of the above one-step ahead predictors is stable when coefficient a1 is between 0 and 2. Noting that

TFm

ma

v

YX

++=1,

1

(2.8) we might run into numerical trouble when m >> FvT. Compared to the product of viscous friction coefficient Fv and sample time T the mass m should therefore not be chosen too large. While the simulation is running, the equations of the robot model (2.5 – 2.7) are evaluated at each simulation step. For this purpose, a further callback function has been provided: ‘Evaluation: Robot model’ (default: robotModelEval.m). Open this file to observe how the new state of the robot is determined using this model (Figure 2-15).

Figure 2-15 Default robot model (Pereira et al.) Using the debug functions of the MATLAB editor/debugger it should be fairly straight forward to understand and experiment with the provided callback functions and/or the code of the simulation itself.


26

2.3 Defining a new robot

2.3.1 Loading a new representation

The default representation of the robot of robsim shows one of the mobile robots used as part of the mechatronics classes at the School of Mechanical Engineering of the University of Adelaide, Australia. When working with a different hardware platform, it might be useful to replace the default representation by one matching the actual hardware. For this purpose, robsim includes the function Define Robot. Click the associated button of the main GUI to launch the robot definition tool (Figure 2-16).

Figure 2-16 Defining a new representation of the robot The robot definition tool is a simple GUI which allows a new robot representation to be loaded or captured from the camera. A number of alternative robot representations have been included with robsim. Modify the name of the Robot bitmap definition file from robot.jpg to robot2.jpg and press enter (or Load). This causes robsim to load the new representation and calculate 36 new rotational phases (Figure 2-17).


27

Figure 2-17 Loading a new robot bitmap Note that the loaded image might have been taken with the ‘robot’ facing in an arbitrary direction. To match the direction of the image to the assumed orientation of the robot (as given by the build-in model equations), the robot representation will have to be rotated. Click on the arrows (“�” and “”) until the image faces the right way (Figure 2-18), then click on Resume simulation.

Figure 2-18 Aligning the ‘robot’ image with the assumed robot orientation


28

The main window of the simulation should now resemble Figure 2-19. When robsim is closed and re-opened, the new settings are used. Note that the outline of the robot is still the old one, i. e. the one matching the UofA robot. To revert back to the default representation of the UofA robot enter the robot definition mode and click on the Reset button.

Figure 2-19 robsim is now using a new ‘robot’ representation The outline of the robot can be redefined as well. Re-enter the robot definition mode and click on Define outline. The currently loaded robotic image is superimposed with a polygone. All but one corner points of the polygone are black. The currently active corner point is marked by a green circle (Figure 2-20).


29

Figure 2-20 Defining the outline Define the new shape of the robot outline by (right-)clicking inside the image. Each time a new corner point has been found, the green circle is advanced to the next corner (Figure 2-21). Notice that the “cursor” can also be moved back using the left mouse button. Once the outline has been defined it can be stored in the global display variable of the simulation by hitting the “enter” key.

Figure 2-21 Defining a new outline Upon definition of the main outline, robsim switches to the definition of the red and blue maker areas (Figures 2-22 and 2-23).


30

Figure 2-22 Defining the red marker

Figure 2-23 Defining the blue marker Upon returning to the main simulation window, the new robot outline is used (Figure 2-24). The new outline is valid until it is redefined or reset to the default outline (UofA robot).


31

Figure 2-24 Robot with new outline It should be pointed out again, that the measurement algorithm will most certainly have to be modified, when the robot representation is changed. This is because it is very unlikely, that the new representation has red and blue patches which are approximately 43 pixels apart (see above). Figure 2-25 shows that, while the red and blue areas in ‘robot2.jpg’ have a colour signature similar to the one of the UofA robot the centroids of the detected objects (blue sky, red jacket) have the ‘wrong’ distance. Therefore, the measurement algorithm does not detect the new ‘robot’ and returns

the latest valid measurement instead (x = 600, y = 599, φ = 100°). This can be seen from the ‘black’ dots in the respective traces windows (Figure 2-25).


32

Figure 2-25 Tracking a new robot implies adjusting the measurement algorithm

2.3.2 Capturing a new robot representation using the camera

When a camera is connected to the computer running the simulation, the robot definition tool uses the image of the camera instead of the loaded image (Figure 2-26). The small yellow square indicates the final size of the robot.


33

Figure 2-26 Capturing a new robot representation using the camera Once the robot appears in the centre of the yellow square, the Save button can be pressed. Note that a new filename needs to be provided. The default robot (robot.jpg) can not be overwritten. To repeat the acquisition of a new robot image click on Resume, to switch back to the default view of the robot definition tool click on No camera. As explained in section 2.3.1, the new representation needs to be aligned with the internal robot model of robsim. Click on the arrow buttons (“�” and “”) until the acquired image faces the right way (Figure 2-27).

Figure 2-27 Aligning the newly captured robot representation


34

The simulation can now be resumed using Resume simulation (Figure 2-28).

Figure 2-28 Resuming robsim using the newly acquired robot representation A number of robot representations have been included in robsim (Figures 2-29 and 2-30). They can be loaded and used/modified as described above.

Figure 2-29 Dolly the sheep


35

Figure 2-30 Dolly in action

2.4 Training the vision system to “see” specific colours

Whenever a new robot representation is used, the colour specification file might have to be changed to train the image processing algorithms for the new coloured objects to be detected. This can be done directly from within robsim using the Train Camera button. Press this button to open the camera training tool (Figure 2-31). Note, when no camera is found on the FireWire bus, the current representation of the robot is used instead.

Figure 2-31 Training the camera to “see” robots


36

Click the Freeze as well as the Select button to define a new coloured object. In the appearing window, click and drag until the desired object has been specified (Figures 2-32 and 2-33).

Figure 2-32 Selecting a colour in the frozen image

Figure 2-33 Colour signature of the chosen object


37

The detected colour specification is displayed in the histogram plots on the right-hand side of the training tool (Y, U, V). A text based representation of the chosen ranges is displayed in the Thresholds edit box. Sometimes the automatically determined ranges can be very narrow, in particular when the colour (and texture) of the chosen object is fairly uniform. In this case it might be advantageous to manually widen the chosen ranges to provide additional robustness of the detection algorithms under varying lighting conditions. However, with purely simulated robots, this is usually not necessary. Copy the current contents of the Thresholds edit box to the colour definition file. This can be done by clicking the corresponding button, or by opening the colour definition file and editing it manually (Figure 2-34).

Figure 2-34 Copying the new specification to the colour definition file To test the new colour configuration, press the Test button. The training tool might still need to be “defrosted” (Figure 2-35).

Figure 2-35 Testing the new configuration For further information about the camera training tool see the manual of the toolbox

FireWire Vision Tools (www.mecheng.adelaide.edu.au/robotics/ - Downloads → FireWireVision).


38

2.5 State estimation

The simulation can – and is primarily intended to – be used to study state estimation problems such as the standard Kalman Filter, Extended Kalman Filter (EKF), Uncented Kalman Filter (UKF) or Particle Filters. As this is the part of this project the students should solve themselves, no further information is provided here, other than the following references: [2] – [5]. When found on the MATLAB search path, the simulation calls the State Estimator callback function (default: stateEstimator.m) between the measurement callback and the robot controller callback function. This way, the propagation equations of the filter equations can be implemented in this callback function. The update equations need to be implemented as part of the robot controller.


39

Appendices


40


41

Appendix A – TODO list

The simulation robsim has been written with a particular goal in mind, namely to provide an easy to use tool for students wishing to study linear estimation techniques, e. g. state estimation, batch and/or recursive parameter estimation, etc. As such, the code of robsim is not necessarily structured in the best possible way for extensions which go beyond this primary focus. Nevertheless, it should not be too difficult to understand how robsim works and how it could be extended. The following TODO list provides a few ideas which might be useful to future developments.

(1) Restructure the code to provide more flexible access to the log data traces.

(2) Replace clunky data handling (global variables) by an object oriented model.

(3) Allow the simulated camera data to be replaced by the live stream of images from the camera – currently, this has not been done, because the work area is 1200 x 1200, whereas the camera is set to capture images with a resolution of only 480 x 480. Access to a higher resolution camera might allow this to be changed.

(4) Provide an option for an unlimited work area – at present the robot “bounces” off the walls, which corrupts the online parameter estimator.


42


43

References

[1] Pereira G. A. S. et al., July 2000, Data-Based Dynamical Modelling of

Externally Observed Actuators-Only Robots, IEEE Transactions on Systems,

Man, and Cybernetics – Part A: Systems and Humans, Vol. 36. No. 4

[2] Gelb A. (ed.) et al.; 1974, Applied Optimal Estimation, The Analytic Science

Corporation, MIT Press, ISBN 0-262-57048-3

[3] Stengel R. F; 1993, Optimal Control And Estimation, Dover Publications, ISBN

0-486-68200-5

[4] Kailath T. et al.; 2000, Linear Estimation, Prentice Hall, ISBN 0-13-022464-2

[5] Julier S. J., March 2004, Unscented Filtering and Nonlinear Estimation,

Proceedings of the IEEE, Vol. 92. No. 3, pp. 401 – 422

Documents

A simple MATLAB simulation for camera based control of ...data.mecheng.adelaide.edu.au/robotics/€¦ · robsim A simple MATLAB simulation for mobile robots 5 1. Introduction This