Main Page | Recent changes | Edit this page | Page history Printable version | Disclaimers | Privacy policy

Not logged in Log in | Help

DGC Subversion Structure

From DGC Wiki

Contents 1 Related Pages 2 2007 Repository Structure 2.1 Modules 2.2 Packages 2.3 Sites and Targets 2.4 Major Releases 3 2005 Repository Structure 3.1 Subversion Repository Guidelines 3.2 Directory Structure Organization 3.2.1 Standard installation directories 3.2.2 Other directories

Related Pages

• Subversion - Guidlines for the use of subversion.
• Subversion Administration - See this page for instructions on how to administer the code.
• YaM - module and package management tool

2007 Repository Structure

For 2007, the repository is structured for use with YaM. The repository consists of a set of modules (individual programs or libraries) and packages (collections of modules that serve a given function).

Modules

• adrive - actuator interface
• astate - state estimation
• follow - simple trajectory tracking program, for use with CDS 110a
• sparrow - real-time display library

Packages

• cds110a - CDS 110a

Sites and Targets

Major Releases

2005 Repository Structure

Subversion Repository Guidelines

The dgc Subversion repository for the 2005 DARPA Grand Challenge was organized in the following way.

1. Only source text files, should be added to the repository. Code documentation should be included in the header files as Doxygen-style comments.
2. ALL directories should have a README which explains what the function of that code is, what the files contain, and link(s) to documentation, including usage instructions.
3. Code that is in development (i.e. not yet fully tested in simulation and on a vehicle) should always start in dgc/projects.
4. Mature (fully tested) code that is platform independent and may be used by multiple modules should go in the top-level (e.g. RDDF, MTA, sparrow, frames). The exception is hardware drivers.
5. Hardware drivers (sensors and actuators) should go in dgc/drivers, one directory for each piece of hardware, conforming to an API as defined by the embedded systems team.
6. Platform-independent modules (e.g. LadarFeeder, PathFollower) that have fully been tested should go in dgc/modules.
7. Vehicle-specific (i.e. platform-dependent) modules should go in the respective vehicle directory (e.g. alice, bob, homer).

Directory Structure Organization

All of the top-level dgc directories should be documented here.

Standard installation directories

• constants/ - Where all constants are stored.

• bin/ - This is where custom binary files should be installed (nothing should be in Subversion).

• include/ - All headers that are used by more than one program are linked into here.

• lib/ - Custom libraries install location (nothing should be in Subversion).

• local/ - Custom configuration files and scripts.

• projects/ - All development code should start here.

• drivers/ - Tested hardware drivers (sensors and actuators).

• modules/ - Race modules.

• util/ - Utilities that are used by modules

Other directories

• Obsolete/ - Code that is no longer used.

Edit this page | Discuss this page | Page history | What links here | Related changes Main Page | About DGC Wiki | Recent changes |   This page has been accessed 306 times. This page was last modified 06:42, 30 October 2006 by Richard Murray. Based on work by DGC Wiki user(s) Foote and Lars.