Software and team meeting
At the software meeting today we got everyone up to speed on the current design and also did a preliminary design of the packet structures we'll use for data transmission. We're going to use a universal packet class that will make the packets in the same fasion for all of the data that we transfer between the different nodes (mailman, MCP, tron, pathfinding). We decided that we'll just use TCP, even though it probably isn't necessary, as we have a fully isolated, single switch network. Oh well, the overhead isn't more than 10%, tops.
At the team meeting, the MechEs were working on the hard drive mounting system that we talked about at Friday's meeting. The box they've designed is pretty large, which worried me because the IDE HD spec is 18 inches for max cable length. I looked stuff up later, and we can use SATA (max cable length of 1M) or firewire (4.5M).
I did some math on mapping, and found that if we use USGS 1M resolution topo maps (thank you Worldwind), each square mile will take up 18.2 megabytes. Now, check my math. We take the longitude, 0 to 180 (8 bits) and east-west (1 bit), latitude, 0 to 100 (7 bits) and north-south (1 bit), and altitude (15 bits). We also need minutes (6 bits) and seconds (6 bits) for latitude and longitude. We end up with:
Long. Lat. Alt.
8+1+6+6 + 7+1+6+6 + 15 = 56 bits per data point (7 bytes). There are 2,592,100 meter seperated points in a mile (a mile is 1610 meters) and we have 7 bytes per point, so each square mile is 18,144,700 bytes or 18.2 megabytes (7*2,592,100). Does that sound right?
If it is right, we can load some maps on the day of the competition. Last year's route was ~150 miles and the largest lateral boundary offset (from the RDDF using: cat RDDF2004.txt |awk '{print $4}'|sort -n) is 800 feet, 15% of a mile. The only thing that the car needs is the area along the route, and a little bit to either side so it can make it's way around obstacles. That puts us at 30% of a mile given last year's max LBO of 800 feet. If we take a 2,640 foot wide swath (that's 50% of a mile, giving us some oops room) along the route of (no more than) 200 miles, we have 100 square miles of map to give to the car. That's only 1,820 megabytes. Not that much at all.
Hours worked: 5
At the team meeting, the MechEs were working on the hard drive mounting system that we talked about at Friday's meeting. The box they've designed is pretty large, which worried me because the IDE HD spec is 18 inches for max cable length. I looked stuff up later, and we can use SATA (max cable length of 1M) or firewire (4.5M).
I did some math on mapping, and found that if we use USGS 1M resolution topo maps (thank you Worldwind), each square mile will take up 18.2 megabytes. Now, check my math. We take the longitude, 0 to 180 (8 bits) and east-west (1 bit), latitude, 0 to 100 (7 bits) and north-south (1 bit), and altitude (15 bits). We also need minutes (6 bits) and seconds (6 bits) for latitude and longitude. We end up with:
Long. Lat. Alt.
8+1+6+6 + 7+1+6+6 + 15 = 56 bits per data point (7 bytes). There are 2,592,100 meter seperated points in a mile (a mile is 1610 meters) and we have 7 bytes per point, so each square mile is 18,144,700 bytes or 18.2 megabytes (7*2,592,100). Does that sound right?
If it is right, we can load some maps on the day of the competition. Last year's route was ~150 miles and the largest lateral boundary offset (from the RDDF using: cat RDDF2004.txt |awk '{print $4}'|sort -n) is 800 feet, 15% of a mile. The only thing that the car needs is the area along the route, and a little bit to either side so it can make it's way around obstacles. That puts us at 30% of a mile given last year's max LBO of 800 feet. If we take a 2,640 foot wide swath (that's 50% of a mile, giving us some oops room) along the route of (no more than) 200 miles, we have 100 square miles of map to give to the car. That's only 1,820 megabytes. Not that much at all.
Hours worked: 5
posted by Drew Stephens at 6:15 PM
0 Comments:
Post a Comment
<< Home