DARPA will give you a million dollars if you can create a self guided land vehicle. There must be some elegant solution. -Jeff M.
Tie a rope to the stearing wheel, put a brick on the gas pedal. Bingo, self-guided vehicle.
--- Jeffrey Martin dogshed@gmail.com wrote:
DARPA will give you a million dollars if you can create a self guided land vehicle. There must be some elegant solution. -Jeff M. _______________________________________________ Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug
On Fri, February 4, 2005 4:04 pm, Jeffrey Martin said:
DARPA will give you a million dollars if you can create a self guided land vehicle. There must be some elegant solution. -Jeff M.
If you've seen the first round of trials, you'll know it's not as easy as it looks.
Quoting Jonathan Hutchins hutchins@tarcanfel.org:
If you've seen the first round of trials, you'll know it's not as easy as it looks.
Jonathan, have you changed any settings on you email client today? I'm getting duplicate messages from you and your single quotes are being escaped with a slash as in the above message.
-- Dave Hull http://insipid.com
On Friday 04 February 2005 07:40 pm, Dave Hull wrote:
Quoting Jonathan Hutchins hutchins@tarcanfel.org:
If you've seen the first round of trials, you'll know it's not as easy as it looks.
Jonathan, have you changed any settings on you email client today? I'm getting duplicate messages from you and your single quotes are being escaped with a slash as in the above message.
I'm afraid the double posts are my fault - jumpy finger on the send button.
The escaped apostrophes just started showing up when I run Squirrelmail on Konqueror/Gentoo. Haven't tracked that down yet, it didn't use to do that.
Was playing around on speedguide.net and ran their analysis tool for MTU RWN etc. My WinXP box showed exactly what I expected in the report. My Suse 9.0 box showed the report below. Any ides on the RWIN of 5808? Ran two different browers with no change and followed there recommendation here: http://www.speedguide.net/read_articles.php?id=121 on adding these commands into boot.local. No dice...
I'm a bit skeptical since my speed tests with SBC show the bandwidth of my DSL connection. I would have figured that 5808 would create so many acks that speed would be sacrificed...????
Ideas??
TCP options string = 020405ac0101040201030300 MTU = 1492 MTU is optimized for PPoE DSL broadband. If not, consider raising MTU to 1500 for optimal throughput. MSS = 1452 MSS is optimized for PPPoE DSL broadband. If not, consider raising MTU to 1500 for maximum throughput. Default Receive Window (RWIN) = 5808 RWIN Scaling (RFC1323) = 0 bits Unscaled Receive Window = 5808
RWIN is a multiple of MSS Other values for RWIN that might work well with your current MTU/MSS: 511104 (MSS x 44 * scale factor of 8) 255552 (MSS x 44 * scale factor of 4) 127776 (MSS x 44 * scale factor of 2) 63888 (MSS x 44) bandwidth * delay product (Note this is not a speed test):
Your RcvWindow limits you to: 232.32 kbps (29.04 KBytes/s) @ 200ms Your RcvWindow limits you to: 92.928 kbps (11.616 KBytes/s) @ 500ms Consider increasing your RWIN value to optimize TCP/IP for broadband. MTU Discovery (RFC1191) = ON Time to live left = 52 hops
TTL value is ok. Timestamps (RFC1323) = OFF Selective Acknowledgements (RFC2018) = ON IP type of service field (RFC1349) = 00000000
According to http://www.mynetwatchman.com/kb/adsl/pppoemtu.htm , the optimal MTU for PPPoE connections is 1454. Anything above that adds an extra ATM cell with padding bytes for each frame you send and receive.
I'm not sure what to make of the 5808-byte receive window. What are the contents of /proc/sys/net/core/[rw]mem*? How does the speed test at dslreports.com compare?
Bennett, Joe wrote:
Was playing around on speedguide.net and ran their analysis tool for MTU RWN etc. My WinXP box showed exactly what I expected in the report. My Suse 9.0 box showed the report below. Any ides on the RWIN of 5808? Ran two different browers with no change and followed there recommendation here: http://www.speedguide.net/read_articles.php?id=121 on adding these commands into boot.local. No dice...
I'm a bit skeptical since my speed tests with SBC show the bandwidth of my DSL connection. I would have figured that 5808 would create so many acks that speed would be sacrificed...????
Ideas??
TCP options string = 020405ac0101040201030300 MTU = 1492 MTU is optimized for PPoE DSL broadband. If not, consider raising MTU to 1500 for optimal throughput. MSS = 1452 MSS is optimized for PPPoE DSL broadband. If not, consider raising MTU to 1500 for maximum throughput. Default Receive Window (RWIN) = 5808 RWIN Scaling (RFC1323) = 0 bits Unscaled Receive Window = 5808
RWIN is a multiple of MSS Other values for RWIN that might work well with your current MTU/MSS: 511104 (MSS x 44 * scale factor of 8) 255552 (MSS x 44 * scale factor of 4) 127776 (MSS x 44 * scale factor of 2) 63888 (MSS x 44) bandwidth * delay product (Note this is not a speed test):
Your RcvWindow limits you to: 232.32 kbps (29.04 KBytes/s) @ 200ms Your RcvWindow limits you to: 92.928 kbps (11.616 KBytes/s) @ 500ms Consider increasing your RWIN value to optimize TCP/IP for broadband. MTU Discovery (RFC1191) = ON Time to live left = 52 hops
TTL value is ok. Timestamps (RFC1323) = OFF Selective Acknowledgements (RFC2018) = ON IP type of service field (RFC1349) = 00000000 _______________________________________________ Kclug mailing list Kclug@kclug.org http://kclug.org/mailman/listinfo/kclug
Gerald Combs wrote:
According to http://www.mynetwatchman.com/kb/adsl/pppoemtu.htm , the optimal MTU for PPPoE connections is 1454. Anything above that adds an extra ATM cell with padding bytes for each frame you send and receive.
I'm not sure what to make of the 5808-byte receive window. What are the contents of /proc/sys/net/core/[rw]mem*? How does the speed test at dslreports.com compare?
BTW, the window size isn't static -- the OS should increase and decrease it as needed. To see this in action, run
tethereal -z proto,colinfo,tcp.window_size,tcp.window_size port 80
while you're browsing the web.
Quoting Jonathan Hutchins hutchins@tarcanfel.org:
If you've seen the first round of trials, you'll know it's not as easy as it looks.
Jonathan, have you changed any settings on you email client today? I'm getting duplicate messages from you and your single quotes are being escaped with a slash as in the above message.
-- Dave Hull http://insipid.com
--- Jonathan Hutchins wrote:
On Fri, February 4, 2005 4:04 pm, Jeffrey Martin said:
DARPA will give you a million dollars if you can
create a self guided
land vehicle. There must be some elegant solution. -Jeff M.
If you've seen the first round of trials, you'll know it's not as easy as it looks.
I saw the first round of trials. It was pitiful. Hmmm... DARPA offering $1,000,000 for a successful self-guided car? Hmmm... cost of building a self-guided car? Old model fullsized chevy: $3,000 AMD 64 PC x 16 : $80,000 1 GB RAM x 32 : $8,000 1 TB Flash Memory : $20,000 GPS + spare : $800 video capture x4 : $1,000 radar : $1,000 tracking laser x5 : $25,000 1000 man-days of coding : $2,000,000 ---------- total cost $2,138,800
less DARPA award $1,000,000 ----------
net return ($1,138,800)
Sounds like a winner to me. ;')
Understand I consider this to be a minimum effort. We could drop the second GPs but that would only save us a few bucks and we'd have no failover should the primary fail and without a gps, and since the GPS would be the map source it'd make navigation very tough. Of course we could forego the GPS for mapping, but would need to add an altimieter and would need to program in a very accurate starting reference point. I could e off on the cost of the GPS, since we'd want the most accurate model we could get. It would be needed only for a starting point reference if the software was well written. The software to drive such a thing would require a combined software model utilizing a smart system with a very large database (1 TB may not be big enough), an AI algorithm capable of fast tree decision making (such as utilized by Google), possibly a nueral net for learning, recognition software (to detect moving and staionary objects, read signs and road markings), some fuzzy logic as part of the decision tree perhaps, and a controlling central unit to accept inputs from each system and co-ordinate commands. Of course you'd need to add mundane things like crash avoidance, lane changing, turning. All part of the knowledge base based on system inputs. Piece of cake. I could do this in six months with a team of 10 coders. Also, I'm using very cheap labor, probably Rusisans.
Brian Densmore
__________________________________ Do you Yahoo!? Yahoo! Mail - Find what you need with new enhanced search. http://info.mail.yahoo.com/mail_250
I realize you are kidding, but I spent thousands of hours in the early nineties thinking about automating driving in cities. My conclusions were:
* it would easier to start with night driving since there are more obvious indicators and less visual noise, then generalize to daytime.
* collision avoidance would be better done with sonar, as there is meaningful doppler information available in addition to distance.
* Curb mapping would be handled with sonar too, but visuals are needed for identifying the lines in the road.
a far cry from the intelligent skateboards in Snow Crash, but essentially dealing with the same problem domain.
IIRC there were successful demonstrations of intelligent cruise controls that kept a distance from the car ahead rather than simply tracking speed, and very intelligent cruise controls that could entirely take over normal highway driving.
Exceptional situations, such as what to do when a piano falls off a flatbed in front of you, are of course unpredictable and will prevent commercialization of the VICC: The potential liabilities are infinite.
I understood the DOD test to be across some rough desert rather than on roads, so the biggest problem is smart obstacle avoidance. Sort of like the science fair robot mazes, scaled up, and not on a smooth floor. Can't have your robot falling off a cliff, unless of course it's built to take falling off a cliff -- like those huge self-propelled beach balls they were talking about deploying on mars.
On Sun, 6 Feb 2005 19:37:28 -0800 (PST), Jack quiet_celt@yahoo.com wrote:
Of course you'd need to add mundane things like crash avoidance, lane changing, turning. All part of the knowledge base based on system inputs. Piece of cake. I could do this in six months with a team of 10 coders. Also, I'm using very cheap labor, probably Rusisans.
Brian Densmore
-
Bennett, Joe -
Dave Hull -
David Nicol -
Gerald Combs -
Jack -
James Sissel -
Jeffrey Martin -
Jonathan Hutchins