There are a couple of fundamental problems. 1. Chemical rockets are expensive and have low energy density. 2. Humans in space require ridiculous levels of life-support that steal much of what precious little energy we are able to cram into a chemical rocket.
Lets not have a repeat of the automobile engine. Lets move on to a new engine. The vast amounts of money being used to prevent astronauts from dieing in space could fund a whole lot of propulsion R&D that might well result in a drive system that would be safer and actually make human space flight practical from a both an economic and a safety perspective.
In the meantime, robots in space are cheaper and can go further than any human. No human could take the radiation exposure implied by a trip to Europa or Enceladus for example.
I can't clain to have built the bot either, but I can vouch for author. If there are errors you could get help directly from the author or from any number of robot club mailing lists.
And more. The clubs often have links to one another, check around for one in your area and you could possibly get in person help if you have a problem.
That's really the key here that I think Bartle missed.
Respawning monsters/areas and instanced areas are both bad solution to what is a instrinsically difficult problem: Players consume content far, far, far faster than developers can possibly create it.
Just to add a bit to what my competitors have said that is not always obvious to those outside the control business is that anything under control of our systems can be subjected to an automatic schedule. The lights could turn on and off based 7 day time schedule with exception days and holiday days that are indicated on a calender for example.
And/Or as a security guard is patroling at night, as he keys into each section of the building the system could turn on just the lights in that section for 30 minutes or whatever.
Jobs where we link together systems like Fire, Security, and HVAC control are always a favorite.
You are probably thinking of the older PMI/NCM350 based software. The newer stuff is.NET, Java, and SOAP based with SVG for graphics. Each supervisory controller is a web server.
The usual way to do this is called ice storage. Rather than store cool air in a leaky room space they have special chiller that makes ice in an insualted container during off-peak. Then later, when the peak demand time occurs, they pass the water for the AC units'c cooling coil thru the ice rather than the electric chiller.
Most are not savy enough to give real time prices. Often you get a schedule of times of day duing a given season when demand charges (which are over and above total consumption charges) are in effect. Like durring summer between 11AM and 8PM demand changes will be in effect. That means that during that time you want to minimize your pull from the network.
Keep in mind though that big sites can pay consumption charges that are like US$0.02/kWH.
This stuff is a lot older than the article implies. If you want to see a networked building control system that uses XML drop by Johnson Controls Metasys. It does everything the article talks about and way more besides. The XML apspect of the system is only about a year and a half old but the networked demand limiting/load rolling apsects are 10+ years old.
Demand limiting is big bucks. It is common to have a contract with a power company that says that during peak times you will not exceed a given kWH in a 15 or 30 min interval. Often the penalty for doing so is severe, such as a upward change in rate structure for the rest of the contract.
Even less harsh contracts usually involve a peak kW demand charge that is in addition to the normal kWH charge.
Running the AC at half power all the time is often not realistic. Big ACs have control systems that automatically change their output level according to demand anyway. The functionaly described here is actually nothing at all new to those control systems. Just the XML part is new and even that is over a year old for my company.
Take a look at Johnson Controls, Siemens, Automatated Logic, and Honeywell. All of us have controls systems that do in fact talk between buildings using TCP/IP if not XML in particular. (Bacnet is the big standard protocol in our world actually.) All of us have control systems that does everything that article talks about and much, much more.
I disagree. Indirect measurement is no way to run a system. The kind of people you find willing to be an operator, wheter a nuke plant or an refrigeration plant are not going to be able to deduce the state of a system by analysising indirect variables. Engineers can, in the calm of an office, but I doubt they'ed do much better in a crisis.
That valve should have had direct status indication. That pipe should have had direct flow indication. Inferring flow from temperature is just shitty, particularlly in a nuke plant.
Number 5 to me is the real stinker. How fucking cheap do you have to be to not put a valve stem travel end switch on such a critical damn valve?
It occurs to me that if they had simply had that direct valve status indication, rather than just the command, none of this would have happened. For that matter they should have also had a flow meter on the pipe so they could directly measure how much water was leaving the reactor.. instead somebody else has to call them about standing water.
We put end switches on valves that could break a US $5K device if it breaks. If find their lack on a nuke reactor to be total unbeleivable.
Overall the amount of reactor status that they were expected to deduce from indirect measurements was just crazy. You'll never get switch board operator type people who will be able to navigate those kind of intellectual waters in a crisis. I wonder how many nuke physists could navigate those waters knowing that a mistake means their ass.
I'm just a lowly HVAC control guy. I would never trust my company to do nuke control. But, damn, even I could design a better control system than what I read about here.
The web guy just said they might retry. So the damage cant be bad.
Other unoffical updates: Sandstorm is out with a blown motor. Sci II is supposedly still running. Caltech is still running technically but is going nowhere fast. Its not stuck or anything tho. Dad is running. #25 has a stuck brake. #23 has GPS problems but they may restart. Navigator is stuck real bad in a fence. they are cutting it out. #15 lost it hydralic pump Cajunbot hit a obstacle right out of the gate. Ensco hauled ass out of the gate, made its first turn OK but then rolled on the next.
I think they are blocking the other bots, tho. The web guy said there was a course blockage but he did not say what the obstruction was. I'm guessing its Sandstorm.
Neither the flash animation or the status board seem to match what the web guy is saying. I think they are kinda buggy.
If my early morning math is right the wave length of 24Ghz is about half an inch. Does that mean that the chip could distinguish distances as small as half an inch?
That would be really cool for a small robot if it could.
I have to concur with the other posters. Mike Doyle is no one to cheer on. Two wrongs don't make a right. A broken patent system is a major threat to small developers. Big corps routinely cross licence their patent portfolios to one another with prices that a cheap relative to their size but prohibative to upstart companies.
A monolpoly may be difficult to sustain but an oligarchy is most possible with current patent policies. In my opinion this is incrediably dangerous to free software, open source software, and even small proprietary biz.
Mr. Underhill
P.S. I sit next to a guy who is owed 5 months pay by Mike Doyle. He doesn't expect to see one red cent of that $521Megs.
The nice thing about Robot Sumo is that there is a fair number of local competions closely patterned after the original.jp Robot Sumo and one of the robot classes is autonomous.
Slashdot Mirror
There are a couple of fundamental problems.
1. Chemical rockets are expensive and have low energy density.
2. Humans in space require ridiculous levels of life-support that steal much of what precious little energy we are able to cram into a chemical rocket.
Lets not have a repeat of the automobile engine. Lets move on to a new engine. The vast amounts of money being used to prevent astronauts from dieing in space could fund a whole lot of propulsion R&D that might well result in a drive system that would be safer and actually make human space flight practical from a both an economic and a safety perspective.
In the meantime, robots in space are cheaper and can go further than any human. No human could take the radiation exposure implied by a trip to Europa or Enceladus for example.
Did I read that right? Android 1.0 and Android 1.0 devices won't have bluetooth? That seems like kind of a big miss.
The author's website page on homemade PCBs
I can't clain to have built the bot either, but I can vouch for author. If there are errors you could get help directly from the author or from any number of robot club mailing lists.
Chibots
AHRC
DPRG
And more. The clubs often have links to one another, check around for one in your area and you could possibly get in person help if you have a problem.
Intermediate Robot Building. Check it out too.
Also his website: http://www.robotroom.com
He attends the Chicago Robotics Club Chibots. Check it out too.
I read this the same way. The treaty is talking about WMDs. Sat. Jammers, Sat. Killers and missile interceptors don't quailfy.
That's really the key here that I think Bartle missed.
Respawning monsters/areas and instanced areas are both bad solution to what is a instrinsically difficult problem: Players consume content far, far, far faster than developers can possibly create it.
Just to add a bit to what my competitors have said that is not always obvious to those outside the control business is that anything under control of our systems can be subjected to an automatic schedule. The lights could turn on and off based 7 day time schedule with exception days and holiday days that are indicated on a calender for example.
And/Or as a security guard is patroling at night, as he keys into each section of the building the system could turn on just the lights in that section for 30 minutes or whatever.
Jobs where we link together systems like Fire, Security, and HVAC control are always a favorite.
You are probably thinking of the older PMI/NCM350 based software. The newer stuff is .NET, Java, and SOAP based with SVG for graphics. Each supervisory controller is a web server.
JCI is right in the thick of web standards.
The usual way to do this is called ice storage. Rather than store cool air in a leaky room space they have special chiller that makes ice in an insualted container during off-peak. Then later, when the peak demand time occurs, they pass the water for the AC units'c cooling coil thru the ice rather than the electric chiller.
Most are not savy enough to give real time prices. Often you get a schedule of times of day duing a given season when demand charges (which are over and above total consumption charges) are in effect. Like durring summer between 11AM and 8PM demand changes will be in effect. That means that during that time you want to minimize your pull from the network.
Keep in mind though that big sites can pay consumption charges that are like US$0.02/kWH.
This stuff is a lot older than the article implies. If you want to see a networked building control system that uses XML drop by Johnson Controls Metasys. It does everything the article talks about and way more besides. The XML apspect of the system is only about a year and a half old but the networked demand limiting/load rolling apsects are 10+ years old.
So I can pretty much say the article is XML hype.
Demand limiting is big bucks. It is common to have a contract with a power company that says that during peak times you will not exceed a given kWH in a 15 or 30 min interval. Often the penalty for doing so is severe, such as a upward change in rate structure for the rest of the contract.
Even less harsh contracts usually involve a peak kW demand charge that is in addition to the normal kWH charge.
Running the AC at half power all the time is often not realistic. Big ACs have control systems that automatically change their output level according to demand anyway. The functionaly described here is actually nothing at all new to those control systems. Just the XML part is new and even that is over a year old for my company.
Take a look at Johnson Controls, Siemens, Automatated Logic, and Honeywell. All of us have controls systems that do in fact talk between buildings using TCP/IP if not XML in particular. (Bacnet is the big standard protocol in our world actually.) All of us have control systems that does everything that article talks about and much, much more.
I disagree. Indirect measurement is no way to run a system. The kind of people you find willing to be an operator, wheter a nuke plant or an refrigeration plant are not going to be able to deduce the state of a system by analysising indirect variables. Engineers can, in the calm of an office, but I doubt they'ed do much better in a crisis.
That valve should have had direct status indication. That pipe should have had direct flow indication. Inferring flow from temperature is just shitty, particularlly in a nuke plant.
Number 5 to me is the real stinker. How fucking cheap do you have to be to not put a valve stem travel end switch on such a critical damn valve?
It occurs to me that if they had simply had that direct valve status indication, rather than just the command, none of this would have happened. For that matter they should have also had a flow meter on the pipe so they could directly measure how much water was leaving the reactor.. instead somebody else has to call them about standing water.
We put end switches on valves that could break a US $5K device if it breaks. If find their lack on a nuke reactor to be total unbeleivable.
Overall the amount of reactor status that they were expected to deduce from indirect measurements was just crazy. You'll never get switch board operator type people who will be able to navigate those kind of intellectual waters in a crisis. I wonder how many nuke physists could navigate those waters knowing that a mistake means their ass.
I'm just a lowly HVAC control guy. I would never trust my company to do nuke control. But, damn, even I could design a better control system than what I read about here.
Yea that thing is useless. The status of the vehicle isnt even correct. I can't belive they spent $13M and have such a bad webpage to show for it.
The web guy just said they might retry. So the damage cant be bad.
Other unoffical updates:
Sandstorm is out with a blown motor.
Sci II is supposedly still running.
Caltech is still running technically but is going nowhere fast. Its not stuck or anything tho.
Dad is running.
#25 has a stuck brake.
#23 has GPS problems but they may restart.
Navigator is stuck real bad in a fence. they are cutting it out.
#15 lost it hydralic pump
Cajunbot hit a obstacle right out of the gate.
Ensco hauled ass out of the gate, made its first turn OK but then rolled on the next.
Didn't look like very much. They might have broken a headlight. It real hard to say.
They hit that same spot on the car (right front panel) coming right out of the starting gate. Didn't even make it to the first turn.
Yeah.
I think they are blocking the other bots, tho. The web guy said there was a course blockage but he did not say what the obstruction was. I'm guessing its Sandstorm.
Neither the flash animation or the status board seem to match what the web guy is saying. I think they are kinda buggy.
The guy on the CMU webcast says they had a motor failure.
Well my thought was that since the the chip's clock was 24Ghz the minimum detectable increment would be a half-inch.
If my early morning math is right the wave length of 24Ghz is about half an inch. Does that mean that the chip could distinguish distances as small as half an inch?
That would be really cool for a small robot if it could.
I have to concur with the other posters. Mike Doyle is no one to cheer on. Two wrongs don't make a right. A broken patent system is a major threat to small developers. Big corps routinely cross licence their patent portfolios to one another with prices that a cheap relative to their size but prohibative to upstart companies.
A monolpoly may be difficult to sustain but an oligarchy is most possible with current patent policies. In my opinion this is incrediably dangerous to free software, open source software, and even small proprietary biz.
Mr. Underhill
P.S. I sit next to a guy who is owed 5 months pay by Mike Doyle. He doesn't expect to see one red cent of that $521Megs.
The nice thing about Robot Sumo is that there is a fair number of local competions closely patterned after the original .jp Robot Sumo and one of the robot classes is autonomous.
Northwest Robot Sumo (Contains many links to other Sumo's)
Atlanta Hobby Robot Club Mini Sumo Robot Contest Rules
Central Illinois Robotics Club 2001 Sumo Rules