Tuesday, January 31, 2012

Meta Software Report

Over the past week I have gotten the Git repository, blog, and other metadata management tools up and running. Learning Git has taken longer than I expected, but I think it will pay off in the long run. Instead of wondering what other members of the team are up to all you have to do is look at the repository, and all the changes are listed there neatly and in order. With the source code control I can efficiently test out new ideas without affecting the master branch. If the idea works than I can merge it back into the master branch, and if it fails then I can discard the branch without any change to the master. That is the power of source code control.

In addition, by hosting our project on a proper project management site we get all the additional features: a central repository, a useful wiki, a bug tracking feature, and more. Good organization is one of the most useful features of a project, and we now have the framework for the rest of the year. Thirty hours later and it's up and running smoothly.

The next step is to begin working on the Spin code for the MPU-6050 Eval board. I put it off in the last week in order to get git up and running, but now that the dust is settling it's time to get coding. It will be challenging to figure out the model and representation necessary to get flying, but that's a week or two out anyway.

An update from Luke

This week we made it a huge effort to have everything accessible from the web. We have completely set up Git for our SVN Repository. A wiki has been created and we are currently pushing all of our Google Documents over to it. There has been lots of progress with the custom circuit board.

I have reached the stage of the circuit board that I would have liked to be at and I am nearly ready to have it made.
A plan of ours it to make it down to UCSD to meet with Dr. Kastner about his current UAV projects that he is researching. Cody and I feel like this would be a great experience to try to ask what problems and possible solutions we could expect in our own project.

This week I have put in over 28 hours on the research.

Heat management is a critical aspect in every project and is currently my upmost concern. 

For next week we would like to have all of the Web stuff finished and self cleaning. We would also like to meet with Dr. Kastner this Friday, however that all depends on his schedule. Last I would like to start working on reworking the design of the power board for better heat management.

--Luke

Sunday, January 29, 2012

Source Code Control with Git

Source code control is now set up and running! Check out code.anzhelka.com for up to date progress on our project.

I selected Git for the source code control system. The alternative is SVN, but I choose Git based on my research online:
-Git is faster
-Git doesn't need a central server
-Each person on the project has a complete copy of the code with history

So, how are we using it? Some useful commands:

Getting and Pushing from the Server:
Put the following line in a file called .netrc in your home directory (on Ubuntu at least...).
machine code.google.com login username@anzhelka.com password XXXXXXXXXX

From there, you can
Download all files: git clone https://code.google.com/p/anzhelka/
Upload all files: git push origin master

Sometimes, we create a new branch that we want to share:
Push a new branch to server: git push origin <branchname>

For others to get that branch on their local repo:
Update their copy: git fetch origin
Switch to the branch: git checkout --track origin/<branchname>

Notes on pushing and fetching branches here.

Staging Index:
Add all files in directory (including sub directories)*: git add .

Add specific file to index: git add <filename>
Remove specific file from index: git reset <filename>
View files in index: git status

*Note the period at the end, and note that this will also add temporary files (such as files with '~' on Ubuntu)

Committing:
Make a commit*: git commit -m "Your commit message"
View commit log: git log

*adding -a will automatically add any modified files to index before the commit

Branching:
Create a new branch: git branch <name>
Delete a branch*: git branch -d <name>
List all branches: git branch -a
Switch branches: git checkout <name>
Merge branch: git merge <name of branch to pull into current one>

*Branches still need to be deleted after merging...

Rebasing:
Rebasing allows compressing multiple commits to a branch into a single commit. This is useful for doing things like cleaning up the commit history while still allowing a developer the flexibility to commit after every small change.

Proper Git etiquette is to rebase all small changes into a single commit before pushing to the central repository.

Interactive rebasing: git rebase -i origin/master (should this be <name> instead?...)

To turn a branch from main that has been merged back in all to a single, linear flow use the command below. This is useful turning the history of a project from one with lots of branches that have been merged to one with a single linear progression.
git rebase <branch name>

To rebase the current (checked out) branch, you should use the command
git rebase -i HEAD~n
Where n the number of most recent commits that you want to have the option of rebasing.

Notes on rebasing here and on squashing commits here.

Etiquette:
-All commits should have a useful message.
-All new features should be implemented in a branch.
-Branches should only be deleted upon merging.
-Before a branch is merged it's commits should be cleaned up by rebasing.
-A branch should not be rebased into a single linear flow as described above.
-The master branch is always in a releasable state


Conclusion:

Finally, gitk and giggles are useful GUIs on Ubuntu for viewing and working on the repository.

Note: this post will be updated with new commands and Git etiquette that we have found or made.

Tuesday, January 24, 2012

An update from Luke!


We have received all the chassis parts for the Quad copter itself
including the motors, ESCs, and some of the IMU parts.

I have started design of the custom circuit boards that will be used on
the quad copter. Half the parts have been either ordered or sampled
from various manufactures.

We had planned to have the circuit boards designed, however that has
proved to be more difficult due to component availability.

We are working diligently to complete the tasks from last week and are doing
more research on parts and componets; and interfacing all the devices
together.

I have spent approximately 15 hours (this is a rough estimate and is
most likely even more than that).

Most Critical questions include:
What is the best way to ask for free parts from companies? Is there
some form letter or Tax ID we can provide the company?

The plan is to have the circuit board designed and shipped out to the
PCB mil factory. We hope to have more of our parts in. Lastly, we
would like to be able to get some sort of demonstration ready.

--Luke

An update from Cody!

A short summary of where we are right now:

We have selected all of parts for our initial build (link) and have received them from the various manufactures. It turns out that our quadcopter will be about $800 total (estimated) for the first few builds.

I'm happy with where we are at so far, after maybe 30 hours of work in the last week. I'm working on getting the MPU-6050 working with the Propeller and seeing if I can get acceleration and gyro values out of the chip. The main issue with the 6050 is that it's not very well documented: the motion processing unit (the main feature of the chip) has almost no documentation, and all information has to be gleaned from reverse engineering the chip.

The critical question facing me right now is how to get the quaternion data from the 6050. It's going to be a pain to try and recover that, but once I get it out of the chip then I'll be golden and on to the next challenge: managing the control of the quadcopter. In the next week I hope to get the 6050 up and running, and get all the other code going for things like wireless, PWM, SD card, etc.

This is just the software, the hardware is a whole other ball game.


Welcome to the Anzhelka project. We are working hard to create an autonomous aerial video platform to fulfill our senior capstone project in computer engineering at the University of California, Riverside. This project is documented at our blog

blog.anzhelka.com (alternate link)

We will be producing all sorts of files for this project, including Spin code, PC code, PCB schematic and layout files, CAD files for the frame, and construction notes for the whole thing. All this will be documented at

code.anzhelka.com (alternate link)



Cody Lewis (SRLM) srlm@anzhelka.com
Luke DeRuyter

Monday, January 23, 2012

Hello World!