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.