Obstacle avoidance

I got some simple obstacle avoidance working with the laser scanner on the virtual robot and documented how to use the simulator on the wiki. I'm going to work on some GPS stuff tomorrow, or perhaps implement an interface that complies with the standards that MCP/Tron are going to use.

Hours worked: 9
Yesterday (14th): 10

playerclient

I got some player stuff to work late today; the people on the mailing list are helpful. With the player server all working, I can tweak the world and such. There's a car chasis model that I'm going to try build around next.

Jordan did a C seminar, tonight, which will help us all when it comes to working with the Ethernuts. We plan on using a couple of Ethernut boards to do all of the communication between the computers (ethernet side) and the sensors/control hardware (I2c side). The code is being written extensibly enough that we'll be able to very easily implement the hardware redundancy that we want.

Hours worked: 10

Full team meeting

We had the full team meeting in the mech-e lab; it was mostly a mech-e discussion. Matt brought up some concerns with using TCP vs. UDP that we need to talk to Tay about. Ken seems to have the drive enclosures under control and wants to get an accelerometer this week to do some testing so he can calculate spring constants. The other mech-e's need a car to work on. :-(

Hours worked: 2

Friday

We talked a lot about cars today in the meeting, and the fact that not having one is holding up our development. Dr. Palmer made the point that we really should bring the Geo up to speed and do some work on it, such that we can easily move it over to a new car that we get. It's also hard for the Mech-es to work or design for something we don't have.

Hours worked: 8
Thursday: 8

Simulator, world file and interfacing

So I've got some code that reads the laser data now and I'm using Paul's .world file, which I edited some. I'm not sure why, but the robot is always dropped, quite literally, into the world, such that it bounces around violently after the simulator starts. Once it stabilizes however, it's easy to do testing with the simulator.

Tuesday, December 7th

Worked on the simulator some today, after the meeting. At the meeting Tay wrote some code to visually plot the route based upon the RDDF...somethign that will be very useful if we decide to use maps. I looked at Worldwind and the Terraservice API, which you can use to grab pieces of maps. I'm working on external code using the gazebo library to meddle with the robot in the simulator.

Hours worked: 9.5

Monday, Dec 6th

I got CVS setup on the G-CART file server today, so that we can keep track of all the code that we're going to generate. We had talked about making a Sourceforge project, but they have some restrictions on what you can do with the code and such. In the end, we want to be able to decide what happens to our code. I also got all of the files moved over from the old Gallery, so we have something to show sponsors now. I reorganized some of the wiki, to make it a more useful piece of documentation.

Since all of that stuff is done....I got some more time to work with Gazebo. The external scripts for it (to watch and prod the simulator) are easy to write using libgazebo. I'm going to try to model what we want in a robot: laser, vision, and position sensors. I'll work out the code with some simple motions in the simulator.

Packets

I talked with Fotios about packets, and he thought it might be a good idea to simply pass serialized objects; we could simply toss arrays about. It makes things a lot easier, and ought to work, as our bandwidth requirements aren't that intense.

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

Thursday, December 2

We worked on sponsors a lot during today's meeting, figuring out what other companies we can ask for money and such. I spent a good chunk of time playing with the simulator (http://playerstage.sf.net) which is quite featureful. I'm going to write some sample code so that I can understand it, and perhaps choose some sensors that we might use on our car, and hack up a virtual version of our car.

Hours worked Thursday: 7
Friday: 4

Wednesday

I got the new machine up yesterday, we have a new gallery, and a machine dedicated for our file repository. Today is time to mess with the simulator, and perhaps work on some sponsorship stuff.

Hours worked: 8