Is there an easy way to download all the source code for WPILib C++ v4.3 at once?

[Randy Forgaard]

I'm wondering if there is a trick to using FIRST Forge that would allow us to download all the source code for WPILib C++ 4.3 in one fell swoop, rather than downloading each of the C++ source files one at a time from the WPILib C++ home at FIRST Forge. I'm not very familiar with FIRST Forge, so I'm wondering if there is a link or command that will download the latest versions of every source file all at once.

We were able to download all the source code for WPILib C++ v4.0 on the WPILib C++ FRC Updates web page. But we are hoping to grab the latest and greatest source code, corresponding to WPILib C++ v4.3, if possible.

If there's no trick, we'll download each file individually, no problem. I just wanted to check. Many thanks!

[TheDominis]

Yes. Download svn from http://subversion.apache.org/packages.html. Once you've installed svn checkout the source from http://firstforge.wpi.edu/svn/repos/wpilibcpp

If you downloaded tigris version of svn (command-line) you can use :

svn checkout --username <username> http://firstforge.wpi.edu/svn/repos/wpilibcpp

[jhersh]

You can also grab the source snapshot of update 4.1. Updates 4.2 and 4.3 don't have different code, just the compiled binary is different (due to build tool problems).

-Joe

[slavik262]

If you want to be tricky, you can always download the update executable and use 7-zip or an equivalent program to extract the files inside.

[jhersh]

Originally Posted by slavik262

If you want to be tricky, you can always download the update executable and use 7-zip or an equivalent program to extract the files inside.

But that will only get you the header files, not the C++ files.

-Joe

[mikets]

BTW, do you have the link to the 4.1 source code? I only find 4.0 source code in the following link:
http://first.wpi.edu/FRC/frccupdates.html

In particular, I am interested in the source code for the ADXL345_I2C code because I want to find out if it does calibration at initialization just like the gyro does. We played with the accelerometer and noticed that the axes values are non-zero when the robot is perfectly still. It wouldn't be too much a problem until we decided to integrate the acceleration for velocity and again for distance. With a non-zero accerleration at rest, the distance will slowly drifted up (or down). It is not too hard to write calibration code at initialization to find the "zero point equivalent" but I just want to make sure the original code does not have this already.

[jhersh]

http://firstforge.wpi.edu/sf/frs/do/...4_1_2 0100205

The included class does not calibrate the accelerometer because most teams using them as a tilt sensor would not want gravity calibrated out since it would cause strange behavior when it does tilt.

-Joe

[mikets]

Tilt is from the Z-axis, right? So I could calibrate the X and Y axes and still get tilt. Another issue with the accelerometer is noise. We would like the calibration process to auto determine the deadband range during initialization. Is there any down side of doing that?
Thanks.

[jhersh]

Any data you throw away (deadband) is lost accuracy when integrating. Typically you should prefer averaging over deadbanding. If your system has too much noise (which has been my experience) then integration simply won't work very well... especially double integration... especially for any length of time.

-Joe

[mikets]

Actually, after thinking about it, I know what you mean now. When the robot is tilted, both the X and Y axes will have some G on it even if it is still.

[jhersh]

Originally Posted by mikets

Actually, after thinking about it, I know what you mean now. When the robot is tilted, both the X and Y axes will have some G on it even if it is still.

Exactly.

[mikets]

Hmm, shouldn't integration smooth out noise? Noise is supposed to be superimposing on the actual value (i.e. it will be above at one point and below at another). So both averaging and integration should cancel out noise in the long run, shouldn't it?