Comments for Urban Search and Rescue Simulation

Comment on We’re Back…. Meeting Minutes – 30 Jun 2008 by wagray

wagray — Wed, 02 Jul 2008 03:18:51 +0000

The script/batch file is exactly what we’ll do once we have actual applications created. Right now we’re using Eclipse to compile/build/execute with a lot of dependencies. For awhile I was looking into making an Ant script, but that never came into fruition. Maybe I’ll look into it again.

Comment on We’re Back…. Meeting Minutes – 30 Jun 2008 by Fitzgerald Steele

Fitzgerald Steele — Wed, 02 Jul 2008 02:20:42 +0000

Hmm…sounds like you need a startup script/batch program. Let me know if that’s something I can help with.

Comment on MySQL Problems by Fitzgerald Steele

Fitzgerald Steele — Thu, 24 Jan 2008 02:07:57 +0000

If you want a RAM based DB, take another look at SQLite.

Is it possible to do bulk commits to MySQL? Instead of insert 1 row, say insert a whole chunk of rows?

I still can’t believe that a knowledgable DB person couldn’t give us some other ideas. Youtube is run from MySQL (http://radar.oreilly.com/archives/2007/04/youtube_on_mysq_1.html) – they must get more hits than we do.

Comment on MySQL Problems by wagray

wagray — Tue, 22 Jan 2008 21:56:05 +0000

The issue seems to be that the socket connection between the computer with the robot running and the computer with the DBApp & MySQL server is not keeping up with how fast the sensors are being read. We stripped down a robot to only have 4 sonar sensor which are necessary for automation, but we can’t control how fast we receive data from. Apparently, we receive sonar data every ~50 milliseconds but it takes the MySQL up to 80 milliseconds to store the sensor data. The data keeps piling up on the DBApp end and eventually the data is so far behind it is no longer useful and causes the automation to climb walls and drive over victims.

There isn’t an intuitive way to setup MySQL to run only in RAM, though we tried to get a Live Linux Disk so that everything was running in RAM but had some issues connecting remotely to the MySQL server on that computer.

I believe that our next step is going to be discarding data on the DBApp end so that not every data set is stored into MySQL. Since all the data comes at consistent intervals, we could fill up an array of INSERT statements until all of the sensors are filled, and then store them at once. Rinse and repeat. We would skip the data at the beginning of the queue until we get to laser data (for instance) and start recording all of the subsequent sensor data. Write the complete set of data, and then have the DBApp skip messages until the next laser data set comes through. In this way we could control the number of writes to the DB. The obvious downside to this is that we’ll be losing quite a bit of data, but I think it’s still a reasonable compromise.

I’ll report back when it’s implemented and tested.

Comment on MySQL Problems by Fitzgerald Steele

Fitzgerald Steele — Tue, 22 Jan 2008 16:01:08 +0000

What is the exact problem you’re trying to solve by reducing the lag? What can’t you do because the data is coming in slow? This will help me think of other solutions…

This must be a solved problem…web servers read/write from disk way more often, I would have thought. One possibility…would it be possible to build some type of message queue? Sensors dump data into the queue, and DBApp grabs data from the queue as fast as possible. This would decouple the sensors from the DBApp, but you lose real-time access to data.

Is there someone around Iowa or on the internet that is good at tuning MySQL? Maybe we can talk to a DB person to give us some advice.

Comment on Update as of 15-Jan by Zaid Towfic

Zaid Towfic — Fri, 18 Jan 2008 05:52:05 +0000

Also, you can try to burn a CD of this:

http://slax.hosting4p.com/download.php

The SERVER EDITION. That should have mysql. Knoppix doesn’t have MySQL unless you get the DVD edition (then launch mysqld)

Zaid

Comment on Update as of 15-Jan by Zaid Towfic

Zaid Towfic — Fri, 18 Jan 2008 05:43:06 +0000

http://www.winsoft.sk/ramdisk.htm
it only works for one hour at a time, but should be enough to test hd performance vs. ram.

Zaid

Comment on Update as of 15-Jan by Fitzgerald Steele

Fitzgerald Steele — Thu, 17 Jan 2008 01:56:15 +0000

Still, to have a working/running robot in January is a huge improvement over the last two years.

Way to go, team!

Comment on Update as of 15-Jan by wagray

wagray — Wed, 16 Jan 2008 20:18:08 +0000

Update to the Update:

The actual string parsing & storing in the RobotUtilities is only taking ~50ms, which means the bogging down has to be happening other than the string parsing.

Comment on Adhoc network by Zaid Towfic

Zaid Towfic — Sat, 29 Dec 2007 19:41:12 +0000

Well, the data is binary when transmitted, so images would also work. The 512 byte limit is because of the WCS (last year, this limit was present) It is simple to change it if WCS is changed. The system already splits up very long packets into several 512 byte packets and sends it over and it gets reassembled on the other side. I wonder if we can force each image from the robot to less than 512 bytes (Anyone thinks this is possible?)