FYP Progress up to Recess

Recently I was largely occupied by projects and labs from other modules, therefore the progress for FYP is not as fast as previous a few weeks.

I found the following articles useful and summarized them as below.

 

Simultaneous Localization and Mapping for Forest Harvesters

This article is based on a forest harvester application that is done in Finland. The environment is extremely similar to the Out-door project that Jinqiang is doing (I guess).

The main sensor for this mentioned project is laser scanner. They made use of a graph data structure to store the measured information and run multiple data association algorithms against the obtained data on batch basis.

They also brought up a few interesting points in the article:

1.    They claimed that the image beacons does not help in the data association problem. The season is simply that trees in forests looks alike. They claimed that this is extremely true in well-maintained forests.

2.    The proposed the idea (not realized though) that measuring the absolute angle would help in the data association problem.

a.    I think magnetometer would help in geometry based data association, if the sensor was able to produce measurements of absolute direction with reasonable accuracy.

b.    I am not sure whether the motors from the helicopter would interfere with the magnetometer.

3.    They are using GPS in their project. Since their tests are also carried out in forests, is it the case that GPS data is actually available in forests.

 

Towards Lazy Data Association in SLAM

This paper took a second look at a basic assumption that most maximum likelihood data association algorithm adopts, which is all pervious decisions made were correct.

 Data Association

        In this proposed approach, author maintained a tree-like log-likelihood data structure. Each time a new data association decision is made, all frontier are re-examined to see whether modifying one of the pervious decision would result in greater likelihood. If so, the upper level to the modified leaf would also be checked recursively, until a maximum is obtained. In the process, all log-likelihood data are maintained in the tree data structure for later use.

 SLAM

        The SLAM part of this algorithm is similar to the Sparse Information Filter SLAM. All measurements are finally translated in to soft constrains and the mapping task becomes an optimization problem.

 Computation considerations

        If this idea is implemented on feature bases, the memory and computation usage would be very expensive. Therefore, I don’t think this method would be able to run on-board.

        The lazy nature also make this approach hard to meet real-time requirement. Whenever a modification of previous data association is made, the search might be substantial. Therefore the computation time variance from frame to frame is large. In such case it’s easy to hit scheduling deadline, if run in real-time.

In short, the advantage of this method is the modification solved the root of brittleness for data association problem, which is the assumption that previous decisions are always right.

The disadvantage of this approach is that, the lazy nature of the tree search and the large amount of computation for inverting information matrix make this approach hard to implement for real-time.

FYP progress for week 3 & 4

Overview

For the past two weeks, the main focus was on trying to understand the various approach in solving SLAM problem.
The book borrowed from Jinqiang turned out to be extremely useful!

Literature summary:

Particle Filter Based Robust Simultaneous Localization and Map Building for Mobile Robots
This article discribed an approach to detact and fix gound robot kidnap problem in real-time SLAM.
Basically, the author was monitering the residule from odometry readings. When it is likely that fault has occured. The particles are mutated in order to retrack the position of the robot.
The artile is short and does not contain much details.

Noval approach to nonlinear/non-Gaussian batesian state estimation
This article discribes the math and thought behind particle filter and proved particle filter performs better than EKF in certain cases, where it's nonlinear or non-Gaussian.

A Method for Registration of 3-D shapes

This paper discribes in detail the ICP algorithm, however, I have not get the time to finish this paper, before I find the book below is much better.

Probabilistic Robotics

Chapter 5 robot motion

This chapter dealt with motion model of robot. Two approach was given in the book, one was based on controll input, the other was based on odomery.
However, I felt that the two approach given in the book was mainly meant for ground robot, however both could be related to our case.

• The odometry model could be related to the optical flow model, whic is being developed by Wang Fei.
• The control model for a UAV is way more complex than the one for ground vechicle. In order to make the model usable for 2-D SLAM, we have to find a way to approximate the 3-D motion into 2-D. It might also be a problem that the heading of UAV might not be the direction that the UAV is actually propagation. Extensive research in UAV control and modelling need to be done in order to obtain a control-based motion model.

Chpter 6 Robot Perception (measurement model)

This chapter introduced a few types of measurement model that could be used for laser sensor.
In my point of view, establishing an accurate measurement model is criticle for the rest of the task. (especially after seeing Bo Xuan's work).
The model introduced in the book could be summarized as follows:

• Beam model for Range finders is a model that could be justified with rigour and tuned systematically. In the model, there are 4 factors that could contribute to a measurement reading, each of which can be represented by a probability distribution. They are:
• hit: the intended measurement with a narrow gaussian distribution
• short: obstruct by unintented object
• max: max reading returned, due to lighting condition, color of object, reflection etc.
• random: other factor contrbute to a false reading
• The wrights of these four factors and their intrinsic parameters could be tuned.
• The shortcomes of this approach are:
• Expensive computation involved
• Dependency amoung beems, which are assumed to be independent
• Lack of smoothness (trouble caused by objects like table leg, chair etc.)

• Likelihood Fields for Rnage finder is a model only deal with the end point of the measurements(except for the max readings). This method calculate the position of the end point w.r.t. global map using translation matrixes and adjust the probability of encountering an obstacle at the end point. This approach deals with 3 out of 4 factors in the Beam Model
• hit
• max
• random
• The disadvantages of this approaches are:
• It does not model dynamically moving objects (short category)
• The algorithem does not deel with problem of going through obstacles
• It does not takes into account the matching of free space
• While comparing to Beam model, this approach does better in smoothness

• Correlation-based measurement model is not really a measurement model. It's more a method that matches two local maps and produce parameters like distances between maps.
• The advantage of map mapping is that it considers white spaces in the map. But the dis advantage of this approach are there is no physical explanation behind and there is no noise charicteristic of the sensor.

• Feature-Based measurement Model is what Bo Xuan has done (more or less). It has to do feature extraction first before the data could be processed to yield measurements. Being at a higher level, features extracted are way lower in number. Therefore, the computational cost for this approach is much lower.
• The main challenge in feature-based measruement model lies in data association steps. We have to find a way to extract a signature of every feature, so that it could be checked to confirm the association of data. In order to do this, Lidar alone will not be enough.

Chapter 7 Mobile Robot Localization: Markov and Gaussian

This chapter introduced, in detail, two similar approach (EKF and UKF) to realize localization task.
Both EKF and UKF assumes a gaussian distribution for measurement noise. Their differece lies in the different ways to linearize the measurement/ motion model. UKF usually produce better result at the cost of more computation power.
The main draw back of both approaches are that they were subject to global registration and kidnap problems.
Author also briefly mentioned another approach- multi hypothesis tracking algotrithm (MHT), which I think is the most promissing amoung the gaussian filter approaches. It is more robust, while still seems practicle to be implemented in real time.

Chapter 8 Mobile Robot localization: Grid and Monte Carlo

This chapter introduced mainly two approach to achieve the localization problem, and they are grid (histogram filter) and Monte Carlo.
They are similar in a sence that they both try to represent the probability distribution by having a sample of states.
However, Monte Carlo is more efficient as compare to Grid based approach, especially after adopting the KLD-sampling approach.
As compare to Gaussian filter based algorithms, these two approaches solved the global registration and kidnapped problem at the cost of heavier computation. But, if implemented properly, the Monte Corlo approach seems promising to be run in real-time.

Goals for now

Following should be done before CA1:

• Finish the SLAM related chapters in the book
• Look back into the papers that has been found and categorize them according to as the book suggested
• Try finding some more articles through the references in the book

FYP Progress for Week 1 & 2

Overview

For the past two week, the main focus has been trying to understand the literature's received from seniors, Wang Fei and Cui Jinqiang.
I have also downloaded and installed MatLab on my PC and labtop, so that whne I finish reading, I could getting started with the Matlab codes.

 Classification of Literature

The literature's can be roughly classified into following topics:

• Localisation
• Feature based localisation
• Feature extraction
• Cartesian coordinate based
• Sensor coordinate based
• Transformation estimation
• Point based localisation
• ICP algorithm
• MbICP Algorithm
• IDC algorithm
• SLAM
• EKF SLAM
• Fast-EKF SLAM

Literature Summaries

Simultaneous Localisation and Mapping with extended Kalman Filter

This article introduced the steps of implementing a EKF-SLAM algorithm after processing the raw scanning data.
In the article, how to extract feature, and how to estimate the position of the UAV are not mentioned.

An Introduction to Kalman Filter (Find through Library E-resources)

As I had never came across the term EKF. I searched for this article so that I know how Kalman Filter and Extended Kalmen Filter came about.
This article explained in detail, how KF and EKF are obtained mathematically and illustrated what should be done, in updating an estimation after each set of data in obtained from measurement.

Stochastic models, estimations, and control <chap 1-3> (Borrowed from Library)

I browsed thought the first a few chapters of this book mainly to familiarise myself to matrixes.
I never came across Matric-Representation of linear systems and Correlation matrixes. I need to get a taste of what are the meanings of these matrixes.

High-speed laser localisation for mobile robots (Find through Library e-resources)

This paper presented a localisations method based on both sensor's coordinates and Cartesian coordinates. The algorithm is termed "HAYAI".
The proposed algorithm made use of linear filters, which could be easily implemented by Matrix multiplications. As a result, it achieved good computational speed with reasonable accuracy.

Feature-based laser scan matching for accurate and high speed mobile robot localisation

This paper aimed to improve on the accuracy of HAYAI algorithm by refining the feature extraction part of the HAYAI algorithm.
Author Incorporated the covariance into the computation, which makes the process slower but more rigorous.
The line extraction and corner extraction algorithm has been improved to expect better accuracies.

Metric-Based Scan Matching Algorithms for Mobile Robot Displacement Estimation

This paper introduced the MbICP algorithm.
The introduced algorithm tried to solve for displacement and rotation at the same time. After taking approximation, the expression is simplified into second order equations, for which the extreme value can be easily obtained. The same was applied again for point -to-line transformation.
Author claims this method has significantly better result, as compare to tranditional ICP methods
.

Efficient Variants of the ICP algorithm [have not understood fully, in progress]

I am still working on this paper.
This is a review type of paper, therefore, I need to dig through some of the reference list before I could understand what all the comparisons are talking about.

GSoC 2012 update

The review of the app has been successful!

It's available at OI Shopping List in App Store

GSOoC 2012 Week 10 report

This week, the primary focus has been to complete the store-wise price calculation related features.

A subtotal display is added to the ListContentTableViewController. Store filter is also implemented and added to the application.

Functionality of both feature are similar to the android version.

The subtotal calculation sums the product of unit price and quantity of all unchecked items. And updates the sum when the user load the list, modifies the list or check/ uncheck the items.

The Store filter enables user to display items with price information available within a certain store. The app would load all the stores that are related to the displayed list. After one is selected by the user, those items that has price information related to the selected store would be displayed, others would be hided.

Screen shots of both feature have been attached below.

 

These two screen shot shows the button to filter and the action sheet popping up after clicking filter button.

These two screen shot below shows selecting store filter and filtered list display.

After completing the store-wise price calculation, I feel that the feature could be improve as below:

Now, list owns stores. In other words, when we create a new list, we have to input the price information from scratch. Which can be a thing that users do not want. If we could change it around, and makes Item owns the stores. That could be potentially better. For example, I buy potato chips on Wednesday and recorded down it is $3.00. If I add potato chips to the Friday shopping list, it would be good to have the $3.00 information in the list automatically, then “forget” about it and ask users for it again.

Of course, this would add complexity to the algorithms. Other potential problem could be that a long list of prices and stores might be associated with a item, and the database might be messy and difficult to clean up.

I could now, focus on cloud synchronization solely. Hope it could be done soon!

GSoC Week9 Report

First of all, I am glad that I have passed the mid-term evaluation. Now, I have got more thrust to move on with the project, complete the price feature, optimize the interface and incorporate the cloud sync feature into the app.

This week, the mean focus is still on store-wise price calculation. It has been pointed out that the bug in android has been fixed and after updating my source version, I am able to run the android version smoothly. There I finally got the full picture of the app.

There was an discrepancy between my previous understanding of store-wise price calculation and the one that Android is using now. My understanding was, store would be primarily associated with items, since that is the thought that most people have in real-live. While in the Android app, stores were associated with list. This makes the implementation easier. I took the second approach after considering the two. Firstly because it is more manageable; secondly because of the consistency crossing different platforms.

After clearing the mis-understanding of how it is done. I continued with my implementation.

The data-model has to be slightly adjusted, as follow:

the list_id is a to-one type of relationship

each store is “tied” to a list, removing the list would remove the store.

Then I went on to realize the interface, The challenge was, I have to use a customized a table cell with textfield in it. The approach I took was to subclass the text field, and add a property “store name” to each of the textfield. So that when user modifies the price, I would always know it is the price in WHICH store that is being modified.

 

The store-wise price menu is in the edit entry detail menu, a screen shot is attached below.

GSoC Week8 Report

The primary focus of this week has been:

Implement the price calculation.

However, this feature is not, yet, ready for running. Thus, there was no code uploaded this week. 

The working code for this week will be uploaded as soon as I finish up the remaining parts, latest by the next week.

The main challenge of this task is to implement the store-wise price calculation.

There is a bug in the Android version of the app, there was no ready algorithm for this purpose. It's more like writing something brand new rather than fit something to a different platform.

The task can be brought down roughly, as follows:

 

Core Data

Responsible for creating and managing the relationship between contains, items, prices and stores. 

Fetches and Calculations

when a list is displayed, the subtotal of the times will also be displayed at the bottom of the list.

Interfaces

Interface must be improved to accommodate the price feature and store-wise price calculation.

Potential problems are:

When a price is created, it must be associated with a store, if we intend to calculate the price base on store. However, this creates tedious input process, as the user has to input information about a store before he can do something with the price.

Therefore, it would be a challenge to present the UI in a neat and concise manner.

GSoC Week7 Report

GSoC Week 7 Report

This week, the main focus has been to tidy up the code that has been previously developed.

1)Fixed the bug in assigning units to items.

In the pervious version, there was a but when trying to associate a unit to an item.

This bug was fixed

2)Enabled AutoHide feature

The auto hide switch has been in the option menu for a while, but it was not functional.

This version has modified the setting management object, integrating the auto hide feature into NSUserDefault.

Now the auto hide feature is functioning.

3)Removing non-necessary code

The code and UI meant for testing purpose or the outdated version were all removed.

Files invoking the non-necessary code were also taken care of.

Now, a basic version of the application is already up and running, ready for mid-term evaluation.

In the next week, the main focus would be:

 

1) add in price calculation

2)read materials relevant to cloud synchronization, and be ready to implement cloud synchronization after mid-term evaluation

GSoC Week 14 Report

This is the last week of GSoC 2012.

I have been working on documentation of the project as well as pushing through the review of the app on app store.

The documentation is as follow:

OI Shopping List for iPhone and iPod

Overview

The OpenIntents Shopping list lets you keep track of your shopping items. You can also use it for other kinds of check lists, for example for ToDo lists or party guest lists. 

Currently, the Open Intents Shopping List for iPhone and iPod supports the following functions: 

=>Add items, mark items, clean up list. 

=>Create new lists, delete lists. 

=>Change font size and sort order through settings 

Development

Data structure

All the data structure related file are placed in the DataModel group in the project. The structure of the Core Data data model was extremely similar to the OI Shopping List for Android. 

There were 5 entities in the data model and they are:

• Contains
• Items
• Itemsstores
• Lists
• Stores
• Units

In each of the entries, the table columns are also similar to the SQLite data base structure in OI Shopping LIst for Android. Except that the cells that stores ids, were replaced by bidirectional relationships, which makes referencing easier and faster.

As the data model subclasses were all generated by Xcode, and regeneration might be needed in future. All methods were written using categories.

The overall relationship between all the entries can be summarized as follows:

• Lists is the main entries and are always created first;
• Items can belongs to several lists at the same time and are always linked up with list by Contains.
• Contains serves as a note between Lists and Items and stores additional information for a item and associates with a list. A contain is always one-to-one. In the case where a item belongs to several lists simultaneously, different contains links the item to different lists.
• Stores belongs to a list.(I do think it would be better if the store and price information could be shared among different lists, as that would make more sense. However, it is left this way to maintain consistency with the version for Android)
• Items contains links up Lists and Stores, and store the price information.
• Units are associated with Items.

User Interface

The user interface mainly makes use of table view controllers and were embedded in navigation controllers.

Controller classes were also divided into blocks. The blocks are namely:

• Main Shopping List Interface
• User interface for settings and options
• Filter related user interface

Each of the above group achieves functionality as follows:

Main Shopping List Interface

This group of files consists of the code to define the view controllers for creating, selecting and displaying shopping list, content of shopping list and detailed infomation of a product entry that is in the list.

These controllers interacts with user and handles events like creating a new list, adding a product into a list, editing information for a product and management of store-wise price information for a product.

User interface for settings  and options

These block of code are located in the “Options” group with in the OIShoppingList folder. The files in this group are mainly view controllers as well as setting managers. 

The view contorllers in the “Options” group interacts with user to adjust the preferences for font size, sorting order and auto hide. The app also allows user to revert the setting to factory setting. The table view controllers in this class are mainly static table view controllers, therefore, the codes are pretty straight forward.

The “ShoppingListSettingManager” class check and stores user preferences and generate the appropriate output string or predicates according to user preference.

Filter Related user interface

This group of code are placed in the “filter” group within the OISHoppingList. As the name imply it let user choose the filter to be applied and filter the list entries according to the chosen filter.

GSoC Week 13 Report

The primary Goal for this week has been to submit the application to app store.

This process has been SUPER TEDIOUS, and I underestimated the time it would took.
The submission process consists of obtaining tons of certificates and authorizations from apple developers' account.
I messed up the credential information once and reset my entire account on mac. It tools me an entire day just to be able to run the app on device again.
Anyway it was finally done!

This review process would take 3-5 business days, according to apple. Therefore, if they have no issue with the app, it should be available on app store by the end of this week.

The rest of the project would be, then, to finish up the documentation.
I will try to finish the draft of the documentation by Thursday, so that every one could take a look at the documentation and I could improve on it over the weekend.

GSoC 2012 Week 11 Report

Cloud synchronization

Not much coding has been done this week, instead, the main focus has been trying to figure out how to achieve the cloud synchronization with other platforms.

According to vettukal’s post, the cloud synchronization is likely to be achieved by Google App Engine, Endpoint service. According to what I have discovered by now, Endpoint would be able to generate libraries for multiple platforms, including iPhone. Therefore, compatibility will not be a big issue. 

Vettukal will be working out some back end code, and Google App Engine would put some wrapper code so that it can be called in iOS. The issue is, the object, passed in from iOS must fit the one that is defined in the backend algorithm.
The problem is, Core Data DO NOT allow manipulation of the SQLite file, thought the data can be stored in SQLite format. Therefore, we can’t pass in the entire db file as argument to server, or pass back a new db file. Instead, the object, that the backend expect would have to be an array of  table entries(or arrays of tables, which are arrays of table entries).

So the problem, now, simplifies to:

• 1.Make sure the argument that the cloud accept and returns is not db file, since db file cannot be manipulated in iOS platform.
• 2.implement the code to generate and unpack the code in iOS platform.

Depending on the approach taken by Vettukal, we can either pass in and return the entire data base, or just pass in or return the changes to be made.

If the first approach is taken, then the only thing need to do is to record down the last modified time and wrap the entire data base into an object. 

The code might be more straight forward, but the data traffic would be heavier.

The second approach would requires modifying the data base a little bit to add in a synchronization time stamp to each of the entries. 

Advantage being only the change get sent to /from the cloud.

Next week, the main focus would be try to work out the cloud synchronization feature. At the same time, tidy up the code, and add in commons.

GSOC Week5 Report

Rebuild and debug Data Model

This week, the focus has been trying to adapt the app to fit the newly modified data model.The new version of the data model shares exactly the same name with the Android version.And the core data diagram is attached as below.

By rebuilding the data model, most of the task related to management of the data base has been shifted into the categories files, which aim to make the program more objective oriented.

Edit Detail Interface

In addition to the data base, the detail editing interface has been improved. Instead of using many text fields, a static table view is engaged to obtain the detailed information of a specific product.A screen shoot of the new product detail interface has been attached below.

The rotating dail is there for user to select a unit that already exists in the data base. For the rest of the entries, the virtual keyboard would pop up when clicking on the individual entries. User, then, would be able to key in specific information of a product.

Delete

Deleting list or entry is also enabled. when user swipes across one of the entries in the table. a delete button would appear. When clicked on, the corresponding entries would be wiped out.A screen shoot of the delete button is shown in the picture

Bugs or problems:some times the app is having trouble adding new units, and I am working on solving this problem.

GSoC 2012 Week 4 Report

The focus of this week has been trying to redesign the data base structure for the app so that cloud synchronization can be carried out.

However, some trouble has incurred.

I have been trying to make use of the core data service provided by iOS. Though the core data service is provided through making use of SQLite, the application will not have direct access to the SQLite tables. Everything is taken care of by using NSManagedObject.

Therefore, additional code has to be put in to convert the data base on iOS device into a single Jason string.

This can only be done after the format of the Jason string being finalized.

The solution for that, for now, is have a Core Data structure that is similar to the Android table. In that way, though the exact structure of the tables might be different, it might be easier to synchronize the data to a cloud.

Due to bugs, no code has been uploaded. 

New data structure should be ready to go by next week.

GSoC 2012 Week 3 Report

GSoC 2012 Week 3 Report

Activities in the week

Fixing the bug within applying setting

There was a bug in week's  2 version of code, where the sorting order setting was not applied immediately after an adjustment.
This was fixed by setting the fetch result controller in view did load method. where checks the setting and set the sort descriptor.

Add sharing features

Sharing using SMS and email is added.
When user click the <share> button while browsing the list, a action sheet would pop over and ask whether the user wants to share by emailing or SMS.
Once one of the two options is selected, a SMS or Email editing interface would pop out with the list content loaded as default content of the message. User can then add recipients and modify the content as his/ her will.
Controller for SMS and email activity and interface is provided by apple as API, in package MFMailComposeViewController and MFMessageComposeViewController
by creating an instance of one of the controllers, and setting the default strings for the instance, a controller for SMS and email can be initiated. A interface for launching SMS or Email can be drawn on screen by calling on the instance.
The interface of the sharing related activity looks like this.

<share>button is added to the list



























Action sheet pop up after <share> button is clicked.

Message to be sent to intended recipient by user.


















Side note: It seems that testing of SMS is not available on Simulator. It might have to be tested on device.

Goals for next week

Fine tune on the interface.

Move on to data structure and database

GSoC 2012 Week 1 Report

WEEK 1(CODE UPLOADED TO GITHUB):

Primary Objective: Get the Core Data set up (in demo app, a data structure (not Core Data) in NSUserDefault were used, which won't be capable of handling large data sets)

Core Data Design

The design of the Core Data entries and relationships are as shown in the figure below:

 Currently, Entity Shop and ItemInShock are not in use. They are intended for storing and showing price in future.

UI Design and implementation

The UI design roughly follows the one runs on Android platform. The currently implemented UI are as shown below:

Shopping List Table View

This table displays all the shopping lists that is stored in the app. This UI is able to achieve the following:

    1. select a created list

    2. create a new list by typing in the tittle

Creating is done by typing in the TextField, and a list would be created in CoreData when return is hit.

SideNote:

*in future, it's possible to skip this UI when lunching the app.

 *How:Select one of the lists based on user's last choice and segue to the List Content Table View

 *Why:Shopping List Table View controller would be pushed into the controller stack, and user would be able hit back in navigation bar and change the list. Besides, the relationship between the two controller is preserved.

List Content Table View

This table displays all the entries within a shopping list. Through interacting with this interface, user would b able to achieving the following:

    1. Add items into the list

    2. Check an items, which will be displayed then in light color and marked with a checkmark(uncheck by clicking again)

    3. Clean Up, hide the marked items from the list

    4. Details, view and edit the details of an item. eg. quantity, unit, tag, notes....

    5. Edit/View List. Toggle between Edit and View mode. Both mode are shown below in the graph

           View Mode: checked and cleaned items are hiden

           Edit Mode:  All items are shown, user would be able to bring back hided items by clicking on the green<+>sign on the right

These two scree shot shows the checked the items and after clicking the CleanUp where the marked items are hided.

This graph shows when entering Edit List mode, the hidden items are shown and can be brought back by clicking the + sign.

Goals for now:

    1.Implement "Options" and "Details" UI. ask for, store and apply user preference.

    2.Implement store based price calculation