MGC Development Tools

The following is an overview of all software and/or hardware tools, as well as standards, the Mini Grand Challenge team uses.

= System Dependencies =

Software Components
Operating System: Fedora 11.

Fedora is one of the most supported distributions of Linux, and is updated frequently. We chose Fedora because of its ease of use, but also because its power is not hidden from advanced users. We do not officially support other distributions or operating systems, though all of our tools are standard and should compile correctly for any other UNIX/unix-like system as long as the dependencies are supported.

Programming Language / Compiler: GNU GCC/G++

C/C++ are high-performance languages that allow us to create well designed modular code that takes advantage of the fast run-times and object oriented features. The free GNU GCC/G++ compilers provide us with the needed functionality and interface with other needed tools.

Robot Interface: Custom code & CMU IPC

Carnegie Mellon University's Inner Process Communication library is a method of having completely independent processes (on one or more computers) communicate efficiently over a number of different methods. This is used such that we can have multiple processes interfacing with different hardware, all on independent timing schemes. The club used to use Player/Stage for this component in the past.

Image Processing: OpenCV

OpenCV, originally created by Intel, is a powerful image processing library that allows us to capture images from our webcam, perform many different analysis functions on them, and even display them through a simple GUI system that is incorporated in the library. This makes our image processing tasks much more manageable, as there are many many different functions in the OpenCV library.

Data Visualization:OpenGL

OpenGL is a cross platform framework for graphics representation. It provides a clean visualization of our data to help us make adjustments.

Arduino Interface: Custom Client

We have written a small client program to run on the Arduino and communicate with the host computer over a serial interface. This client is able to recieve speed and direction commands, as well as report sensor data back from the compass and sonars attached via I2C to the client computer.

GPS Interface: GearBox Project

The Garmin GPS "puck" we use requires some proprietary code. Fortunately, the team has found the GearBox project that allows us to interface with the device without too much difficulty.

Source(s): Software solutions

Hardware Components
''This list is out of date as of Spring 2010. Please see Mini Grand Hardware.''

Platform: Fisher Price Power-Wheels F-150.

This platform is available across the country in department stores for under $200, and provides a robust starting point for modification. Its solid construction was meant to take abuse, so it seemed fitting to use for an autonomous robot.

Controller Board: Arduino Diecimila.

This microcontroller is an open source platform based on the Atmel ATMega168 chip. The Arduino is very versatile, and easy to use with the IDE provided. The programming language is a fairly straightforward C/C++ language, with support for special functions coming from different libraries. It supports 2 servos with its hardware timers, I2C bus communication, digital I/O, analog in, hardware/software serial, and more.

The Arduino is supported under Windows, Linux, and Mac OS with their custom IDE, written in Java. However, due to the open nature of the device, one can use other IDE's such as Processing or MAX/MSP. Their hardware design, bootloader, and software are all available from Arduino.cc

Locomotion: Hitec EZX Electronic Speed Controller.

This is a standard electronic speed control for use in remote controlled cars. The controller is typically used with 7.2 - 8.4 volt battery packs, but we use it with out 6v drive batteries. There were initially some concerns about how the unit would react to two motors, but it rarely even heats up. It is fully programmable for forward, reverse, and center, and accepts servomotor PWM signals.

The motors we are using are the stock power-wheels motors that come as part of the whole platform.

Steering: Hitec 805BB 1/4 Scale Servomotor.

Available from any reputable hobby shop, this large servomotor provides more than enough torque to keep our front wheels pointed in the right direction. The stock steering system had to be modified slightly to account for the servo, we achieved this task by fabricating a simple bracket to go between the servo and the wheels. However, the same task can be achieved by using common tools and some parts from any hardware store.

Laser: Hokuyo URG-04LX Laser Sensor.

This is a very powerful sensor, and provides the basis for much of our decision making. It is capable of imaging on about a 240 degree radius, and provides ranges up to 10 meters with high precision. The one caveat is that it uses an infra-red laser, so the medium being detected must be able to reflect infra-red light. Otherwise, inaccurate readings are possible.

Sonar: Devantech SRF08 Ultrasonic Range Sensor.

We employ two of these sensors, one in the front and one in the back to provide general information about the proximity of our robot to objects around it. Although our laser is capable of high precision imaging, it is pointed down at the road, so it will not sense an obstacle until it is very close. The sonar can fill this gap by providing warning that an obstacle is being approached. These sonars detect objects in a 30 degree cone, and are accurate up to and beyond 12'.

Cameras: Logitech QuickCam Pro 5000.

We use two of these cameras for our image grabbing needs. They are compact, cheap, and provide reasonably good image quality at a 640x480 resolution. They interface to our laptop through USB, and can be interfaced with Windows and Linux with the proper drivers.

GPS: Garmin GPS 18 PC with serial connection.

The Garmin GPS 18 PC is a cheap off-the-shelf device that allows us to measure how close we are to waypoints. Though it is not accurate enough for localization and path planning needs, it is great for use with verification of how far along the vehicle is on the course.

= Software Tools =

Source Control
All project members are required to use the Subversion Source Control tool (SVN). This is to prevent code loss, promote access to all developers, and allow for quick code reviews. Feel free to commit code that works or not, and use the team mailing list as a resource for help. When developing on a file, please lock the file so that others do not edit the file and have a merging issue when committing the source back to the server.

Please read the article on SVN to access the Mini Grand 2009/2010 code. The current SVN can be found at http://svn.psurobotics.org/Minigrand10. We have an online source browser found here. (Select Minigrand10 from the top-right drop-down menu)

Bug-Tracking
Please use the team mailing lists to discuss about any major bugs or issues with the current revision of the code: L-MiniGrand-UP@lists.psu.edu

Compiler standards and Makefile
The solution is targeted for the Player/Stage platform, thus is restricted to GNU C/C++ on a Unix-Like Operating System. Other dependencies, such as audio and visualization tools, should also target GNU C/C++ on Unix-Like Operating Systems. We currently target the Fedora 8 distribution.

Makefiles are also important so that we can create code compatible on multiple systems and independent from any IDE's. Here is a good example of an efficient use of a makefile. The makefile system for the Minigrand09 solution was documented, through the Revamping makefiles article.

Continuous Integration
Once a day, a daemon process on the club server will attempt to do multiple jobs in order to help developers by providing extra tools:


 * Doxygen will build a document on the current source code, our daily builds are found here
 * The latest version of the software will be built, emailing any compile-time issues to the team mailing list
 * A copy of the SVN will be made and uploaded to a secondary server

Virtual Machine
In order to keep things as simple as possible for developers, a Virtual Machine image, or VM image, was created. This is simply a full operating system that can be run within a virtualized system such as VirtualBox or VMware. This virtualized system is also fully installed and ready to go, will all dependencies, databases, and tools pre-installed. This is your full developers environment in one simple neat package.

Installing
All you need is a virtual machine and an image, both being free and provided by the club. The virtual machine system we use is Sun's VirtualBox. Download and install this tool first. Next, you will want to download two major files that represent the VM image. You must download the setup file and the disk image. Once these files are downloaded, you will need to load them into VirtualBox. You can do this in VirtualBox by selecting "Import Appliance...", and choosing the *.ovf setup file.

The system's root password is "psurobotics", in which the SVN project folder is found on the directory. All library files are pre-installed and no special instillation will be needed.

Simple instructions


 * 1) Download Sun's VirtualBox
 * 2) Install Sun's VirtualBox
 * 3) Download setup file
 * 4) Download disk image
 * 5) Use "Import Appliance..." in VirtualBox on Robotica.ovf
 * 6) Log into the virtual machine with the password "psurobotics"

= Coding Standards =

The below lists a few coding standards developers should follow to help with the development process, help working as a group, help with documentation, and ultimately help with creating good code. We will be using the WebKit Open Source Project's coding standards found here. Make sure you are familiar with the standard before contributing to the project.

Certain exceptions are made, as discussed below:

Top of File Comments
Each file should begin with a conforming header file that includes project information, copyright, author name and contact information, and file description. The reason to do this is because header files include source prototypes, are are commonly as a reference file when developing code. Having this extra information helps decipher sections of code.

Please use the bellow as a format to begin all header files:

Please use the bellow as a format to being all source files:

Documentation markup
We will be generating Doxygen documents from our code base, so please mark all code with Doxygen markup comments. All comments simply need an exclamation point and, if wanted, a keyword to help organize code. For example:

Function Body
The webkit standard states that the first curly brace "{" must be on the function prototype line. We will not be following this, instead all curly braces should be on their own lines.

This is wrong:

This is right:

Try/Throw/Catch
Try/throw/catch blocks are powerful tools in C++ but can be easily abused, giving the application a very low run-time speed. Do not use these unless it is to catch an error from an external library. Use the custom Assert function provided by the project's code.

Inclusion Guard
Always use an inclusion guard to prevent multiple declarations. The WebKit standard stipulates that the identifier match the name of the header (including case), replacing '.' with '_'.

C/C++ Heap Allocation & Pointers
As mentioned at the top of this article, we strongly suggest you read the articles in Programming Practice and Methods to familiarize yourself with our tools and technologies. This is even more critical for the topic of heap allocation and pointers, as they are a difficult topic. Please see our Pointers article.