in some autonomous robotics stuff i've worked on, after task competitions teams would get together and discuss varying approaches to problems.
While no code sharing occured (nor would've been useful, as each platform has its own unique way of doing basic tasks), discussing approaches leads often to combined approaches, fresh perspectives on ideas and then THAT leads to innovation as each time takes what they've learned and applies it to the next project. Eventually the most efficient and "best" system results.
By your logic, nobody should go to a university to learn things and should learn everything on their own to foster 'innovation', while in fact everyone would be reinventing the wheel a billion times over.
The time will certainly help, and the experience will help immensely.
As for improving the world model, they'll be able to add a few more variables to it and tweak others, but it will still be far from complete. There are still going to be issues like running over something at the wrong angle, or taking a curve too sharp and the sand shifts under the tires and it gets swung wildly off course, the system overcorrects and the vehicle flips or gets turned around... problems like that are really frustrating:)
There is an algorithm out there called the Kalman filter which does this. It's very complicated and rooted in probability theory, but it basically takes several sensor inputs, smooths out their response based on previous values (and known noise characteristics, such as the typical standard deviation from the truth) and makes a good assumption about where the sensors will be in the near-future.
It is very accurate, if you tune it properly (thats the tricky part)
This is very important for real time things because you need to begin to smoothly react to situations before they happen (ie, driving into an obstacle at high speeds).
what kept them from practicing in every concveivable situation?
This is impossible to do. There are too many variables in the real world.
The bane of autonomous robotics is the fact you can't create an accurate world model. Sure, you can model the things you think will have the most effect, but there are literally millions of little things which by themselves may not mean much, but over time or in differing combinations can cause havoc and system disruption.
As an example, say for driving over barbed wire. Suppose you hit it at just such an angle the wire gets wrapped around the axle? You can't predict such things.
The post-mortems will be interesting to read. I hope they post them online.
the idea behind these things is to create automated ammo/medic/fuel ferries eventually. It wouldn't do to have a 7-ton vehicle run into a group of wounded soldiers at 40 mph. Or anything else, for that matter.
I work with autonomous robots in a lab setting. It's difficult enough to get a 2 wheeled robot the size of an RC car that moves 75 cm/sec to navigate its environment reliably. Failure is something you simply have to learn to live with and learn from (many computer scientists have a tough time getting used to the idea that these systems cannot nor ever will work 100% of the time). Honestly, you learn way more from failure than success in this business.
To get a full sized vehicle working at battlefield speeds with battlefield obstacles is a monumental challenge and almost certainly guaranteed to fail on the first try. Autonomous robotics is still a very young field, and the research published out there is generally some pretty rudimentary stuff done in a lab. Translating that stuff into a big complicated machine in a big complicated environment is a hell of a task and probably demonstrates some substantial holes in the current tech that weren't apparent from the confines of the lab.
This DARPA challenge does two excellent things for the field: Gives it a real goal and gives it a real deadline. Alot of research doesn't have a deadline and so researchers spend much of their time spinning their wheels (heh) on some of what i would consider, less important issues. This challenge gives a genuine goal to accomplish in a certain amount of time.
I definiately want to see the post-mortem on each team to see where they failed. In 2 more years, with this failure experience gained, perhaps a quarter of the teams will succeed or at least get further down the course.
much of the information an encyclopedia contains does not, in fact, go out of date. Most of it is historical and written by actual experts in the respective field (usually academics and doctors).
So while the part about the current state of the soviet economy might be useless, the part about the founding history of the soviet union would not.
it might just've been the light of the fire on the smoke or cloud bottoms.
A couple of months ago a magnesium recycling plant in ohio (i think) burned up. A town webcam was pointed in its direction, and despite being miles away, the sky looked as bright as day from the white light reflecting off the bottom of the clouds at 2 am. You could definiately say it was glowing.
or, it could actually have been the radiation ionizing the air (is this possible, nuclear physicists?). I seem to remember some descriptions of nuclear blasts causing purple glows in the air from radiation ionizing it.
her description says that children were playing in it before the town was evacuated and it was covered in smoke so thick it could not be seen through.
This smoke would have been highly radioactive. Those children are probably all dead.
I'd never read an account like that, even in the west which didn't gloss over the horrors of chernobyl. If its true, then that disaster was far, far worse than any of us realized.
you might be kidding, but i think of the people back then were clever enough to warrant the old style definition of hacker:)
Computers were designed and built by engineers (directed by theorticians). But they were programmed by the same women who used to run the adding machines! Though usually they were women with a college degree, often in math.
At that time, programming the computer was often seen as 'below' the designers who built the thing and not a particularly manly job. Given this, its little surprise that many of early advancements in programming were done by women. Grace Hopper's development of mnemonics comes to mind and the invention of the compiler.
Though in the western world this attitude has done a complete 180 (men are much more common as programmers), there are still some places in the world where programming is often seen as a more womanly job.
Re:Is it allowed to call itself a "computer"?
on
The Disposable Computer
·
· Score: 3, Insightful
Many "calculators" today run general purpose processors and can be used for general purpose computing. I believe my old 1991 TI-82 has a Z80 in it.
It seems to me this new device has some ideas in mind for it should be used for, but is fairly general purpose. At the moment, its a computer. Though the systems it becomes embedded in might be called something else.
Just like my calculator's processor could be used in a 'computer'. But its embedded use is for arithmetic and algebra, therefore its a 'calculator'
Re:Is it allowed to call itself a "computer"?
on
The Disposable Computer
·
· Score: 4, Interesting
back in the 1940s, a "computer" was a young woman who sat in front of an adding machine punching in numbers. It was actually quite awhile before the electronic machines came to be known as 'computers'. I'm sure many early designers would laugh at the thought of their complicated multi-ton kilowatt consuming monstrosities being named after the job a 19 year old girl did.
What it is called depends on its use. You don't call a PDA a computer do you? Even though it clearly is one.
If this device is in fact used for computing, then it is in fact, a computer.
Mandrake, had it not been for some poor contracts from the past, would currently making a profit.
And I would be the queen of england had I been born in the right place at the right time.
RedHat is making a profit
Are they now, finally? Without accounting trickery? Note that they've dropped consumer support and maintenance as of almost immediately. Even microsoft treats average consumers better in that respect.
IBM, a company that obviously like to make cash of their code, is making money as well while still working on open source.
IBM may use open source in their product lines, but they're certainly not an open source company. Their money is from their other bajillion divisions from really big hardware to enterprise management.
The above poster wants to know how many people make an actual living directly from open source.
Using a suitable video application (streaming server?) it would be possible to look through the webcam and steer around the house
For real autonomous steering you're going to need a couple of cams for stereoscopic vision, plus some badass software to handle it, of your own creation.
stereoscopic navigation is still fairly new, even in the research world..i don't think there are any software packages out there you can go grab to work with. a quick google seems to support this since "stereoscopic robot navigation" returns mostly research papers..
And a sure way to guarantee malfunctioning, piss poor quality code is to come in the middle of the project with little knowledge of the surrounding project.
This is especially true if its a non-trivial piece of software. Several times new programmers have come into software packages I've been working on, don't bother to read the structural documentation or even the useful other code that serves as examples for how to improve and extend upon the existing structure.
Instead they try and do things their own way, often end up doing things redundantly or breaking something else and just otherwise fouling more than they contribute.
The best person to improve upon software is the person who designed in the first place! Or someone who's worked on it extensively enough to know the quirks, the reasoning behind non-obvious parts and knows the rest of package throughout.
Telling a user to fix a poor piece of software is incredibly frustrating and lame to those of us who, god forbid, have other things to do in our lives.
pushing jobs/internships at origin's home here in austin (and EA ones elsewhere). Hell, I still have the info sheet on it and was going to send over my resume soon. If this is true, it must come as quite a shock.
If video is an option (it should be, these days) video is extremely processor intensive. Even simple blob tracking will tax a fast system on framerates.
blob tracking or worse, object recognition (you need some sort of memory architecture to handle this to compare features to), requires an intensive scan of pixels in an image. Depending on your image resolution, its easy to run into many mega-ops for even the simplest tracker.
background: i work with 'autonomous robots' in an academic setting on some much more expensive and fancy equipment than the robosapien...
Because you can only make a robosapien do one, or some sequence of, 67 canned actions. You can't make new actions. It's just the 67, that's all forever, no more, no hope to expand..
This is not necessarily a bad thing. Most sensible autonomous architectures work this way these days. You take a few atomic actions and sequence them together to complete more complex behaviors. Now, usually you use your sensors during this time to see how you're progressing or if you need to try a different sequence to accomplish your task. Robosapien doesn't appear to have any external sensors though, aside from its innate sense of balance due to its geometry and hardwiring of the motor driver chip. I'm not sure what atomic movements RS comes with (if there are 67, thats very impressive).
Contrast with Aibo where every sensor and servo can be read/ignored/actuated to whatever degree you (or the stock programmers) can imagine.
On the other hand though, you've got to micro-manage really basic things (like balance) and need some fancy processing power to do it. And if you're programming it, the sensible thing to do would be to replicate the atomic movements I mentioned above.
You can't just control the motors as you like and invent new behavior.
You mean can't invent new atomic actions. I'm not quite sure about the validity of that statement even, since it depends on what level of parameter tuning you can do. I think most roboticists involved in autonomous agents would appreciate a robot having an innate sense of balance from its mere physics and electrical architecture. It would make their jobs easier in many respects.
Honestly, for what it does, the RS is a neat robot. The only thing really holding it back from autonomous nature is a lack of sensors to give it information about its environment and a way to process that data and then to use it to influence tuning parameters on the motor driver.
Most fully programmed autonomous systems work this way, except they need to manage the balance themselves in another thread of execution (if you're going fully software). What I'd like to see is a hybrid of this robosapien platform and some simple sensors to let it "see" obstacles or other things.
on projects such as this, the design specs would've been frozen several years ago, and then would've been conservative for the time, using proven technology.
Another factor in this is the safety of the flash ram. It is rad-hardened and built with tons of extra error correction which again, requires years of testing and special design considerations. And is extremely expensive.
Wouldn't that be VERY BAD for these multi-thousand-dollar amplifiers that rely on crystal-clean power to do their thing ?
As though the power is "crystal-clean" to begin with. Most power coming across the lines is very poor. If you're that obsessed with good power, shouldnt you have a fantastic line conditioner anyway?
If you have a robot which supports some form of connectivity (IR, wireless, tethered.. protocol isn't all that important), you can make player connect to your robot. Player is a TCP server which then allows you to write your robotics code in whatever language you see fit, provided it has the ability to connect via TCP. It abstracts away hardware in much the way a driver does, and provides a uniform way to access sensors and effectors.
Slashdot Mirror
in some autonomous robotics stuff i've worked on, after task competitions teams would get together and discuss varying approaches to problems.
While no code sharing occured (nor would've been useful, as each platform has its own unique way of doing basic tasks), discussing approaches leads often to combined approaches, fresh perspectives on ideas and then THAT leads to innovation as each time takes what they've learned and applies it to the next project. Eventually the most efficient and "best" system results.
By your logic, nobody should go to a university to learn things and should learn everything on their own to foster 'innovation', while in fact everyone would be reinventing the wheel a billion times over.
The time will certainly help, and the experience will help immensely.
:)
As for improving the world model, they'll be able to add a few more variables to it and tweak others, but it will still be far from complete. There are still going to be issues like running over something at the wrong angle, or taking a curve too sharp and the sand shifts under the tires and it gets swung wildly off course, the system overcorrects and the vehicle flips or gets turned around... problems like that are really frustrating
There is an algorithm out there called the Kalman filter which does this. It's very complicated and rooted in probability theory, but it basically takes several sensor inputs, smooths out their response based on previous values (and known noise characteristics, such as the typical standard deviation from the truth) and makes a good assumption about where the sensors will be in the near-future.
It is very accurate, if you tune it properly (thats the tricky part)
This is very important for real time things because you need to begin to smoothly react to situations before they happen (ie, driving into an obstacle at high speeds).
This is impossible to do. There are too many variables in the real world.
The bane of autonomous robotics is the fact you can't create an accurate world model. Sure, you can model the things you think will have the most effect, but there are literally millions of little things which by themselves may not mean much, but over time or in differing combinations can cause havoc and system disruption.
As an example, say for driving over barbed wire. Suppose you hit it at just such an angle the wire gets wrapped around the axle? You can't predict such things.
The post-mortems will be interesting to read. I hope they post them online.
the idea behind these things is to create automated ammo/medic/fuel ferries eventually. It wouldn't do to have a 7-ton vehicle run into a group of wounded soldiers at 40 mph. Or anything else, for that matter.
I work with autonomous robots in a lab setting. It's difficult enough to get a 2 wheeled robot the size of an RC car that moves 75 cm/sec to navigate its environment reliably. Failure is something you simply have to learn to live with and learn from (many computer scientists have a tough time getting used to the idea that these systems cannot nor ever will work 100% of the time). Honestly, you learn way more from failure than success in this business.
To get a full sized vehicle working at battlefield speeds with battlefield obstacles is a monumental challenge and almost certainly guaranteed to fail on the first try. Autonomous robotics is still a very young field, and the research published out there is generally some pretty rudimentary stuff done in a lab. Translating that stuff into a big complicated machine in a big complicated environment is a hell of a task and probably demonstrates some substantial holes in the current tech that weren't apparent from the confines of the lab.
This DARPA challenge does two excellent things for the field: Gives it a real goal and gives it a real deadline. Alot of research doesn't have a deadline and so researchers spend much of their time spinning their wheels (heh) on some of what i would consider, less important issues. This challenge gives a genuine goal to accomplish in a certain amount of time.
I definiately want to see the post-mortem on each team to see where they failed. In 2 more years, with this failure experience gained, perhaps a quarter of the teams will succeed or at least get further down the course.
rarely was in the past. Especially if millions are spent figuring out what is 'obvious'.
and its caused by the lens, not the CCD.
second one down
So while the part about the current state of the soviet economy might be useless, the part about the founding history of the soviet union would not.
i would have used a world almanac. Published yearly, every library has probably a dozen copies since they're just 1 cheap volume.
most economics magazines publish a summary of the world each year... really, getting economic information from an encyclopedia is just lazy.
LIN 312 is a linguistics class on the languages of middle earth.
It's a real class for which you get real credit.
course description
it might just've been the light of the fire on the smoke or cloud bottoms.
A couple of months ago a magnesium recycling plant in ohio (i think) burned up. A town webcam was pointed in its direction, and despite being miles away, the sky looked as bright as day from the white light reflecting off the bottom of the clouds at 2 am. You could definiately say it was glowing.
or, it could actually have been the radiation ionizing the air (is this possible, nuclear physicists?). I seem to remember some descriptions of nuclear blasts causing purple glows in the air from radiation ionizing it.
This smoke would have been highly radioactive. Those children are probably all dead.
I'd never read an account like that, even in the west which didn't gloss over the horrors of chernobyl. If its true, then that disaster was far, far worse than any of us realized.
you might be kidding, but i think of the people back then were clever enough to warrant the old style definition of hacker :)
Computers were designed and built by engineers (directed by theorticians). But they were programmed by the same women who used to run the adding machines! Though usually they were women with a college degree, often in math.
At that time, programming the computer was often seen as 'below' the designers who built the thing and not a particularly manly job. Given this, its little surprise that many of early advancements in programming were done by women. Grace Hopper's development of mnemonics comes to mind and the invention of the compiler.
Though in the western world this attitude has done a complete 180 (men are much more common as programmers), there are still some places in the world where programming is often seen as a more womanly job.
Many "calculators" today run general purpose processors and can be used for general purpose computing. I believe my old 1991 TI-82 has a Z80 in it.
It seems to me this new device has some ideas in mind for it should be used for, but is fairly general purpose. At the moment, its a computer. Though the systems it becomes embedded in might be called something else.
Just like my calculator's processor could be used in a 'computer'. But its embedded use is for arithmetic and algebra, therefore its a 'calculator'
back in the 1940s, a "computer" was a young woman who sat in front of an adding machine punching in numbers. It was actually quite awhile before the electronic machines came to be known as 'computers'. I'm sure many early designers would laugh at the thought of their complicated multi-ton kilowatt consuming monstrosities being named after the job a 19 year old girl did.
What it is called depends on its use. You don't call a PDA a computer do you? Even though it clearly is one.
If this device is in fact used for computing, then it is in fact, a computer.
And I would be the queen of england had I been born in the right place at the right time.
RedHat is making a profit
Are they now, finally? Without accounting trickery? Note that they've dropped consumer support and maintenance as of almost immediately. Even microsoft treats average consumers better in that respect.
IBM, a company that obviously like to make cash of their code, is making money as well while still working on open source.
IBM may use open source in their product lines, but they're certainly not an open source company. Their money is from their other bajillion divisions from really big hardware to enterprise management.
The above poster wants to know how many people make an actual living directly from open source.
For real autonomous steering you're going to need a couple of cams for stereoscopic vision, plus some badass software to handle it, of your own creation.
stereoscopic navigation is still fairly new, even in the research world..i don't think there are any software packages out there you can go grab to work with. a quick google seems to support this since "stereoscopic robot navigation" returns mostly research papers..
This is especially true if its a non-trivial piece of software. Several times new programmers have come into software packages I've been working on, don't bother to read the structural documentation or even the useful other code that serves as examples for how to improve and extend upon the existing structure.
Instead they try and do things their own way, often end up doing things redundantly or breaking something else and just otherwise fouling more than they contribute.
The best person to improve upon software is the person who designed in the first place! Or someone who's worked on it extensively enough to know the quirks, the reasoning behind non-obvious parts and knows the rest of package throughout.
Telling a user to fix a poor piece of software is incredibly frustrating and lame to those of us who, god forbid, have other things to do in our lives.
pushing jobs/internships at origin's home here in austin (and EA ones elsewhere). Hell, I still have the info sheet on it and was going to send over my resume soon. If this is true, it must come as quite a shock.
blob tracking or worse, object recognition (you need some sort of memory architecture to handle this to compare features to), requires an intensive scan of pixels in an image. Depending on your image resolution, its easy to run into many mega-ops for even the simplest tracker.
Because you can only make a robosapien do one, or some sequence of, 67 canned actions. You can't make new actions. It's just the 67, that's all forever, no more, no hope to expand..
This is not necessarily a bad thing. Most sensible autonomous architectures work this way these days. You take a few atomic actions and sequence them together to complete more complex behaviors. Now, usually you use your sensors during this time to see how you're progressing or if you need to try a different sequence to accomplish your task. Robosapien doesn't appear to have any external sensors though, aside from its innate sense of balance due to its geometry and hardwiring of the motor driver chip. I'm not sure what atomic movements RS comes with (if there are 67, thats very impressive).
Contrast with Aibo where every sensor and servo can be read/ignored/actuated to whatever degree you (or the stock programmers) can imagine.
On the other hand though, you've got to micro-manage really basic things (like balance) and need some fancy processing power to do it. And if you're programming it, the sensible thing to do would be to replicate the atomic movements I mentioned above.
You can't just control the motors as you like and invent new behavior.
You mean can't invent new atomic actions. I'm not quite sure about the validity of that statement even, since it depends on what level of parameter tuning you can do. I think most roboticists involved in autonomous agents would appreciate a robot having an innate sense of balance from its mere physics and electrical architecture. It would make their jobs easier in many respects.
Honestly, for what it does, the RS is a neat robot. The only thing really holding it back from autonomous nature is a lack of sensors to give it information about its environment and a way to process that data and then to use it to influence tuning parameters on the motor driver.
Most fully programmed autonomous systems work this way, except they need to manage the balance themselves in another thread of execution (if you're going fully software). What I'd like to see is a hybrid of this robosapien platform and some simple sensors to let it "see" obstacles or other things.
Another factor in this is the safety of the flash ram. It is rad-hardened and built with tons of extra error correction which again, requires years of testing and special design considerations. And is extremely expensive.
As though the power is "crystal-clean" to begin with. Most power coming across the lines is very poor. If you're that obsessed with good power, shouldnt you have a fantastic line conditioner anyway?
The player system.
If you have a robot which supports some form of connectivity (IR, wireless, tethered.. protocol isn't all that important), you can make player connect to your robot. Player is a TCP server which then allows you to write your robotics code in whatever language you see fit, provided it has the ability to connect via TCP. It abstracts away hardware in much the way a driver does, and provides a uniform way to access sensors and effectors.
It's a nice system.