http://octave.org/ i suggest you get the cvs version. most matlab scripts will just work, unless they're mex files (in which case you're s.o.l.). that makes a lot of the packages you mentioned at least possible.
as for the meat of your question, i suggest you try to write one of the pieces of software you mentioned --- the exact reasons for why they're hard to find in general will become apparent pretty quickly.
i don't believe that your chosen major is sufficiently broad to be useful. i also believe that, unless you intend to immediately pursue a graduate degree, you're likely to find it very hard to explain to potential employers what, exactly, it is that your degree says you can do. i don't know that anyone can develop the degree of maturity in the fairly wide set of disciplines that you'll have to master (general comp. sci., intro a.i., "soft" a.i., statistics, linguistics, and quite possibly some signal processing) to really succeed at this major as an undergrad. i suggest instead that you do a major in comp. sci. (or e.e., or linguistics) with a concentration in computational linguistics and then pursue further study at the graduate level.
medical imagery typically requires highly specialized equipment (like the hdr displays they were yapping about in another article). to give the offeror of your second opinion a reasonable hope, you'd have to scan in at least 16bit and quite possibly 24bit gray scale at sufficient resolution to get a 16k x 16k image (these are the magic numbers i remember from my image processing class. i am not a medical professional, nor do i play one on tv. take my advice with a suitably large grain/pile/mine of salt. by reading this post, you agree not to sue me, etc.) do *not* compress the images or in any way dick around with them (contrast stretch, etc. --- just say no).
i seriously doubt that your scanner will be able to get sufficiently high quality to get a meaningful diagnosis. find the person you want the second opinion from, tell him/her about the existing imagery, let them deal with the paper work.
i suppose i should actually answer the question;-)
most of my parallel programming has been on commodity pc hardware (intel). as a result, i've used a combination of pthreads, compiler auto-vectorization (god bless intel's compiler), and mpi. for the more real time stuff i do now, i use nist's nml as the message layer rather than mpi (i have no idea how they'd compare in terms of performance). almost all my code is in c++ (the ocassional piece being in c).
honestly, if you've got the option of using multiple parallel paradigms in the same program, go for it -- mpi for interproc communications, openmp and compiler autovectorization to max out performance on smp nodes.
uniform access shared memory (think the bigass (tm) cray machines) -- here you'd typically use mpi (if your programs are supposed to be portable) or the local threading library + vectorized / paralellized math libraries. since its all in a single memory space, it's "as simple" as just doing a good job multithreading the program.
non-uniform access shared memory (think the large modern sgi machines) -- here things get a bit more subtle, because you're going to start caring about memory access and intranode communications. you can still get a reasonable measure of performance by just using threads, however, if your problem is "embarrassingly parallel enough".
distributed memory (beowulf clusters and their ilk, although a bunch of regular linux or windows boxes will do) -- this is where things get excessively complicated very quickly. you have your choice of several toolkits (mpi being standard in the scientific world and superceding the previous pvm standard). here you are going to care a lot about communications patterns (in fact, probably more so than computation). i believe one of the java technologies (javaspaces perhaps? jini maybe?) abstracts this away and gives you the view of the network as a sea of computational power. regardless, you're going to have to pay very careful attention to how data moves because that will typically be your bottleneck. synchronization becomes whole orders of magnitude more expensive on this kind of parallel machine, which is another thing you'll have to figure into your algorithm design.
once your architecture is fixed, you can start to talk about which toolkit to use. a well tuned mpi will work "equally well" in each of these environments and have the added bonus of being portable across architectures. mpich is a well respected implementation, although i found lam to be much easier to use, personally. good luck, i think you're about to open a can of worms only to discover that you've really just opened a can of ill tempered and rather hungry wyrms.
while it's rather alarming to see that the "best and brightest" can be a bunch of cheating bastards, it's good to see that the necessary controls are in place to find them out. unfortunately, i don't think this would ever work in my field (computer vision) because people tend to be very selective about the results they publish (i.e. they won't often show you what happens when things go wrong), choose poor test sequences (or fail to explicitly state the simplifying assumptions that made their choice of test sequence appropriate), and so on. if someone were to use sufficiently intimidating / esoteric math (especially if it were reasonably plausible math), they could probably fake a paper in some of the top journals and get away with it for several years.
...can probably solve this problem for you. whether or not they can do so on the sort of budget you're willing to spend is a totally different story, however....
... "minor glitches". the sorts that cost banks millions in dollars as fractional pennies are gobbled up or cause machines designed to treat cancer with radiotherapy burn and kill patients. if i were a resident of michgan, i'd demand an inquiry and follow it up with at least one big law suit. this should have been discovered and fixed during testing, not deployment.
first, the video ipod will sell well, regardless of whether or not people are using the video capabilities. it is first and foremost an ipod, and for that fact alone you can expect the same sorts of sales that the ipod has seen thus far (assuming that market forces, etc. don't change significantly in the short term).
second, i think the article severely underestimate the market for music video downloads. the margins on the music videos are insane (even more so than on the music itself)
third, this is the next logical step in apple owning media computing. even if this is initially a loss leader, i expect that the payoff in terms of driving the market will more than make up for it.
correct on both accounts. this was a homework question back when i was taking a class on proofs. i didn't get it until the prof underscored the importance of the communication or lack thereof.
you have five hats (two red, three black) and three people. you queue the people up in order of height and have them face the same way (this way the tallest person can see the two people in front of him/her, the middle person can see the shortest person, and the shortest person can't see anyone). you put a hat on each person's head and instruct them that they are not allowed to take the hat off or turn around. you then ask them to tell you what color their hat is. after a while, the person at the front of the line correctly announces the color of his/her hat. how did the person at the front of the line know and what were the other hat colors?
i really hope the judge finds in favor of the plaintiff.
can you imagine the class action law suit that this could lead to? and not just for spyware, but spam and abusive cookies too... oh what a beautiful thing it will be should it ever happen.
you have no idea how much i wish i had non-suck options for large files being shared between windows and linux. i would *love* to see native support for reiserfs or ext3 (in fact, why not xfs, jfs, and ext2 too) --- this would make my life a lot easier. i do a lot of work with video, typically raw dv streams. while kino does have its strengths, playing nice with the camera i use is not one of them. so i'm forced to use windows to capture the raw dv streams and then work with them under linux (not a big deal — lets me run off and get lunch while my machine is working for me, so i don't mind too much). the problem is then sharing the large dv avi files between linux and windows. can't put 'em on a vfat/fat32 partition because they break the 4gb file size limit. keeping them on ntfs gets to be painful because i need to be able to move equally large video files the other way as well. so i'm forced into my current "solution", which involves using 3rd party apps to allow access to the ext3 partition on my external drive. i would love, more than anything, to have a single large ext3 partition on that drive which can be mounted and used transparently from windows and linux. too bad it's not happening anytime soon.
it depends on how you allocate your arrays. if everything is statically allocated with sizes known at compile time, you are correct. the dynamic case, however, is a very different story.
i saw that episode (as did the folks who did that project, if you read the article). the mythbusters folks didn't really build a parabolic mirror so much as a poor approximation thereof and they didn't really do a good job of focussing it, so it makes sense that they had problems making it work.
... my experience has been that this matters more in the multidimensional array case than in the single dimensional array case (for those who are curious: my goal is to write algorithms which do non-trivial amounts of processing on VGA or larger video at full frame rates [>= 15Hz], any time i can make array operations faster my entire program benefits significantly). when dealing with two dimensional arrays, you can either do the addressing yourself (location [i,j] in a r x c matrix maps to [i*c+j] in a flat array). if you are clever about how you explain your indexing to the compiler, it should realize that you're passing through consecutive addresses in memory and generate code accordingly. if, on the other hand, you're doing something like A[i][j], the compiler has to generate two deref ops plus pay the cost of whatever cache misses result from using the two levels of indirection --- in this case, working with pointer / index arithmetic relative to the base address is a big win.
have you tried this with intel's c/c++ compiler or other compilers? i'd be curious to see if what you're seeing is a result of how gcc is limited in the number of optimizations it can apply directly to the parse tree because it can't assume (at that stage) a particular target machine.
unless you're including the cost of installation and configuration in the sci stuff, i believe your numbers are pretty far off. i was looking at dolphin sci cards which could do roughly 8-10gb and remote dma. the prices i was discussing were on the order of $1-1.5k / device (dual ported cards, depending on volume) and about $5k for an 8 port switch (cables will add a pretty significant amount to these totals). (check their pricelist at http://www.dolphinics.com/pdf/pricing/Price%20List %2020050701.pdf). the dolphin guys were pretty pleasant to deal with. i would have loved to have used their solution, but power requirements made that essentially impossible (high bandwidth, low latency, and low power communications solutions don't really exist, which is a pity.)
if you have access to (ir)rational rose, runing your code through that will probably speed up a lot of this process. otherwise, a combination of cccc and doxygen with the appropriate config files will give you about the best start you can hope for. hopefully, the code has reasonable documentation. if not, you're basically screwed --- you'll have to work out the use cases and reconstruct your software from there.
their vehicle was equipped with two novatel gpses and setup to do differential gps. they had at least two sicks mounted on top of their vehicle mounted so that the lasers were scanning vertically. the scanners pivoted on their mounts. they may have had an additional sick scanning horizontally (i don't recall).
they were running a mix of mac minis, a power book, and some linux boxes.
("my" team was right next to them, so we got to have a chat with them).
all in all, i'm very impressed by what they accomplished. their practice runs were in a walmart parking lot at 2am (i guess they did a good job of obstacle avoidance by necessity!).
make friends with someone who has authority, then present the business case: x, y, and z are hurting your group's efficiency and are costing $$$ in lost productivity and morale. suggest at least one (preferrably two to three) courses of action which can lead to a positive outcome for as many people as possible. said person might champion your cause (probably taking all the kudos, but your problem is solved at least), or they might do nothing. or they might do something in between — it's a hard call. my point is you don't deal with the burocrats, you deal with their keepers. this will need to be done delicately mind you, burocrats despise nothing more than the impression that their power is being usurped.
i can appreciate why rms et al are doing things the way they are, but it makes me kinda leary. if i used f/oss package $x as the basis for a web service and then made modifications to it to suite my business (custom tie-ins to my inventory system, etc.), i'm not certain that i would want to be forced to release that information to the world. which means that in order to keep that stuff private, i am forced to perform some very careful surgery to build an interface to proprietary code which is designed to interoperate with the original gpl stuff but is a seperate module under a seperate license. so all the gpl would accomplish is releasing to the world the hooks and interfaces i put into place to interface with my code. not terribly useful, imho. in the mean time, people who don't want to give away even that much information switch over to closed source stuff. which kinda defeats the purpose...
but then again, i'm probably way oversimplifying things. it's late and i'm sleepy.
my company is sponsoring a team and happened to book some extra hotel rooms, so i'm going off to watch the race (instead of gambling away my soul in vegas). bunch of other guys are going from work as well -- should be a blast.
I wouldn't say that this is an amazing failure of AI so much as an amazing failure to realistically estimate the real difficulty of AI and the mess of systems integration problems that accompany robotics (I happen to work for a company that's part of a GC team and specializes in autonomous robotics). Firstly, sensors suck. We are just now barely approaching video sensors that have the same resolution as the human eye, but at 9+megapixels a piece, you have an insane amount of numbercrunching to do before you've reduced a frame into useful information. Now repeat that at 60Hz and you now have an appreciation for where a large portion of the computing power is used. Now take three such cameras for multi-baseline stereo and terrain classification and you're talking 1.6 gigapixels per second that you have to process. You also have to find machines which can sustain 3.2GB/s or 4.8GB/s transfer rates (depending on whether you use YUV 4:2:2 or RGB 8 bit per channel imagery). Now toss in a couple LADARs scanning at 100Hz, 360 x 16 bit samples per scan line, a bunch of RADARs operating at 30Hz, an IMU, two GPS units (one for the IMU, one for you to use)... you begin to see some of the problems. You need all those different sensing modalities because the fundamental truth of sensors is that they lie. You can do things to get reasonable estimates up to some confidence, but realistically what you're seeing are random values near the real values. Sensors fail, so you need back-up systems, and some way of determining which sensors failed (or rather, a way to change your beliefs about which sensors are reliable).
In short, the classical AI part (most folks seem to use D* + reactive controls) is not where 90+% of the processing bandwidth is used, you need that power for sensing and for guaranteeing that your control loops cycle at at least some minimum frequency to guarantee safe operations.
That said, there's a lot the gov't can do to make this problem a lot easier to solve. Standard bus designs (like FireWire) which can power most of the sensors on the bus are a really great start. Open protocols from the wire up are also important. A push towards integrating more intelligence in the sensors (embedded FPGAs which allow you to do optional processing on the raw signals coming in) can help quite a bit. Research into high-speed busses that allow you to pretend you have a shared memory multiproc will also help a lot. Finding a way to reliably and efficiently move processing algorithms into FPGAs or microcontrollers will also help to distribute the workload and reduce overall bandwidth and processing requirements. Unfortunately, there's still a lot of fundamental algorithm work to be done before you get to that point, but as certain algorithms becomes standardized this will become a lot more feasible.
Slashdot Mirror
http://octave.org/ i suggest you get the cvs version. most matlab scripts will just work, unless they're mex files (in which case you're s.o.l.). that makes a lot of the packages you mentioned at least possible.
as for the meat of your question, i suggest you try to write one of the pieces of software you mentioned --- the exact reasons for why they're hard to find in general will become apparent pretty quickly.
i don't believe that your chosen major is sufficiently broad to be useful. i also believe that, unless you intend to immediately pursue a graduate degree, you're likely to find it very hard to explain to potential employers what, exactly, it is that your degree says you can do. i don't know that anyone can develop the degree of maturity in the fairly wide set of disciplines that you'll have to master (general comp. sci., intro a.i., "soft" a.i., statistics, linguistics, and quite possibly some signal processing) to really succeed at this major as an undergrad. i suggest instead that you do a major in comp. sci. (or e.e., or linguistics) with a concentration in computational linguistics and then pursue further study at the graduate level.
medical imagery typically requires highly specialized equipment (like the hdr displays they were yapping about in another article). to give the offeror of your second opinion a reasonable hope, you'd have to scan in at least 16bit and quite possibly 24bit gray scale at sufficient resolution to get a 16k x 16k image (these are the magic numbers i remember from my image processing class. i am not a medical professional, nor do i play one on tv. take my advice with a suitably large grain/pile/mine of salt. by reading this post, you agree not to sue me, etc.) do *not* compress the images or in any way dick around with them (contrast stretch, etc. --- just say no).
i seriously doubt that your scanner will be able to get sufficiently high quality to get a meaningful diagnosis. find the person you want the second opinion from, tell him/her about the existing imagery, let them deal with the paper work.
i suppose i should actually answer the question ;-)
:-)
most of my parallel programming has been on commodity pc hardware (intel). as a result, i've used a combination of pthreads, compiler auto-vectorization (god bless intel's compiler), and mpi. for the more real time stuff i do now, i use nist's nml as the message layer rather than mpi (i have no idea how they'd compare in terms of performance). almost all my code is in c++ (the ocassional piece being in c).
honestly, if you've got the option of using multiple parallel paradigms in the same program, go for it -- mpi for interproc communications, openmp and compiler autovectorization to max out performance on smp nodes.
good luck
in order of easiest to hardest to program:
uniform access shared memory (think the bigass (tm) cray machines) -- here you'd typically use mpi (if your programs are supposed to be portable) or the local threading library + vectorized / paralellized math libraries. since its all in a single memory space, it's "as simple" as just doing a good job multithreading the program.
non-uniform access shared memory (think the large modern sgi machines) -- here things get a bit more subtle, because you're going to start caring about memory access and intranode communications. you can still get a reasonable measure of performance by just using threads, however, if your problem is "embarrassingly parallel enough".
distributed memory (beowulf clusters and their ilk, although a bunch of regular linux or windows boxes will do) -- this is where things get excessively complicated very quickly. you have your choice of several toolkits (mpi being standard in the scientific world and superceding the previous pvm standard). here you are going to care a lot about communications patterns (in fact, probably more so than computation). i believe one of the java technologies (javaspaces perhaps? jini maybe?) abstracts this away and gives you the view of the network as a sea of computational power. regardless, you're going to have to pay very careful attention to how data moves because that will typically be your bottleneck. synchronization becomes whole orders of magnitude more expensive on this kind of parallel machine, which is another thing you'll have to figure into your algorithm design.
once your architecture is fixed, you can start to talk about which toolkit to use. a well tuned mpi will work "equally well" in each of these environments and have the added bonus of being portable across architectures. mpich is a well respected implementation, although i found lam to be much easier to use, personally. good luck, i think you're about to open a can of worms only to discover that you've really just opened a can of ill tempered and rather hungry wyrms.
while it's rather alarming to see that the "best and brightest" can be a bunch of cheating bastards, it's good to see that the necessary controls are in place to find them out. unfortunately, i don't think this would ever work in my field (computer vision) because people tend to be very selective about the results they publish (i.e. they won't often show you what happens when things go wrong), choose poor test sequences (or fail to explicitly state the simplifying assumptions that made their choice of test sequence appropriate), and so on. if someone were to use sufficiently intimidating / esoteric math (especially if it were reasonably plausible math), they could probably fake a paper in some of the top journals and get away with it for several years.
1) open mouth ...
2) insert shotgun
$$$ profit! $$$
with "protecting" children as lesbian porn has to do with lesbians. not that i've ever, you know, had personal experience with this.
...can probably solve this problem for you. whether or not they can do so on the sort of budget you're willing to spend is a totally different story, however....
... "minor glitches". the sorts that cost banks millions in dollars as fractional pennies are gobbled up or cause machines designed to treat cancer with radiotherapy burn and kill patients. if i were a resident of michgan, i'd demand an inquiry and follow it up with at least one big law suit. this should have been discovered and fixed during testing, not deployment.
a couple of things:
first, the video ipod will sell well, regardless of whether or not people are using the video capabilities. it is first and foremost an ipod, and for that fact alone you can expect the same sorts of sales that the ipod has seen thus far (assuming that market forces, etc. don't change significantly in the short term).
second, i think the article severely underestimate the market for music video downloads. the margins on the music videos are insane (even more so than on the music itself)
third, this is the next logical step in apple owning media computing. even if this is initially a loss leader, i expect that the payoff in terms of driving the market will more than make up for it.
correct on both accounts. this was a homework question back when i was taking a class on proofs. i didn't get it until the prof underscored the importance of the communication or lack thereof.
let's see... the problem goes roughly like this:
you have five hats (two red, three black) and three people. you queue the people up in order of height and have them face the same way (this way the tallest person can see the two people in front of him/her, the middle person can see the shortest person, and the shortest person can't see anyone). you put a hat on each person's head and instruct them that they are not allowed to take the hat off or turn around. you then ask them to tell you what color their hat is. after a while, the person at the front of the line correctly announces the color of his/her hat. how did the person at the front of the line know and what were the other hat colors?
i really hope the judge finds in favor of the plaintiff.
can you imagine the class action law suit that this could lead to? and not just for spyware, but spam and abusive cookies too... oh what a beautiful thing it will be should it ever happen.
you have no idea how much i wish i had non-suck options for large files being shared between windows and linux. i would *love* to see native support for reiserfs or ext3 (in fact, why not xfs, jfs, and ext2 too) --- this would make my life a lot easier. i do a lot of work with video, typically raw dv streams. while kino does have its strengths, playing nice with the camera i use is not one of them. so i'm forced to use windows to capture the raw dv streams and then work with them under linux (not a big deal — lets me run off and get lunch while my machine is working for me, so i don't mind too much). the problem is then sharing the large dv avi files between linux and windows. can't put 'em on a vfat/fat32 partition because they break the 4gb file size limit. keeping them on ntfs gets to be painful because i need to be able to move equally large video files the other way as well. so i'm forced into my current "solution", which involves using 3rd party apps to allow access to the ext3 partition on my external drive. i would love, more than anything, to have a single large ext3 partition on that drive which can be mounted and used transparently from windows and linux. too bad it's not happening anytime soon.
it depends on how you allocate your arrays. if everything is statically allocated with sizes known at compile time, you are correct. the dynamic case, however, is a very different story.
i saw that episode (as did the folks who did that project, if you read the article). the mythbusters folks didn't really build a parabolic mirror so much as a poor approximation thereof and they didn't really do a good job of focussing it, so it makes sense that they had problems making it work.
... my experience has been that this matters more in the multidimensional array case than in the single dimensional array case (for those who are curious: my goal is to write algorithms which do non-trivial amounts of processing on VGA or larger video at full frame rates [>= 15Hz], any time i can make array operations faster my entire program benefits significantly). when dealing with two dimensional arrays, you can either do the addressing yourself (location [i,j] in a r x c matrix maps to [i*c+j] in a flat array). if you are clever about how you explain your indexing to the compiler, it should realize that you're passing through consecutive addresses in memory and generate code accordingly. if, on the other hand, you're doing something like A[i][j], the compiler has to generate two deref ops plus pay the cost of whatever cache misses result from using the two levels of indirection --- in this case, working with pointer / index arithmetic relative to the base address is a big win.
have you tried this with intel's c/c++ compiler or other compilers? i'd be curious to see if what you're seeing is a result of how gcc is limited in the number of optimizations it can apply directly to the parse tree because it can't assume (at that stage) a particular target machine.
unless you're including the cost of installation and configuration in the sci stuff, i believe your numbers are pretty far off. i was looking at dolphin sci cards which could do roughly 8-10gb and remote dma. the prices i was discussing were on the order of $1-1.5k / device (dual ported cards, depending on volume) and about $5k for an 8 port switch (cables will add a pretty significant amount to these totals). (check their pricelist at http://www.dolphinics.com/pdf/pricing/Price%20List %2020050701.pdf). the dolphin guys were pretty pleasant to deal with. i would have loved to have used their solution, but power requirements made that essentially impossible (high bandwidth, low latency, and low power communications solutions don't really exist, which is a pity.)
let's see:
if you have access to (ir)rational rose, runing your code through that will probably speed up a lot of this process. otherwise, a combination of cccc and doxygen with the appropriate config files will give you about the best start you can hope for. hopefully, the code has reasonable documentation. if not, you're basically screwed --- you'll have to work out the use cases and reconstruct your software from there.
their vehicle was equipped with two novatel gpses and setup to do differential gps. they had at least two sicks mounted on top of their vehicle mounted so that the lasers were scanning vertically. the scanners pivoted on their mounts. they may have had an additional sick scanning horizontally (i don't recall).
they were running a mix of mac minis, a power book, and some linux boxes.
("my" team was right next to them, so we got to have a chat with them).
all in all, i'm very impressed by what they accomplished. their practice runs were in a walmart parking lot at 2am (i guess they did a good job of obstacle avoidance by necessity!).
make friends with someone who has authority, then present the business case: x, y, and z are hurting your group's efficiency and are costing $$$ in lost productivity and morale. suggest at least one (preferrably two to three) courses of action which can lead to a positive outcome for as many people as possible. said person might champion your cause (probably taking all the kudos, but your problem is solved at least), or they might do nothing. or they might do something in between — it's a hard call. my point is you don't deal with the burocrats, you deal with their keepers. this will need to be done delicately mind you, burocrats despise nothing more than the impression that their power is being usurped.
i can appreciate why rms et al are doing things the way they are, but it makes me kinda leary. if i used f/oss package $x as the basis for a web service and then made modifications to it to suite my business (custom tie-ins to my inventory system, etc.), i'm not certain that i would want to be forced to release that information to the world. which means that in order to keep that stuff private, i am forced to perform some very careful surgery to build an interface to proprietary code which is designed to interoperate with the original gpl stuff but is a seperate module under a seperate license. so all the gpl would accomplish is releasing to the world the hooks and interfaces i put into place to interface with my code. not terribly useful, imho. in the mean time, people who don't want to give away even that much information switch over to closed source stuff. which kinda defeats the purpose...
but then again, i'm probably way oversimplifying things. it's late and i'm sleepy.
my company is sponsoring a team and happened to book some extra hotel rooms, so i'm going off to watch the race (instead of gambling away my soul in vegas). bunch of other guys are going from work as well -- should be a blast.
I wouldn't say that this is an amazing failure of AI so much as an amazing failure to realistically estimate the real difficulty of AI and the mess of systems integration problems that accompany robotics (I happen to work for a company that's part of a GC team and specializes in autonomous robotics). Firstly, sensors suck. We are just now barely approaching video sensors that have the same resolution as the human eye, but at 9+megapixels a piece, you have an insane amount of numbercrunching to do before you've reduced a frame into useful information. Now repeat that at 60Hz and you now have an appreciation for where a large portion of the computing power is used. Now take three such cameras for multi-baseline stereo and terrain classification and you're talking 1.6 gigapixels per second that you have to process. You also have to find machines which can sustain 3.2GB/s or 4.8GB/s transfer rates (depending on whether you use YUV 4:2:2 or RGB 8 bit per channel imagery). Now toss in a couple LADARs scanning at 100Hz, 360 x 16 bit samples per scan line, a bunch of RADARs operating at 30Hz, an IMU, two GPS units (one for the IMU, one for you to use)... you begin to see some of the problems. You need all those different sensing modalities because the fundamental truth of sensors is that they lie. You can do things to get reasonable estimates up to some confidence, but realistically what you're seeing are random values near the real values. Sensors fail, so you need back-up systems, and some way of determining which sensors failed (or rather, a way to change your beliefs about which sensors are reliable).
In short, the classical AI part (most folks seem to use D* + reactive controls) is not where 90+% of the processing bandwidth is used, you need that power for sensing and for guaranteeing that your control loops cycle at at least some minimum frequency to guarantee safe operations.
That said, there's a lot the gov't can do to make this problem a lot easier to solve. Standard bus designs (like FireWire) which can power most of the sensors on the bus are a really great start. Open protocols from the wire up are also important. A push towards integrating more intelligence in the sensors (embedded FPGAs which allow you to do optional processing on the raw signals coming in) can help quite a bit. Research into high-speed busses that allow you to pretend you have a shared memory multiproc will also help a lot. Finding a way to reliably and efficiently move processing algorithms into FPGAs or microcontrollers will also help to distribute the workload and reduce overall bandwidth and processing requirements. Unfortunately, there's still a lot of fundamental algorithm work to be done before you get to that point, but as certain algorithms becomes standardized this will become a lot more feasible.