User:Henrik
From DGC Wiki
Contents |
General info
I'm a student that was a member of the team during the summer of 2004 when I did a SURF project on the Arbiter and Gazebo simulation. I stayed 10 weeks at Caltech working on the same thing after SURF ended. Right now I'm graduating in Sweden back home, but I'll stay up to date with Team Caltech remotely!
Teams/Groups
Projects/SubTeams
SURF
Report/presentation
Some pages I've created
Installations
- Boost local installation (copying precompiled)
- Boost local installation (compile)
- Gazebo local installation (copying precompiled)
- Gazebo local installation (compile)
- Gazebo_Stable_Installation
Running howto's
- Running MTA on a local machine
- Running Gazebo
- Running PlayerInterface module
- Running Deliberative Planner in Gazebo
Miscellaneous
- Player_Gazebo_CVS - general info about the latest development of Player and Gazebo CVS HEAD.
- Gazebo User Notes - the latest news on the development of the simulation environment
- KDevelop - a page that tells you alot about a great IDE (Integrated Development Environment) application
- Race_Computers_Status_Chart - the current status at the race computers
- Laptop_Status_Chart - the current status of the DGC laptops
Setting up your .bashrc
For easier development, use my .bashrc (rename to .bashrc) as a template and distribute your own version of it with the dgc/local/scripts/distribute_bashrc.sh script. This is a .bashrc that checks on which computer it's running, making it easier to manage since you only have one .bashrc for all your linux logins! --Henrik 15:20, 21 Oct 2004 (PDT)
Team Caltech API documentation
Team Caltech API documentation
This documentation is generated by the /usr/local/bin/dgc-doxygen script which is executed 4 times a day by a crontab entry.
General thoughts about Team Caltech and the software development
Below are some thoughts and suggestions I came up with during the summer and fall of 2004 when I was working in Team Caltech. --Henrik 07:08, 7 Nov 2004 (PST)
Testing
I think there's a need to push much harder on people writing complete tests for each piece of code. You might think too much time will be spent on the test writing but I can insure you it pays of in the long term (bugs takes huge amounts of time). I think specifically in this kind of project, a very strict policy of "write small piece of code, write test" iterations should pay off very well. A good way of doing this is to use Unit tests. I'm not sure how familiar you guys are with that around here, but it's a good way to test class oriented software in a modularized way. I used a simple unit test suite that is called cxxtest (http://cxxtest.sourceforge.net/) but I know there's more sophisticated support for example in the boost libraries (http://boost.org/libs/test/doc/components/unit_test_framework/index.html).
Simulation
Gazebo is as we know powerful but also has it's limitations, for example the continous development of the CVS HEAD. I think a test suite would be good here too, so the status of the CVS tree can be verified by the instructors before "releasing" it to the students. We don't want to have students sitting complaining about non-working versions of the CVS HEAD. I guess freezing specific revisions of the CVS HEAD or just stick with working with released code is the best way to do it. Currently the released Player/Gazebo code is too old to be useful in a course (for example the position device doesn't give speed or 3D angles at all).
Software development
- The need for a dashboard/telemetry application is obvious (see http://gc.caltech.edu/bugzilla/show_bug.cgi?id=773)
- Tweakable parameters for feeders, mappers, planners to be able streamlining the pipeline with the user interface.
- The mess of makefiles takes alot of time even for the experienced programmer in the team and is a hell to learn for a newbie. Automating this with use of GNU automake tools should be a good thing, but requires some effort made by someone with experience from this field.
- Dependencies: There's some wierd depenencies but I guess it takes too much effort and debugging to get rid of them, but at least it should be easier to compile without getting almost impossible errors to debug, because of them. Now sure about this one...
- Documentation is becoming better and should be written in the SOURCE code and then generated by Doxygen. This is a good way to keep the documentation up to date since the source files are the files the developers are almost always looking at.
- Coding standards. We made a few to start out with, now we just need people to follow them. It is a thing that's used in every company so why don't let everyone learn how to adapt to such thing right now?
- Collect common functions in some kind of global library somewhere, for example degree->radians function and nice-to-have stuff like the Timeval class in MTA and so. Things like that.
- profiling: I think profiling is big must have for the software we make. Since there has been no real analysis about how much cpu different modules use and why there's strange delays sometimes (which might be one module stealing cpu from another executing at the same computer). I did some research on the profiling because gprof (the GNU profiler doesn't support multithreaded programs (which all MTA modules are). It showed that there's an easy fix for this issue. See the Wiki page.
- Logging: generailized and made easier! The Log class in the arbiter is quite custom but has some nice general usage also. Like sending a voter to << prints it very nicely when you've implemented that in the Voter class.
- User interface: while listening, how to do it without lagging down the actual systems. UDP should make it possible to have multiple reciepents and even maybe have this module to sniff the network for the info it wants to display. Multicast requires special hardware?
- Code reviews! I think it's a good thing to have and it pushes people to write good code and make decent documentation.
Contact info
email: kjelland@caltech.edu
ICQ: 1948509
MSN: exton2000@hotmail.com
AIM: exton2k
A picture so you know who I am:
![[Main Page]](../../../../upload/alice.jpg)