Consider aviation. Aviation had an age of rapid advance from about 1910 to 1970. In those sixty years, aviation went from the Wright Brothers to the Boeing 747 and the Apollo program. Every decade completely obsoleted the aircraft of a decade earlier.
Then, suddenly, it was all over. Advances since then have been minor compared to any ten-year period in those first sixty years.
See Optimizing Array Bounds Checks Using Flow Analysis. The Java JVM does some array bounds checking optimization. C and C++ don't, because the language doesn't know how big arrays are. And millions suffer because of that.
Now, we damn well know that, barring memory corruption or a serious bug in the STL, that this won't overrun the boundaries of the container. So why should i be range-checked ten million times?
It shouldn't. If the compiler, rather than the template library, knew about subscript checking, it could optimize much of it out. Most subscript checks in FOR loops can be hoisted out of the loop. Only a single check at loop entry is required, and that may resolve to a constant expression which is always true, eliminating the test entirely. Most C compilers today know how to hoist expressions and do basic strength reduction; that's why, for loops, pointer arithmetic and subscripts generate almost the same code in modern compilers.
But because the language doesn't know how big arrays are, the compiler can't help out here.
This is another price paid for papering over the problem with templates.
They've spent far less money than GM spent on the EV-1, and have almost as many cars on the road. About 1100 EV1 cars were produced.
The current version of the Tesla roadster is a reasonably good sports car. Speed is good, acceleration is very good, the range is 200 miles, and it looks good as it whooshes by. It's overpriced, but there's hope of getting that down as volume goes up.
They had some initial problems stemming from trying to make it go fast. First they had motor overheating problems at high revs, so they put in a two-speed transmission. That was a disaster; shifting under load ate up the transmission because the two speeds were too far apart. Then they went back to a simple single speed transmission, but water-cooled the motor, which simplified the mechanics and got them the desired top speed. The current drive train seems to be holding up well.
Top speed is only 125MPH, which is low for $100K+ sports cars, but few customers really take their Ferraris to a track anyway.
I see Teslas on the road almost daily. I live near the Silicon Valley dealership and on a road the sales reps use for demos. They change lanes very smoothly, with all that battery mass holding the center of gravity down.
The Python world suffers badly from this problem. There are many add-on modules for Python that are written in C. The interfaces for databases, SSL sockets, and similar things one needs for basic web applications are third-party modules in Python. In most cases, the module has one maintainer.
The C API for Python changes with each release of Python, and modules have to be updated and rebuilt for each platform. This process lags years behind Python releases. Often, the needed changes are minor, but short of forking and taking over maintenance of the module, there's no way to get them done fast.
There have been amusing moments. At one point, the maintenance organization for a module used in business applications was a World of Warcraft guild. At least they got stuff done.
C++ is dangerous because it needs to be. There needs to be one high level language in the world that's like juggling operating chainsaws to code in it, because of the options that gives you.
Wrong. It's not essential that a language be unsafe to have low level constructs. Ada, Modula I/II/III, Clascal, Object Pascal, Eiffel, and other hard-compiled languages have been much safer than C++, with comparable power. You don't have to go to an interpretive environment to get safety. That's an illusion from Java, which was made interpretive because Sun wanted portability between their SPARC architecture and the competing Wintel systems.
It's kind of sad. The C++ committee has taken the general position that the underlying defects of C++ should be papered over by making it possible to write templates that hide the problem. But the hiding never quite works; the mold always seeps through the wallpaper.
The root of the problem is that C and C++ backed into a type system. Originally, C barely had types at all; there were ints and there were floats. Pointers and ints were almost interchangeable. Fields in structures were just offsets, and field names had to be unique across all structures. Gradually, C evolved into a strongly typed language. Sort of. "void *" was introduced as a sort of escape hatch for the type system.
More importantly, there was never a clear distinction made between arrays and pointers. That single design decision is responsible for most of the buffer overflows in the world.
We should have had syntax like
int read(int fd, char buf[n]&, size_t n); to replace the old
int read(int fd, char *buf, size_t n);
which says nothing about the size of the array. Right there is the cause of most buffer overflows - the language doesn't properly support talking about the size of arrays.
Part of the problem there was a major error in the original design of C++ - it didn't have "&" references. So you couldn't talk about a reference to an array; you had to use a pointer to the first element. That pointer has the type of the element, not of an array. Every time you write "char *buf" instead of "char buf[n]&", you're lying to the compiler. The cost of that lie is millions of crashes a day.
Instead of fixing the mess underneath, C++ papered it over. Arrays were wrapped with classes in the Standard Template Library. The STL is a good thing, but it's not good enough to totally replace built-in arrays. So real-world programs remain a mixture of ambiguous built-in arrays, pointers to arrays, and STL arrays.
Then the STL approached iteration as an extension of pointer arithmetic. For "compatibility" with C pointer arithmetic, iterators are not only unchecked, but are not explicitly bound to the collection over which they iterate. So the safety problems of C were carried over into STL arrays. This was another bad decision. Most modern languages approach iteration by providing a "do this to all that stuff" construct used for most common iteration cases. C++ does not.
This is why I'm so critical of the C++ committee. If they'd focused on safety, instead of cool but obscure template features, software would be much better today.
No lawyer can legitimately use Google-hosted services, unless they're doing work for Google. It would be a huge violation of confidentiality.
In Silicon Valley, where many lawyers are doing work adverse to Google, absolutely no way would this be tolerated. Even Microsoft Windows Update makes some lawyers nervous.
What netbooks are still available with Linux?
on
11.6" Netbooks Face Off
·
· Score: 2, Interesting
I'd still like to get a somewhat bigger Linux netbook. I have some EeePC 2G Surf units, and like them, but the original version with the tiny screen just isn't quite enough. Has Microsoft totally crushed the Linux netbook market, or is something cheap still available with no Windows?
This is promising. We need more and better hand-held medical devices. Medical technology tends to be bulky, and as it is downsized, it can be deployed more freely.
A friend of mine is a horse veterinarian, and she's always looking for devices that can be used in the field. Vets sometimes get new gear before human doctors do, because it can be deployed for animal use while it's still in clinical testing for humans. She already has compact X-ray gear which displays on a laptop; that was a big advance. She's had portable ultrasound gear for a decade or more. Field tests on blood, though, are still in their infancy.
The drug-test device, though, is testing for simple compounds. That's easier than most medical tests.
They're reselling InfoSpace. Click on this link to demonstrate.
InfoSpace claims to be passing search queries to Google, Yahoo, Bing, Ask, and Twitter, then combining the results. I'm surprised they can do that. Google, Yahoo, and Bing all prohibit that in their terms of service. (With Google, you're only allowed to use Google's display format, expressed in their AJAX API, but you can add additional info. Google doesn't allow reordering or combining their results. Yahoo is more flexible; you can reorder, reformat, and, subject to some restrictions, add ads. Bing allows reordering and combining for Web searches, but not other types of searches.)
When enough users have been lulled into inaction and enough machines have been taken over, the enemy will strike.
Meanwhile, the operators may be sending commands to specific PCs of interest. Security researchers might not be picking up commands targeted to only a few machines.
Most anti-virus defense efforts assume the enemy is only marginally competent and has no strategic goal. It's clear from what's known about the Conflicker attack that the enemy is significantly more competent and better funded than those behind previous viruses. The Conflicker attack was updated frequently until it was deploying itself successfully despite defensive efforts. Once the attack continued to grow despite defensive efforts, the updates stopped. That's not loss of interest, that's operational art.
This thing behaves like it has military tactical planning behind it.
And can you name a couple of examples of this happening in Windows Vista or Windows 7? Vista has been out for 2 years now, it is, like it or not, "the current Windows version."
Yes, I can.:
"Hypponen detailed how Conficker's code triggered an autorun on Windows, even when a user might have had autorun disabled for USB media."
The people to call when this happens are Failure Analysis Associates, an engineering consultancy that analyzes engineering failures. They started with building structural failures, and they've branched out. They call themselves "The Exponent Group" now.
One of the things they do is battery failure investigation. These are the people your class action lawyer brings in to find out what really happened. Companies with a clue use this to fix their manufacturing processes. Whether or not Apple has a clue about this, or whether they just take whatever their China supplier gives them, remains to be determined in court.
Now what sort of hacker is going to enlist in the military?
An unemployed one. At least the U.S. military is hiring.
Of course, even if you go in for a technical job, you may be deployed to Iraq, wiring up CAT-5 cable and Cisco routers while dodging IEDs on your way to work.
Much military work today is about systems for sorting out who's enemy and who isn't. The days when everybody in front of you is enemy are over. (In recent decades, enemies who've tried stand-up battles against US troops were defeated within days.)
Security is very discouraging. I was in the field a long time ago and got fed up. It's just hopeless. The same problems come up over and over.
Microsoft has the mindset that anything executable that comes near their operating system should immediately be executed. CDs and DVDs autorun. USB devices autorun. Active-X controls autorun. Universal Plug and Play stuff autoruns. Yes, they now have some "security controls" on this, which sometimes actually work.
Remote update. Not only is patch downloading a lousy way to prevent security problems, the download process itself introduces a huge backdoor. With every two-bit application now supporting remote update, it's easy to find an attack vector.
Overly powerful "install" mechanisms. Apple had it approximately right in the original MacOS; an application was one file with a resource fork. Delete one file and the app was gone. Now, installers expect to run with administrator privileges and blither all over the machine.
Crappy security models. We know what works - mandatory security with integrity levels. The trouble is that most apps whine when made to work under those restrictions.
Thirty years of buffer overflows. The fundamental problem is that the C and C++ concept of arrays is broken. The language has no idea how big an array is. That's defective by design.
The C++ crowd tries to paper over the problem with templates, but the mold always comes through the wallpaper. Most of the newer languages come with a gonzo interpretive system underneath, which makes them slow, overly complex, or both.
That's just part of the list. I don't see a determined effort to fix the underlying problems. Given that, it's hopeless.
LTSpice is quite good if you want to design power supplies with Linear Technology components.
The component library has just about everything Linear makes, and not much else. So you need
some additional libraries for other purposes. You'll probably have to put together a model library for your students, from various downloaded models.
I've had fun with LTSpice. As an exercise, I've been designing hardware to run a Model 15 Teletype (1930s technology) from a USB port. The usual power supply for the 60mA current loop required is a 120VDC supply through a 2K 10W resistor, to get enough punch to energize the 4H 55 ohm selector magnet of the Teletype fast enough. Most of the energy is wasted heating up the big resistor. But I've designed something that up-converts 4.5VDC to 120VDC using an IC intended for photoflash applications, charges up a capacitor when the input is low, and when the input transitions to high (MARK), dumps the energy into the magnet. The 120VDC is only needed for the first 1ms or so of each bit time, to push current through the big inductance. A 3.3V linear regulator then provides the sustain current to keep the magnet pulled in after the cap dumps. The whole thing needs 250mA at 4.5V, which can be taken from a USB port. Separately, a small CPU is needed to do the serial port stuff for the signal.
One would assume that it's not unreasonably hard to start from walking and move to running.
Yes, one would assume that. And one would be wrong.
People have been studying locomotion for centuries. Until the 1980s, almost everyone obsessed on gait issue. There's an extensive literature on stride length, footfall pattern, and similar gait issues. Most locomotion studies focused on straight-line movement, too.
The real issue is handling the hard cases - slipping, tripping, hills, finding footholds.
That's what legs are for. (On flat ground, wheels are easier and better. There is no point making legged machines which can only handle flat ground.) Legs are assets to be deployed as necessary to get first traction, then balance, then propulsion. Gaits are an emergent behavior of that process.
To run smoothly and efficiently robots will need joint motors that are springy and compliant just like human muscles.
I tend to agree. What you want to emulate a muscle is a spring with a variable spring constant and zero position. There are several ways to do that. A double-ended pneumatic cylinder can do it; if you pressurize both ends at a high pressure, it's stiff, and if you pressurize both ends at low pressure, it's springy. Relative differences in pressure change the zero position. If the valves are close to the cylinder, position control of pneumatic cylinders works. Someone at CWRU built a robot this way. Of course, you need an onboard air compressor.
There's a new variation on this concept - a device which is both a pneumatic cylinder and a linear motor. A pneumatic cylinder is a piston in a tube, and a linear motor is a magnet in
a tube with coils outside the tube. So a device can be built which has a magnet as the piston and coils outside the tube, allowing both pneumatic and electrical operation. The linear motor does the fine positioning and the pneumatic system provides high power when needed.
It's possible to do an adjustable spring mechanically, using two actuators pulling on opposed springs. That's been tried, but most of the designs involve pulleys and strings, which tend to be troublesome. I've been working on a new string-less mechanical design in that area, one that can fit inside the space required for an R/C servo of the type used on hobbyist robots.
BigDog is hydraulic, and its actuators are very stiff. They had to put a bicycle shock absorber at the end of each leg to handle the landing shocks. But BigDog doesn't recover significant running energy. The Legged Squad Support System, the militarized successor to BigDog, may have energy recovery. There are things one can do with hydraulic accumulators and extra valves to get spring-like behavior out of hydraulics. Still, BigDog does a nice job; energy recovery will improve gas mileage, not stability.
There's also a way to fake spring-like behavior, using a "series elastic actuator". This is a leadscrew-type linear actuator in series with a stiff spring. When the spring is compressed, the drive motor frantically tries to release the pressure before the spring bottoms out. This doesn't really store much energy, but it can be used to fake something that does. Pratt at MIT came up with this, and it's a useful research tool.
There have been a number of other, more exotic muscle-line actuators, including fluids that change properties in an electric field, but so far, they're all worse than the ones mentioned above.
There's not much of a moment of suspension, but there is some. There's a little more than with Research ASIMO.
Most legged running researchers are trying to maintain some stability criterion, and avoid spending much time in suspension, with all legs off the ground. This may be the wrong approach.
There are two schools of thought in this field. There are the people who start with walking and try to work up to running, and the people who start with hopping and try to work down to running. Most work is from the first school, but BigDog comes from the hopping faction.
Suspension is sometimes a good way to get out of trouble. You get to move all the limbs while in flight and get completely new footholds. Watch some basketball and you'll see this frequently. There's also a half-suspension in quadrupeds, as when you see a horse kick up their hind end to reposition the legs.
The technology in this area can get much, much better. The hardware, in robots, sensors, and computers, is almost good enough. Now we need smarter control algorithms.
As the article points out,
"For a device as simple as a keyboard, it is hard to imagine why a firmware update mechanism is even required." There's no justification for including an update feature other than as a designed-in security hole. The keyboard CPU should be running off a ROM, or at least an MPU where the security bit has been set to prevent future changes.
This looks like a "feature" put in for development that should have been pulled before release.
The TOTAL confinement time looks like it'll be measured in microseconds at most on this thing, no way is there time for active control of the plasma during a shot like that.
I see that. So what do they want all the compute power for? I'd assumed I was reading an oversimplified version, and all the compute power was to actively stabilize something. If they just need a simultaneous push, they don't need compute power. I'm missing something.
There's been some modest interest in actively stabilized fusion for a while, but this is the first mechanical scheme.
The basic problem with fusion reactors is that the plasmas aren't stable. Most work to date involves trying to come up with some geometry that produces an inherently stable plasma. So far, nothing works, although some geometries almost work. But it's not that hard to build a small machine that has an unstable plasma.
The original Stellerator, in 1951, did that.
The instabilities occur on the order of milliseconds, not microseconds or nanoseconds. That's slow enough that some kind of active stabilization scheme to nudge the instabilities back in line might work. Something with a large number of sensors and actuators.
But I'd been expecting electrostatic deflection plates or magnets, not physical pistons.
Slashdot Mirror
The Concorde first flew in 1969.
Of course.
Consider aviation. Aviation had an age of rapid advance from about 1910 to 1970. In those sixty years, aviation went from the Wright Brothers to the Boeing 747 and the Apollo program. Every decade completely obsoleted the aircraft of a decade earlier. Then, suddenly, it was all over. Advances since then have been minor compared to any ten-year period in those first sixty years.
See Optimizing Array Bounds Checks Using Flow Analysis. The Java JVM does some array bounds checking optimization. C and C++ don't, because the language doesn't know how big arrays are. And millions suffer because of that.
Now, we damn well know that, barring memory corruption or a serious bug in the STL, that this won't overrun the boundaries of the container. So why should i be range-checked ten million times?
It shouldn't. If the compiler, rather than the template library, knew about subscript checking, it could optimize much of it out. Most subscript checks in FOR loops can be hoisted out of the loop. Only a single check at loop entry is required, and that may resolve to a constant expression which is always true, eliminating the test entirely. Most C compilers today know how to hoist expressions and do basic strength reduction; that's why, for loops, pointer arithmetic and subscripts generate almost the same code in modern compilers.
But because the language doesn't know how big arrays are, the compiler can't help out here.
This is another price paid for papering over the problem with templates.
They've spent far less money than GM spent on the EV-1, and have almost as many cars on the road. About 1100 EV1 cars were produced.
The current version of the Tesla roadster is a reasonably good sports car. Speed is good, acceleration is very good, the range is 200 miles, and it looks good as it whooshes by. It's overpriced, but there's hope of getting that down as volume goes up.
They had some initial problems stemming from trying to make it go fast. First they had motor overheating problems at high revs, so they put in a two-speed transmission. That was a disaster; shifting under load ate up the transmission because the two speeds were too far apart. Then they went back to a simple single speed transmission, but water-cooled the motor, which simplified the mechanics and got them the desired top speed. The current drive train seems to be holding up well. Top speed is only 125MPH, which is low for $100K+ sports cars, but few customers really take their Ferraris to a track anyway.
I see Teslas on the road almost daily. I live near the Silicon Valley dealership and on a road the sales reps use for demos. They change lanes very smoothly, with all that battery mass holding the center of gravity down.
The Python world suffers badly from this problem. There are many add-on modules for Python that are written in C. The interfaces for databases, SSL sockets, and similar things one needs for basic web applications are third-party modules in Python. In most cases, the module has one maintainer.
The C API for Python changes with each release of Python, and modules have to be updated and rebuilt for each platform. This process lags years behind Python releases. Often, the needed changes are minor, but short of forking and taking over maintenance of the module, there's no way to get them done fast.
There have been amusing moments. At one point, the maintenance organization for a module used in business applications was a World of Warcraft guild. At least they got stuff done.
C++ is dangerous because it needs to be. There needs to be one high level language in the world that's like juggling operating chainsaws to code in it, because of the options that gives you.
Wrong. It's not essential that a language be unsafe to have low level constructs. Ada, Modula I/II/III, Clascal, Object Pascal, Eiffel, and other hard-compiled languages have been much safer than C++, with comparable power. You don't have to go to an interpretive environment to get safety. That's an illusion from Java, which was made interpretive because Sun wanted portability between their SPARC architecture and the competing Wintel systems.
It's kind of sad. The C++ committee has taken the general position that the underlying defects of C++ should be papered over by making it possible to write templates that hide the problem. But the hiding never quite works; the mold always seeps through the wallpaper.
The root of the problem is that C and C++ backed into a type system. Originally, C barely had types at all; there were ints and there were floats. Pointers and ints were almost interchangeable. Fields in structures were just offsets, and field names had to be unique across all structures. Gradually, C evolved into a strongly typed language. Sort of. "void *" was introduced as a sort of escape hatch for the type system.
More importantly, there was never a clear distinction made between arrays and pointers. That single design decision is responsible for most of the buffer overflows in the world. We should have had syntax like
int read(int fd, char buf[n]&, size_t n);
to replace the old
int read(int fd, char *buf, size_t n);
which says nothing about the size of the array. Right there is the cause of most buffer overflows - the language doesn't properly support talking about the size of arrays.
Part of the problem there was a major error in the original design of C++ - it didn't have "&" references. So you couldn't talk about a reference to an array; you had to use a pointer to the first element. That pointer has the type of the element, not of an array. Every time you write "char *buf" instead of "char buf[n]&", you're lying to the compiler. The cost of that lie is millions of crashes a day.
Instead of fixing the mess underneath, C++ papered it over. Arrays were wrapped with classes in the Standard Template Library. The STL is a good thing, but it's not good enough to totally replace built-in arrays. So real-world programs remain a mixture of ambiguous built-in arrays, pointers to arrays, and STL arrays.
Then the STL approached iteration as an extension of pointer arithmetic. For "compatibility" with C pointer arithmetic, iterators are not only unchecked, but are not explicitly bound to the collection over which they iterate. So the safety problems of C were carried over into STL arrays. This was another bad decision. Most modern languages approach iteration by providing a "do this to all that stuff" construct used for most common iteration cases. C++ does not.
This is why I'm so critical of the C++ committee. If they'd focused on safety, instead of cool but obscure template features, software would be much better today.
No lawyer can legitimately use Google-hosted services, unless they're doing work for Google. It would be a huge violation of confidentiality.
In Silicon Valley, where many lawyers are doing work adverse to Google, absolutely no way would this be tolerated. Even Microsoft Windows Update makes some lawyers nervous.
I'd still like to get a somewhat bigger Linux netbook. I have some EeePC 2G Surf units, and like them, but the original version with the tiny screen just isn't quite enough. Has Microsoft totally crushed the Linux netbook market, or is something cheap still available with no Windows?
This is promising. We need more and better hand-held medical devices. Medical technology tends to be bulky, and as it is downsized, it can be deployed more freely.
A friend of mine is a horse veterinarian, and she's always looking for devices that can be used in the field. Vets sometimes get new gear before human doctors do, because it can be deployed for animal use while it's still in clinical testing for humans. She already has compact X-ray gear which displays on a laptop; that was a big advance. She's had portable ultrasound gear for a decade or more. Field tests on blood, though, are still in their infancy.
The drug-test device, though, is testing for simple compounds. That's easier than most medical tests.
They're reselling InfoSpace. Click on this link to demonstrate.
InfoSpace claims to be passing search queries to Google, Yahoo, Bing, Ask, and Twitter, then combining the results. I'm surprised they can do that. Google, Yahoo, and Bing all prohibit that in their terms of service. (With Google, you're only allowed to use Google's display format, expressed in their AJAX API, but you can add additional info. Google doesn't allow reordering or combining their results. Yahoo is more flexible; you can reorder, reformat, and, subject to some restrictions, add ads. Bing allows reordering and combining for Web searches, but not other types of searches.)
There's a simple random number generator based on a radioactive source on-line. That can be accessed through a Java app, and the hardware info needed to build one of your own is on line. There are commercial random number generators. USB, even. A serious data center should have a few of these.
When enough users have been lulled into inaction and enough machines have been taken over, the enemy will strike. Meanwhile, the operators may be sending commands to specific PCs of interest. Security researchers might not be picking up commands targeted to only a few machines.
Most anti-virus defense efforts assume the enemy is only marginally competent and has no strategic goal. It's clear from what's known about the Conflicker attack that the enemy is significantly more competent and better funded than those behind previous viruses. The Conflicker attack was updated frequently until it was deploying itself successfully despite defensive efforts. Once the attack continued to grow despite defensive efforts, the updates stopped. That's not loss of interest, that's operational art.
This thing behaves like it has military tactical planning behind it.
And can you name a couple of examples of this happening in Windows Vista or Windows 7? Vista has been out for 2 years now, it is, like it or not, "the current Windows version."
Yes, I can.: "Hypponen detailed how Conficker's code triggered an autorun on Windows, even when a user might have had autorun disabled for USB media."
The people to call when this happens are Failure Analysis Associates, an engineering consultancy that analyzes engineering failures. They started with building structural failures, and they've branched out. They call themselves "The Exponent Group" now.
One of the things they do is battery failure investigation. These are the people your class action lawyer brings in to find out what really happened. Companies with a clue use this to fix their manufacturing processes. Whether or not Apple has a clue about this, or whether they just take whatever their China supplier gives them, remains to be determined in court.
Now what sort of hacker is going to enlist in the military?
An unemployed one. At least the U.S. military is hiring.
Of course, even if you go in for a technical job, you may be deployed to Iraq, wiring up CAT-5 cable and Cisco routers while dodging IEDs on your way to work.
Much military work today is about systems for sorting out who's enemy and who isn't. The days when everybody in front of you is enemy are over. (In recent decades, enemies who've tried stand-up battles against US troops were defeated within days.)
Security is very discouraging. I was in the field a long time ago and got fed up. It's just hopeless. The same problems come up over and over.
That's just part of the list. I don't see a determined effort to fix the underlying problems. Given that, it's hopeless.
LTSpice is quite good if you want to design power supplies with Linear Technology components. The component library has just about everything Linear makes, and not much else. So you need some additional libraries for other purposes. You'll probably have to put together a model library for your students, from various downloaded models.
I've had fun with LTSpice. As an exercise, I've been designing hardware to run a Model 15 Teletype (1930s technology) from a USB port. The usual power supply for the 60mA current loop required is a 120VDC supply through a 2K 10W resistor, to get enough punch to energize the 4H 55 ohm selector magnet of the Teletype fast enough. Most of the energy is wasted heating up the big resistor. But I've designed something that up-converts 4.5VDC to 120VDC using an IC intended for photoflash applications, charges up a capacitor when the input is low, and when the input transitions to high (MARK), dumps the energy into the magnet. The 120VDC is only needed for the first 1ms or so of each bit time, to push current through the big inductance. A 3.3V linear regulator then provides the sustain current to keep the magnet pulled in after the cap dumps. The whole thing needs 250mA at 4.5V, which can be taken from a USB port. Separately, a small CPU is needed to do the serial port stuff for the signal.
One would assume that it's not unreasonably hard to start from walking and move to running.
Yes, one would assume that. And one would be wrong.
People have been studying locomotion for centuries. Until the 1980s, almost everyone obsessed on gait issue. There's an extensive literature on stride length, footfall pattern, and similar gait issues. Most locomotion studies focused on straight-line movement, too.
The real issue is handling the hard cases - slipping, tripping, hills, finding footholds. That's what legs are for. (On flat ground, wheels are easier and better. There is no point making legged machines which can only handle flat ground.) Legs are assets to be deployed as necessary to get first traction, then balance, then propulsion. Gaits are an emergent behavior of that process.
To run smoothly and efficiently robots will need joint motors that are springy and compliant just like human muscles.
I tend to agree. What you want to emulate a muscle is a spring with a variable spring constant and zero position. There are several ways to do that. A double-ended pneumatic cylinder can do it; if you pressurize both ends at a high pressure, it's stiff, and if you pressurize both ends at low pressure, it's springy. Relative differences in pressure change the zero position. If the valves are close to the cylinder, position control of pneumatic cylinders works. Someone at CWRU built a robot this way. Of course, you need an onboard air compressor.
There's a new variation on this concept - a device which is both a pneumatic cylinder and a linear motor. A pneumatic cylinder is a piston in a tube, and a linear motor is a magnet in a tube with coils outside the tube. So a device can be built which has a magnet as the piston and coils outside the tube, allowing both pneumatic and electrical operation. The linear motor does the fine positioning and the pneumatic system provides high power when needed.
It's possible to do an adjustable spring mechanically, using two actuators pulling on opposed springs. That's been tried, but most of the designs involve pulleys and strings, which tend to be troublesome. I've been working on a new string-less mechanical design in that area, one that can fit inside the space required for an R/C servo of the type used on hobbyist robots.
BigDog is hydraulic, and its actuators are very stiff. They had to put a bicycle shock absorber at the end of each leg to handle the landing shocks. But BigDog doesn't recover significant running energy. The Legged Squad Support System, the militarized successor to BigDog, may have energy recovery. There are things one can do with hydraulic accumulators and extra valves to get spring-like behavior out of hydraulics. Still, BigDog does a nice job; energy recovery will improve gas mileage, not stability.
There's also a way to fake spring-like behavior, using a "series elastic actuator". This is a leadscrew-type linear actuator in series with a stiff spring. When the spring is compressed, the drive motor frantically tries to release the pressure before the spring bottoms out. This doesn't really store much energy, but it can be used to fake something that does. Pratt at MIT came up with this, and it's a useful research tool.
There have been a number of other, more exotic muscle-line actuators, including fluids that change properties in an electric field, but so far, they're all worse than the ones mentioned above.
There's not much of a moment of suspension, but there is some. There's a little more than with Research ASIMO.
Most legged running researchers are trying to maintain some stability criterion, and avoid spending much time in suspension, with all legs off the ground. This may be the wrong approach.
There are two schools of thought in this field. There are the people who start with walking and try to work up to running, and the people who start with hopping and try to work down to running. Most work is from the first school, but BigDog comes from the hopping faction.
Suspension is sometimes a good way to get out of trouble. You get to move all the limbs while in flight and get completely new footholds. Watch some basketball and you'll see this frequently. There's also a half-suspension in quadrupeds, as when you see a horse kick up their hind end to reposition the legs.
The technology in this area can get much, much better. The hardware, in robots, sensors, and computers, is almost good enough. Now we need smarter control algorithms.
As the article points out, "For a device as simple as a keyboard, it is hard to imagine why a firmware update mechanism is even required." There's no justification for including an update feature other than as a designed-in security hole. The keyboard CPU should be running off a ROM, or at least an MPU where the security bit has been set to prevent future changes.
This looks like a "feature" put in for development that should have been pulled before release.
The TOTAL confinement time looks like it'll be measured in microseconds at most on this thing, no way is there time for active control of the plasma during a shot like that.
I see that. So what do they want all the compute power for? I'd assumed I was reading an oversimplified version, and all the compute power was to actively stabilize something. If they just need a simultaneous push, they don't need compute power. I'm missing something.
There's work on active stabilization. See "Active-Feedback Control of the Magnetic Boundary for Magnetohydrodynamic Stabilization of a Fusion Plasma". That's a 2006 paper on a scheme involving 192 active feedback coils to stabilize a plasma. There's other work like that, and hope that one of the designs that's almost stable might be nudged into stability with active control.
There's been some modest interest in actively stabilized fusion for a while, but this is the first mechanical scheme.
The basic problem with fusion reactors is that the plasmas aren't stable. Most work to date involves trying to come up with some geometry that produces an inherently stable plasma. So far, nothing works, although some geometries almost work. But it's not that hard to build a small machine that has an unstable plasma. The original Stellerator, in 1951, did that.
The instabilities occur on the order of milliseconds, not microseconds or nanoseconds. That's slow enough that some kind of active stabilization scheme to nudge the instabilities back in line might work. Something with a large number of sensors and actuators. But I'd been expecting electrostatic deflection plates or magnets, not physical pistons.