ELEN90066

Embedded System Design

Kobuki Obstacle Course Project Report

November, 2019

1 Introduction

In this Kobuki obstacle course project report, we document, explore and discuss all the relevant compo- nents which are part of this project. Particularly, we will discuss our Finite State Machine (FSM), sensor data usage, design, testing, and validation procedures.  After that, we will discuss our final workshop outcome and some of the unexpected events which took place. This will be followed by our reflection and ideas for future improvements.

The Kobuki robot is best described as a low-cost mobile research based machine which is tailored for education and research on robotics. It has broad range of basic on board sensors and actuators. The factory calibrated gyroscope enables it to perform. precise and accurate navigation.

In the literature, the Kobuki robot has been used for analysing cooperative localisation [12], investi- gating the design of low-cost autonomous robot platform. [10], performing people detection and tracking with mounted Microsoft Kinect [2], and also case study for robot modelling and control [11]. It is clear that the Kobuki is a popular option among educators and researchers as it is flexible, capable and more affordable than other comparable robotics systems. While we are not mounting any additional or more complex sensors on the Kobuki robot itself, its on-board sensors should be sufficient for our task of navigating the obstacle course.

1.1 Aim and Objectives

The aim of the project is to design and implement a FSM that is capable of tackling the designated Kobuki obstacle course as outlined in the project brief.

Other objectives are listed as follows:

1. To learn, apply, iterate upon the concepts and knowledge gained from the Embedded System Design course.

2. To improve our familiarity with programming the Kobuki robot through C (Eclipse IDE) and Lab- view programming environments.

3. To test and validate our design using the available infrastructure and software.

4. To document and describe the processes we went through and recommend potential future im- provements.

2 FSM Diagram

The style and notations ofthe FSM attempt follow the ones shown in the course lectures and the assigned textbook [6] where possible and applicable.

Please note that after each state transition, the startAngle and startDist variables are updated to netAngle and netDist values.  So that we can keep track of the relative angle and relative distance changes. However, this is not explicitly stated in the FSM to help keep the diagram more readable.

Figure 1: Finite State Machine

In addition, please note that Direction is a Boolean variable that is either Left (0) or Right (1). Ini- tially, if the LeftBump, CentreBump, LeftCliff, CentreCliff is activated, then the direction is set to Right. If the RightBump or RightCliff is activated, then the direction is set the Left.

3    Sensor Data Usage

Kobuki robot provides a wide range of basic on-board sensors which can be accessed and processed by the myRIO. Figure 2 provides a an overview of some of the sensors available. However, since not all the sensors are directly applicable or useful for tackling the obstacle course, therefore only a subset of all sensors are used for design and implementation. The sensors used from Kobuki are listed as follows.

• Bump Sensor (Left/Centre/Right)

This is provided as a Boolean data type, and when any of the bump sensor is triggered, the vari- able would go from false to true and activate the obstacle avoidance mode. The update is then pro- cessed by the guard of the FSM so that the robot would know which direction to start searching. For instance, if the left or centre bumper is hit, then the robot will start performing an exhaustive search to the right hand side.  On the other hand, if the right bumper is hit, then the robot will perform an exhaustive search to the left hand side.

• Cliff sensor (Left/Centre/Right)

Similar to the bump sensor, the cliff sensor is provided as a Boolean data type.  When a cliff is detected, the sensor data updates from false to true and the robot enters obstacle avoidance mode in the FSM. The same logic of deciding which side to search is used as in the bump sensor scenario.

• Wheel Drop Sensors (Left/Right)

The sensor data here is provided as Boolean data type.  When the left wheel drop sensor is trig- gered, the robot enters obstacle avoidance mode in the FSM, and begins search to the right. Con- versely, when the right wheel drop sensor is triggered, the robot will search to the left.

• Gyroscope

The sensor data for gyroscope is provided as an integer in the form of 100deg. This means that the gyroscope data needs to be divided by 100 first to convert it into degrees.  The gyroscope sensor is mainly used to correct the robot’s heading when it is in the Drive state. The reason behind this is that, if we only relied on the encoders of the robot the whole time (dead reckoning), then errors can accumulate over time from slip. Significant heading error can also arise when the robot makes contact with an obstacle on the side but does not trigger the left or right bump sensors, this could drag the robot side way and alter the overall heading. To address this, a simple proportional con- troller is implemented to track the initial heading direction of 0。, which is initialised and recorded right after the Labview project is deployed.

• Encoders

While the encoder raw measurements are available in ticks, the Labview statechart project already provides access to the processed variables Inputs.net  distance  (mm) and Inputs .net  angle (deg).  This is used to track the amount that the robot has turned and travelled, and is placed across majority of the guards in the FSM.

• Accelerometer (myRIO on-board sensor)

Although Kobuki robot does not have a built in accelerometer, acceleration data in (g) can still be measured using the accelerometer within the myRIO. The acceleration data is mainly used to determine if the robot is driving on a flat surface, upward incline, or downward slope.  For example, the guard we have in place between the Drive Level and Drive Up state is

jacc.xj + jacc.yj > 0.2                                                       (1)

which allows the robot to determine that it is driving up an incline when the sum of the abso- lute acceleration values in x and y axes is greater than a fixed threshold.  The fixed threshold is determined experimentally during the workshop sessions. Other guards in the FSM utilising the acceleration measurements operate on the same principle, but just with different equality signs and thresholds.

While we initially attempted to just utilise the z-axis acceleration data to determine the presence of a slope, but the change in value between flat surface and the slopes we tested was too small. Hence, it was difficult to rely purely on z-axis measurement for robust performance.

Please note that sensor data acquisition tasks mainly are based off the tutorials from the course assigned lab manual [4], and also with reference to the official Kobuki online documentation [5].

Figure 2: Kobuki robot with labelled sensors

4 Design Procedure

4.1 Signal Filtering

In the first workshop, we learnt about establishing Bluetooth connection to a Nintendo WiiMote and how to send commands to stream the corresponding accelerometer data.  More importantly, we also learnt about how to apply a low pass filter to filter out the high frequency noise of the accelerometer sensor.

The filter introduced was a relatively simple low pass filter that is introduced in the lab manual [4], which links to another document regarding implementation of tilt-compensated e-compass using accelerometer and magnetometer sensors [9].  While the other parts of the lab was not really re-used for later parts of our design process, this basic filter turned out to be surprisingly useful throughout the course. This is mainly due to its simplicity and ease of implementation.

The different equation for filtering the input series x[n] into output y[n] is given by equation 2.

y[n] = (1 -   )y[n - 1] +   x[n]                                                        (2)

For the case where this low pass filter is applied to accelerometer measurement, y[n - 1] would be the previous filtered value, x[n] would be the current unfiltered input, and y[n] would be the filtered acceleration measurement. Variable    is a tunable parameter between 0 to 1 which is adjusted based on experimental results.

• If    is large (closer to 1), then there will be minimal smoothing effect, as a significant weighting is given to the current iteration input.

• If    is small (closer to 0), then there will be a large smoothing effect, as a significant weighting is given to the previous filtered value.

This filter is later applied to the myRIO accelerometer output measurements to filter out the high fre- quency noise. The parameter    = 0.3 was chosen for this purpose.

4.2    Basic Obstacle Avoidance

In workshop 4, we started implementing a basic obstacle avoidance algorithm for navigating around a simple block of obstacle. The main idea we had for this was, depending on which bumper was hit first, the robot will choose an initial direction and then attempt to navigate around the obstacle.

• If the left or centre bumper is hit, the initial direction will be set to right.

• If the right bumper is hit, the initial direction will be set to left.

The steps that the robot follow is that, after it has bumped into an obstacle, it will immediately reverse for a set distance, then turn 90。right (or left, depending on which bumper is hit), go forward a set dis- tance, then turn left (or right), go forward and continue its navigation. This forms the basis for our FSM design as we continue to develop and build on top of this idea in the following workshops.

If the Kobuki is still unable to move forward, it will follow the same turning procedure, continuously turning right (or left) until it has either:

• Found a gap to move through.

• Cannot move in that direction anymore, hence it will follow the same steps except search for an opening in the opposite direction.  If no such opening is found, the Kobuki will turn back from where it came on.

4.3 Hill Climb Implementation

In workshop 5, we were introduced various methods determining whether the Kobuki robot is situated on an inclined surface. The application note provided by Analog Devices [1] listed a breadth of options for how the tilt angle could be determined using an accelerometer, which includes:

• Single-Axis Tilt Calculation

AX[g] = 1g × sin(θ)                                                            (3)

where X is the horizontal axis and we can arrange the equation below and solve for the inclination angle θ = arcsin(AX).

• Dual-Axis Tilt Calculation

(4)

where X is the horizontal axis and Y is the vertical axis.

• Three-Axis Tilt Calculation

(5)

where X and Y are the horizontal axes and Z is the vertical axis.

During the workshop testing phase, we first implemented the single axis tilt calculation method, and found that the while this approach was simple and easy to implement, it was not very robust and sometimes would not trigger the guard which we had in place for incline detection.

After that, we tried to implement our own hybrid approach between the dual and three-axis tilt calculation.  Our incline detection method to directly compute an angle, but to use a combination of acceleration measurement and a fixed threshold to perform incline detection.  This relies on the abso- lute values of the acceleration in x and y axes, which are denoted as acc .x and acc .y.  As previously mentioned, the guard between Drive Level and Drive Up (for an incline), is as follows.

jacc.xj + jacc.yj > 0.2                                                           (6)

Assuming that the x-axis is pointing up the incline, and y-axis is point to the side of the incline, as shown in figure 3.  Then regardless of which orientation Kobuki approaches the incline, the myRIO accelerometer will be able to compute the sum above and determine if an incline exists.

Figure 3: Incline

• When the robot is on flat surface, the contribution from acc .x and acc .y are both 0.

• When the robot is on an incline as shown in figure 3, then the accelerometer value in acc.x would increase, while acc .y remains approximately 0.

• When the robot is on an incline, but oriented at an angle, then acc .x and acc .y would both have non-zero values.

4.4 Choosing Development Environment

We decided to use the statechart module on LabView over developing the FSM in C as the statechart interface was more intuitive when looking at how the FSM transitions from one state to another.  The myRIO is also built around the use of LabView, making it easier to upload and deploy code onto the hardware itself. The team’s experience with LabView over the C development IDE also played a factor into this decision.

4.5 Robot Behaviour Refinement

One of the requirements for the project if for the Kobuki to maintain ground orientation.  The Kobuki may not always keep ground orientation, especially after turning, due to slip or inaccurate encoder read- ings. Hence we have implemented a Proportional Control in the drive state that corrects the Kobuki’s orientation using the error between the gyroscope’s reading and the reference orientation. Below are the equations used to adjust the motor speeds for when the Kobuki is on ground level.

Left Motor Speed = 200(1 + P θ(netAngle - AngleRef))

Right Motor Speed = 200(1 - P θ(netAngle - AngleRef))

where P θ = 0.01 is the Proportional gain for the ground orientation.

Another requirement is for the Kobuki to drive up the ramp without falling off the edge.  We could have let the Kobuki run through the Obstacle Avoidance State every time it reaches the edge of a ramp, but it is not an ideal method for that state to be always triggering, especially if one of the cliff sensors is not working properly.  Our refinement to this is to add another Proportional Control that uses the accelerometer readings to have the Kobuki re-orientate itself so that it travels straight uphill.  Below shows the equations used to set the motor speeds for when the Kobuki is driving down the hill.

Left Motor Speed = 200(1 + Pa(acc.y))

Right Motor Speed = 200(1 - Pa(acc.y))

where Pa  = 3 is the Proportional gain for the accelerometer reading.

(a) Drive state controller implementation

(b) Drive down state controller implementation

4.6 Exhaustive Search Implementation

The Obstacle Avoidance state has been fitted with an exhaustive search algorithm. The exhaustive search algorithm simply makes the Kobuki look for all possible openings if its path is blocked. It searches for a path in one direction, then switches directions if it cannot go in tat direction anymore. If no such opening is found, the Kobuki will simply turn back to where it came from. Such direction changes and choice of turning back are made into simple and general diagrams with the help of variables and triggers. Below shows a representation on how the use of variables and triggers help describe the state of the Kobuki.

5 Testing Procedure

5.1 Testing Using CyberSim Simulator

From the project handout, a relatively detailed specifications were provided for the course, but we were also told that we would not be able to perform trials on the actual course before the final workshop. Therefore, we started exploring other testing options which are more extensive and complete. The main one which we decided to explore further is the CyberSim simulator which we already have access to.

However, CyberSim was not particularly well documented and the existing simulation maps have their configurations stored in  .xml files which are difficult to visualise and customise.  Upon further research, we realised that all the existing simulation maps can be created and edited using LabVIEW Robotics Environment Simulator. Essentially, LabVIEW Robotics Project Template has configuration wizard that provides a simple and basic interface that allows users to open and edit existing  .xml files, from there we were able to modify and add to existing map elements such as walls, obstacles and so on.

The main prerequisites for making the simulation map are:

• NI LabVIEW 2018 myRIO Software Bundle

• CAD software capable of exporting any of the following file types (.ive,  .dae,  .lvsg,  .wrl). It turns out that Fusion360 does not work well for this purpose, and an alternative called Rhino 6 was used for testing and importing custom objects.

• Detailed write-up on how this procedure is conducted is available in the appendix section 10.1.

From the provided sample obstacle course layout shown in figure 6, we were able to construct a sim- ulation map after making a few assumptions regarding measurements which were not explicitly stated. While it was possible to import CAD models, we were unable to obtain a matching physical/collision model after import. These limitations will be discussed in the following subsection. Therefore, we ended up using the existing components from the Built-in Obstacle Library to construct our simulation map. This consists of sphere, cylinder and box.

Figure 8: Simulation Scene (Perspective View)

The resulting simulation environment with slight variation in obstacle arrangement can be seen in figures 7 and 8.  The main advantage for this approach is that all of the obstacles and walls can be customised by specifying its centre coordinates, dimensions and object properties such as colour and whether it can be moved.

One selected test for obstacle avoidance robustness test was recorded [7], and it shows that the robot is capable of performing the exhaustive search algorithm and avoid a wide rectangular block. The main advantage of testing by simulation in CyberSim is that, you can iterate very quickly and do not need to have access to the physical myRIO and Kobuki hardware.

5.2 Limitations of CyberSim Simulation

While the aforementioned simulation map design and setup is convenient and relatively easy to modify and iterate, there is also quite a few limitations which are stated as follows.

• The inability to import CAD model while matching the physical profile exactly.  While the CAD model importer allows us to import models from the specified formats, we were unable to figure out how to apply the physical model so that it would fit the imported shape exactly. For example, if we import a model of a triangular prism, we would need to select a physical model of a box, cylinder or sphere to approximate the collision model.

• Imperfect modelling of the robot, leading to unrealistic simulation behaviour.  The example that best illustrates this would be the ramp/hill implementation in the simulation environment. In real life, when a Kobuki robot falls or is raised, both of its main wheels have mechanical mechanism that allows the wheels to be dropped.  However, this behaviour is not included in the Kobuki model used in CyberSim. Consequently, the simulated Kobuki would struggle to transition from flat surface onto a ramp or incline with more than 5。angle.

• The axes of the simulated Kobuki do not align with the the actual Kobuki. Hence, we would need to ensure that the axes used in simulation are updated accordingly before testing in real life.

• There is significantly more sensor noise in real life.  Therefore, algorithms which work well in CyberSim simulation do not always carry through directly to real life. A potential future improve- ment is to incorporate simulated sensor noise, with tune-able parameters for noise distribution.

5.3 Testing Using Available Infrastructures

With the limitations stated in previous subsection in mind, we look to the available physical testing components to help improve the overall robustness of our design. In workshops 7 to 9, we were given the opportunity to improve and refine our FSM design and the actual implementation with the Kobuki robot. The testing procedure consists of the following steps:

1. Update the FSM implementation in Labview statechart, and upload the code to the myRIO via wired or wireless connection.

2. Setup the obstacle course with the available obstacles and ramp.  This includes tweaking object orientations, initial robot position and setting up different test cases, so that we can explore as many untested cases as possible.

3. Run the robot and observe its behaviour to see whether the actual behaviour matches the expected behaviour.

4. Repeat steps 1 to 3 to continue the design iterations.