Free talladega nights software for linux

Python Traffic Analyzer is a Python base class and sample driver script written to retrieve and manipulate images from the TrafficLand cameras and calculate a numeric value representing the current traffic flow.

PyTrAn, an example driver script, an image collector and an image mask creator are available for download from the link shown at the bottom. To use the PyTrAn package begin by choosing a camera that you wish to analyze, for this example well use the camera captioned above.

We want to construct a mask over the area of the image that we are interested in, namely the road. In this particular example the road takes up the majority of the image but that is not always the case.

We will apply the mask over captured images to fine tune the area over which we are looking for movement. To create the mask we will first need to collect a sequential series of snapshots from the target camera. The image_collector.py script was written for this task:

$ mkdir mask_200003
$ cd mask_200003
$ ../image_collector.py 200003 30
Collecting 30 images...
30

Done.

The script is hard coded to capture images on a 2-second delay. The delay is necessary to ensure the image has changed. I believe 2-seconds to be the absolute minimum. Once complete, 30 images numbered 1 through 30 will be created in the current directory.

We construct a mask from these captured images by creating a diff-image for each sequential image pair and then adding each diff-image together. Naturally, a script was written to automate this task as well:

$ ../mask_maker.py 1 30
Creating a diff for each sequential image pair.
Diffing 29

Creating the initial mask from the first image pair.

Adding the rest of the diffs to the mask.
Masking 29

Done.

A number of .diff files are generated in this process. These files repesent the movement between individual sequence pairs.

The .diff files are simply intermediary files, the important bit is the mask file, which is generated as the sum of all differences.

The mask file may be dirty (as in this case) and require manual cleanup. The basic shape of the road however is clearly visible, evidence that we can with minimal effort automate the mask generation process. Also, this run was conducted at night, day-time images yield better results.

There are a few final steps we need to take before we can use the example PyTrAn driver script. First we need to convert the mask to ASCII (noraw) format:

$ pnmnoraw mask > mask_200003.ascii

Then we need to open an ImageMagick display window and get its X-window-ID using xwininfo. Finally, update camera_id and window_id in pytran_sampling.py and launch the driver:

$ ../pytran_sampling.py
DEBUG> grabbing frame from camera 200003
DEBUG> rotating image: pytran.this > pytran.last
DEBUG> refreshing image in 3 secs
taking a 5 minute sample at various thresholds.
DEBUG> grabbing frame from camera 200003
DEBUG> generating frame diff on pytran.last, pytran.this
DEBUG> displaying image: pytran.diff
DEBUG> converting pytran.diff to ascii
DEBUG> calculating traffic ratio...
ratio[5]: 55%
DEBUG> calculating traffic ratio...
ratio[10]: 52%
...
...
5 minute sample[5]: 67.88
5 minute sample[10]: 42.66
5 minute sample[15]: 30.57
5 minute sample[20]: 23.03
5 minute sample[25]: 18.39
5 minute sample[30]: 14.79
5 minute sample[35]: 12.42
5 minute sample[40]: 10.53
5 minute sample[45]: 9.06
5 minute sample[50]: 7.85

The sampling script will take 5 minute samples at varying color thresholds. The optimal threshold must be manually chosen. Furthermore, you will need to sample the traffic ratios during both heavy and light traffic times to get a good feel for your acceptable range. Also, keep in mind that the traffic ratio value is simply the percent change detected, or in other words the movement detected within the masked region. This means that a completely empty road will register similar values to a road so congested it looks like a parking lot. The time of day can be combined with the traffic ration to determine the logical truth.

With this task implemented and abstracted more complex systems can be built. When I find the time Id like to create a system that will take multiple potential travel routes and times, and during the travel time e-mail the traveler with the best route to take. Another idea I had would be to record the traffic flow values for each camera, for each day and for each half hour interval. Travelers and other interested parties can then analyze traffic patterns to determine the fastest route dependant on date/time.

The FlightGear flight simulator project is an open-source, multi-platform, cooperative flight simulator development project. Source code for the entire project is available and licensed under the GNU General Public License.

The goal of the FlightGear project is to create a sophisticated flight simulator framework for use in research or academic environments, for the development and pursuit of other interesting flight simulation ideas, and as an end-user application. We are developing a sophisticated, open simulation framework that can be expanded and improved upon by anyone interested in contributing.

There are many exciting possibilities for an open, free flight sim. We hope that this project will be interesting and useful to many people in many areas.

FlightGear is a free flight simulator project. It is being developed through the gracious contributions of source code and spare time by many talented people from around the globe. Among the many goals of this project are the quest to minimize short cuts and "do things right", the quest to learn and advance knowledge, and the quest to have better toys to play with.

The idea for Flight Gear was born out of a dissatisfaction with current commercial PC flight simulators. A big problem with these simulators is their proprietariness and lack of extensibility. There are so many people across the world with great ideas for enhancing the currently available simulators who have the ability to write code, and who have a desire to learn and contribute. Many people involved in education and research could use a spiffy flight simulator frame work on which to build their own projects; however, commercial simulators do not lend themselves to modification and enhancement. The Flight Gear project is striving to fill these gaps.

There are a wide range of people interested and participating in this project. This is truly a global effort with contributors from just about every continent. Interests range from building a realistic home simulator out old airplane parts, to university research and instructional use, to simply having a viable alternative to commercial PC simulators.

Flight Dynamics Models

With FlightGear it is possible to choose between three primary Flight Dynamics Models. It is possible to add new dynamics models or even interface to external "proprietary" flight dynamics models:

1. JSBSim: JSBSim is a generic, 6DoF flight dynamics model for simulating the motion of flight vehicles. It is written in C++. JSBSim can be run in a standalone mode for batch runs, or it can be the driver for a larger simulation program that includes a visuals subsystem (such as FlightGear.) In both cases, aircraft are modeled in an XML configuration file, where the mass properties, aerodynamic and flight control properties are all defined.

2. YASim: This FDM is an integrated part of FlightGear and uses a different approach than JSBSim by simulating the effect of the airflow on the different parts of an aircraft. The advantage of this approach is that it is possible to perform the simulation based on geometry and mass information combined with more commonly available performance numbers for an aircraft. This allows for quickly constructing a plausibly behaving aircraft that matches published performance numbers without requiring all the traditional aerodynamic test data.

3. UIUC: This FDM is based on LaRCsim originally written by the NASA. UIUC extends the code by allowing aircraft configuration files instead and by adding code for simulation of aircraft under icing conditions.

UIUC (like JSBSim) uses lookup tables to retrieve the component aerodynamic force and moment coefficients for an aircraft... and then uses these coefficients to calculate the sum of the forces and moments acting on the aircraft.

Extensive and Accurate World Scenery Data Base

Over 20,000 real world airports included in the full scenery set.
Correct runway markings and placement, correct runway and approach lighting.
Taxiways available for many larger airports (even including the green center line lights when appropriate.)
Sloping runways (runways change elevation like they usually do in real life.)
Directional airport lighting that smoothly changes intensity as your relative view direction changes.
World scenery fits on 3 DVDs. (Im not sure thats a feature or a problem!) But it means we have pretty detailed coverage of the entire world.
Accurate terrain worldwide, based on the most recently released SRTM terrain data.) 3 arc second resolution (about 90m post spacing) for North and South America, Europe, Asia, Africa, and Australia.
Scenery includes all vmap0 lakes, rivers, roads, railroads, cities, towns, land cover, etc.
Nice scenery night lighting with ground lighting concentrated in urban areas (based on real maps) and headlights visible on major highways. This allows for realistic night VFR flying with the ability to spot towns and cities and follow roads.
Scenery tiles are paged (loaded/unloaded) in a separate thread to minimize the frame rate hit when you need to load new areas.

Accurate and Detailed Sky Model

FlightGear implements extremely accurate time of day modeling with correctly placed sun, moon, stars, and planets for the specified time and date. FlightGear can track the current computer clock time in order to correctly place the sun, moon, stars, etc. in their current and proper place relative to the earth. If its dawn in Sydney right now, its dawn in the sim right now when you locate yourself in virtual Sidney. The sun, moon, stars, and planets all follow their correct courses through the sky. This modeling also correctly takes into account seasonal effects so you have 24 hour days north of the arctic circle in the summer, etc. We also illuminate the correctly placed moon with the correctly placed sun to get the correct phase of the moon for the current time/date, just like in real life.

Flexible and Open Aircraft Modeling System

FlightGear has the ability to model a wide variety of aircraft. Currently you can fly the 1903 Wright Flyer, strange flapping wing "ornithopters", a 747 and A320, various military jets, and several light singles. FlightGear has the ability to model those aircraft and just about everything in between.

FlightGear has extremely smooth and fluid instrument animation that updates at the same rate as your out-the-window view updates (i.e. as fast as your computer can crank, and not artificially limited and chunky like in some sims.)

FlightGear has the infrastructure to allow aircraft designers to build fully animated, fully operational, fully interactive 3d cockpits (which even update and display correctly from external chase plane views.)

FlightGear realistically models real world instrument behavior. Instruments that lag in real life, lag correctly in FlightGear, gyro drift is modeled correctly, the magnetic compass is subject to aircraft body forces -- all those things that make real world flying a challenge.

FlightGear also accurately models many instrument and system failures. If the vacuum system fails, the HSI gyros spin down slowly with a corresponding degradation in response as well as a slowly increasing bias/error.

Moderate Hardware Requirements

The intention of FlightGear is to look nice, but not at the expense of other aspects of a realistic simulator. Our focus is not on competing in the "game" market and not on the ultra-flashy graphic tricks.

The result is a simulator with moderate hardware requirements to run at smooth frame rates. You can be reasonably happy on a $500-1000 (USD) machine (possibly even less if you are careful) and dont necessarily need $3000 (USD) worth of new hardware like you do with the many of the newest games.

That said, the more hardware you throw at FlightGear, the better it looks and runs, so dont feel like you have to chuck your expensive new hardware if you just purchased it. :-)

Internal Properties EXPOSED!

FlightGear allows users and aircraft designers access to a very large number of internal state variables via numerous internal and external access mechanisms. These state variables are organized into a convenient hierarchal "property" tree.

Using the properties tree it is possible to monitor just about any internal state variable in FlightGear. Its possible to remotely control FlightGear from an external script. You can create model animations, sound effects, instrument animations and network protocols for about any situation imaginable just by editing a small number of human readable configuration files. This is a powerful system that makes FlightGear immensely flexible, configurable, and adaptable.

Networking options

A number of networking options allow FlightGear to communicate with other instances of FlightGear, GPS receivers, external flight dynamics modules, external autopilot or control modules, as well as other software such as the Open Glass Cockpit project and the Atlas mapping utility.

A generic input/output option allows for a user defined output protocol to a file, serial port or network client.

A multi player protocol is available for using FlightGear on a local network in a multi aircraft environment, for example to practice formation flight or for tower simulation purposes.

The powerful network options make it possible to synchronize several instances of FlightGear allowing for a multi-display, or even a cave environment. If all instances are running at the same frame rate consistently, it is possible to get extremely good and tight synchronization between displays.

Flight Gear and its source code have intentionally been kept open, available, and free. In doing so, we are able to take advantage of the efforts of tremendously talented people from around the world. Contrast this with the traditional approach of commercial software vendors, who are limited by the collective ability of the people they can hire and pay. Our approach brings its own unique challenges and difficulties, but we are confident (and other similarly structured projects have demonstrated) that in the long run we can outclass the commercial "competition."

Contributing to Flight Gear can be educational and a lot of fun. A long time developer, Curtis Olson, had this to say about working on Flight Gear:

Personally, Flight Gear has been a great learning experience for me. I have been exposed to many new ideas and have learned a tremendous amount of "good stuff" in the process of discussing and implementing various Flight Gear subsystems. If for no other reason, this alone makes it all worth while.

bwstats will report on how much data has been received and transmitted over each live interface since the system was booted up. bwstats project will also attempt to predict bandwidth usage over the next 30 days based on current usage. I wrote this out of curiosity to see how much data I was shifting about each month; the results were interesting.

At present bwstats will only run on Linux and other systems with the /proc filesystem as the interface statistics are obtained from /proc/net/dev and /proc/uptime files. Sorry.

Improvements to come include the ability to carry over data from the previous reboot so that the results are meaningful for those who power down their computers each night, and the ability to change the period for which predictions are made (currently this is trivial but means editing the source).

Note: since I wrote this tool I have noticed that the figures in this /proc/net/dev file wrap around after they reach a certain figure, therefore skewing the figures when data reaches beyond around 4.2GB (damn Linux kernel!). This will be obvious when looking at the figures. This script will still work perfectly up until the point where the wrapping occurs. This will be fixed in a future release, but for now be warned!

Samples are loaded into memory and playback is then triggered or stopped. The system mixes any number of concurrently playing samples together (up to a predefined maximum).
Also possible is the inclusion of a background MP3 soundfile (external program "mpg123" required). Since version 1.4 panning and volume control has been added. Since version 1.5 each playing sample can be controlled individually.
Currently this multithreaded library is set to mix a maximum of 12 concurrent 16bit signed stereo samples at 44100Hz. The included wav2raw.sh shell-script will take any file with the extension .wav and convert it into the proper .raw format used by libgaudio. The total number of samples that can be loaded is 256. The total size of samples depends on the main memory of the computer.
System load on my P3-450 is about 4% for the MP3-player and 0.5-4% for the testaudio application.
See the sample program "testaudio.c" for a demo implementation. Get the seperatly distributed file "Sample.mp3" (any .mp3 will actually do, but it has to be called Sample.mp3 for testaudio.c to use it) and activate its playback in the test application by editing the Makefile.
A second sample program called "halloween.c" shows how easy it can be to load
multiple WAV files and play them back at random. This was a great effect during
Halloween night. Start it up with the seperatly distributed "ScarySounds" WAV files
for a cool effect.
Enhancements:
- Added support for libsndfile (included). No more RAW audio loading required. Any WAV file can be loaded now.
- Added ScarySounds collection (distributed seperately) and halloween.c demo application.
- Added function to query MP3 stream playing time.

Fair NAT is a script for configuring NAT on dedicated Linux routers. This is the home of my linux router shaper script which allows something like fair bandwidth sharing among clients in the local network. The script is not great or anything - please dont expect the holy grail here - I just thought Id publish it because many people helped me write it and maybe someone has some use for it. I bet there are still lots of things that can be improved. Sorry about the crappy design of this page, I dont have time to put more effort in better looks.
You have a certain number of Clients (User A - User N) in your LAN which are connected by a Switch (or a Hub or BNC) to the Linux Router which is supposed to act as a gateway to the internet. The trouble now is, User B has a lot of downloads running and User C uploads stuff day and night, which leaves User A who only wants to use an interactive SSH shell in the rain, since B and C already use up all bandwidth the internet connection offers.
What we need to do is to share available bandwidth fairly among clients. In order to achieve this, I first tried several searches at Google and Freshmeat. This turned up quite a lot of results, like the Linux Advanced Routing & Traffic Control HOWTO which is a must-read and also contains great scripts, like the Wondershaper for single users. Another great general purpose script I found was HTB.init, which doesnt do anything by default, but gives you an easy way to setup HTB queues. In case you prefer CBQ, theres a CBQ.init too. If you dont know what Im talking about, read the HOWTO above or continue reading here.
Since I never found a script that did exactly what I wanted, I decided to write my own. Its designed to be an all-I-need script, therefore it does not just setup Traffic Shaping, but Masquerading and Port Forwarding too. In short, it does everything that has to do with IPTables and Traffic Control. I use HTB (Hierarchical Token Bucket) to share bandwidth among clients (one class per client). On top of that I added a PRIO queue to prioritize interactive traffic on a per-user basis. On top of PRIO I set SFQ to treat connections fairly. In version 0.72, experimental support for IPP2P to recognize peer-to-peer traffic was added.
This is the simplified scheme for routing:
HTB class (for bandwidth sharing)
|
-- PRIO (for prioritizing interactive traffic)
|
--- Interactive: SFQ (to treat concurrent connections fairly)
--- Normal: SFQ
--- High-Traffic: SFQ
[ --- P2P: SFQ (if IPP2P support is enabled only) ]
I bet this can still be improved and Im always interested in ways to do so. In case you want another class structure, this can be done by replacing the parent_class and user_class functions in the script. See CLASS_MODE in Configuration section and the function documentation in the script for details. Feel free to send me your own functions with a short explanation, if you want me to make them available for everybody.
Heres a "real" graphic, which shows the complete qdisc/class structure on $DEV_LAN if you use the unmodified example configuration file. This graphic was created using a hacked version of Stef Coenes show.pl script and GraphViz. Click here to see it, but I warn you: its quite big. Heres a similar picture, which includes IPP2P support. Note that there are more filter rules (the blue arrows) now which put the filesharing traffic into the users prio band 4.
Main features:
- This is a variable with a space-separated list of features that should be enabled. Default is all enabled if you dont set this variable.
- PROC:
- Allow Fair NAT to change some system variables in /proc, like setting /proc/sys/net/ipv4/ip_forward to 1.
- MODULES:
- Try to load kernel modules for QoS first.
- RESET:
- Fair NAT will replace all existing iptables rules with a very basic (empty) configuration. Not healthy for firewalls. You can disable this feature to keep the original rules in place. See Firewall Support below.
- NAT:
- Allow Fair NAT to configure NAT. You could disable this if you prefer to set this up yourself / let your firewall do it.
- FORWARD:
- Allow Fair NAT to configure Port Forwarding. Same as NAT, you can disable this if you dont need it.
- QOS_DOWN:
- Shape download traffic. If you know a little bit about traffic shaping and believe that download shaping is completely useless, feel free to disable this.
- QOS_UP:
- Shaping upload traffic can be disabled also. If you disable this and QOS_DOWN also, you could use Fair NAT for setting up NAT and Port Forwarding only, although thats not really the purpose of the script ;-)
- TOS:
- Allow Fair NAT to modify the TOS (type-of-service) field of packets. Right now, Fair NAT relies on this TOS field for shaping, so using this feature is highly recommended.

Dial-Up Bot project aims to be a fully functional automated replacement for the /etc/ppp/ip-{up,down}.d hierarchy. Its supposed to be started by cron at night. It cant satisfy the requirements of impatient roots. Its not designed for hosts with a permanent Internet connection.
Enhancements:
- This is the first public release since dubot reached minimal useful functionality and stability. Installation mech is minimally stable (at least for install in /usr/local hierarchy).