A very important bit of processing (depth calculation) is in the Kinect. The depth camera sees a 1280x960 image of IR dots which is turned into a 640x480 depth reconstruction. This is criticial and quite complex to achieve. The kinect would be near useless if they would have moved this bit of processing to the Xbox. Instead, even though all the skeletal tracking stuff is still in the console, it's still extremely useful for all kinds of computer vision research.
Quite honestly, I don't have much experience with autotools. There are two reasons: what little I've seen looks, at first glance, as a nightmare, and, as a user, the experience is horrible. Specifically, autotools is slow. These days I spend more time./configuring than I do actually compiling, especially with distcc (./configure not being parallelizable). Even worse, sometimes I need to rebuild all of the scripts due to some patch, and that adds even more time to an already ridiculously inefficient process. I mean, seriously, why do I need to check for a C compiler, determine the maximum length of commandline arguments, and figure out if I have 20 system headers and 30 libc functions every time I want to compile a package?
Meanwhile, CMake is a hell of a lot faster, uses a more modern language, and can integrate better with other build environments. I've used CMake for a couple of projects and, although the language does have its quirks, it's mostly been smooth sailing. Where I don't use/need CMake, I use simple Makefiles.
So no, I'm not in a position of familiarity with both systems to be able to do a detailed objective comparison as a developer, but as a user I can clearly say CMake is much superior (at least the way it is used by actual projects), and as a developer I can at least say CMake is nice. Several large projects have migrated from autotools to CMake, and I bet they had a good reason.
Meanwhile, most small projects using autotools only appear to be using them because "it's what everyone else uses" and don't really understand them. Maybe autotools is great if you're an autotools guru, but it's still slow, and most people aren't going to invest the time to properly learn a system based on arcane tools. As far as I'm concerned, it's the CVS of build systems - sure, it kind of works works, but honestly, I'd rather either use a modern DVCS or stick with tarballs and patches (bare Makefiles).
cmake is built on OS tools, including GNU make in the case of Linux. What you're thinking of is the use of cmake over GNU autotools. And we're all happy for it.
The GNU Compiler Collection isn't going anywhere (though competition from LLVM is good and welcome), but the sooner Autotools dies, the better.
The signal would be stronger (well, except for the walls of the ISS), but most consumer GPS chipsets are utterly confused at high altitudes and high ground speeds. No real reason it couldn't be made to work given suitable GPS firmware, but it won't work out of the box.
This is a somewhat different thing from what Johnny Lee did, though. Johnny took existing Wiimote driver code and used it to do some very cool things with the data, such as his famous head tracking demonstration. He didn't figure out the actual communications protocol, though (in fact, I did a lot of the early Wiimote reverse engineering hacks too; I guess I have a thing for wacky game controllers!).
Unfortunately for us engineers and low-level hackers, the people actually finding practical algorithms and cool uses for these devices tend to get more attention than the people hacking the low-level details;). I'm genuinely excited to see what computer vision experts can do with the raw Kinect data, though (I personally can't do much more than apply a cheap heat map to the data like I did in my video).
The final device still does a ridiculous amount of processing onboard, compared to just about every other peripheral out there. In order to get the depth map, it has to analyze the IR picture (which is quite different from a depth map) and extract contour and depth info from the density of the IR point cloud. This is being done in the PrimeSense SoC chip.
There is also a Marvell SoC chip in charge of audio processing and echo cancellation. I believe it might also be responsible for triangulation of the audio source.
The processing to get gesture data and do voice recognition is software, but don't underestimate the amount of processing going on in the device just to get the depth map and echo-canceled cooked audio.
The box of my Kinect actually said, and I quote: Requires acceptance of software license agreement available in manual and at: www.xbox.com/sla. You accept by using the Kinect Sensor and your Xbox 360.
It's a good thing I never used my Kinect Sensor with my Xbox 360 since I don't own an Xbox 360:)
Measure depth. And capture 4-channel audio with spatial location and echo cancellation (unconfirmed but likely). It also moves up and down and has an accelerometer. People are mostly interested in the depth thing, though.
What the Kinect does have is anti-cloning. The Kinect cryptographically authenticates itself to the 360 (but not the other way around, as far as I can tell). In other words, it should be very hard to clone, but this doesn't affect efforts to use it outside of the original Xbox platform.
It seems to me like the people in charge of those Microsoft PR statements don't really know what they're talking about. Sure, there's some "security" around the Kinect (in the general sense of anti-cloning and associated Xbox updates), but as far as I can tell, no effort has been made to prevent DIY use like this. Getting it to work was comparable to getting any other proprietary USB device to work: an exercise in reverse engineering and traffic replaying, but there were no deliberate obstacles along the way.
The PS Eye is just a webcam (OV534). The Kinect is a lot more interesting. It might actually be easier to interface, if it has more on-board processing and thus relies less on driver functionality (e.g. auto exposure).
Personally, if I can borrow a 360 and either borrow a USB analyzer or use some stuff I have as a crappy USB analyzer, and if I can get a Kinect tomorrow when it launches in the EU, I'll give it a shot.
Secure login doesn't matter. You need secure everything, or people can just steal your session cookie. That is almost as bad as having your login stolen.
I must admit that I haven't performed the mathematical calculations to fully grasp the mechanics involved, but I don't think I was that far off with my explanation.
This is correct, but not for the reason you think. The vehicle is not moving forward because of torque applied to the wheels but solely due to aerodynamic forces. In fact, the force at the wheels opposes vehicle motion.
What you say is, of course, correct, and I made reference to that fact when I mentioned that you brake the vehicle (oppose its motion) by drawing energy from the wheels. That energy didn't come from nowhere, it came from the wind. At no point did I claim that the vehicle is powered by torque applied to the wheels (in fact, I said this is not the case).
If the vehicle is moving at wind speed the propeller is spinning so there are fairly significant aerodynamic forces acting on it. The force on the propeller is most certainly not zero.
That is correct for the propeller blades when the propeller is in motion. My reference was to the fact that the force applied to the propeller as an abstract static component is zero from the vehicle frame of reference, when moving at wind speed. Sure, the propeller can spin (and it must if the vehicle is moving and it is mechanically linked to the wheels), but it can only be an energy sink at that point, not an energy source, as there is no external air motion relative to its mounting point. In fact, with the hypothetical (incorrect) configuration with the propeller driving the wheels (which is what I was referring to when I made that statement), the propeller would be blowing air forwards, actively impeding vehicle motion.
All the energy in the system must come from the wind; there is no energy in the wheels that can be transferred to the fan.
There is no energy in the wheels, but there is energy being transferred through the wheels. Again, I was contemplating the portion of the system involving the propeller and the wheels and the mechanical link between them. The energy in this system is being transferred from the wheels, through the mechanical link, to the propeller. The energy being drawn through the wheels comes from the vehicle's kinetic energy (thus, opposing vehicle motion). This kinetic energy, in turn, was provided by the aerodynamic interaction of the propeller with the wind (and, to a lesser extent, by the body of the car acting as a sail, but only before achieving wind speed). It all boils down to energy from the wind, of course. The wind is what supplies the continuous flow of energy to keep the system in motion at a stable velocity.
In terms of force, which may be a bit more accurate, the wind exerts a force on the propeller. This force is transferred to the body of the vehicle, accelerating it. Through the action of the wheels, this force is also coupled into torque at the axle, which is transferred to the propeller. This force acts against the wind, increasing the overall force acting on the vehicle.
I see what you're saying, and I agree that an analysis of the kinematics of the system as a whole is the only way to truly explain its behavior with mathematical rigor, and how it achieves a steady state at a velocity exceeding that of the wind, while still drawing energy exclusively from the wind (as that is the only energy source). However, I think my broken down explanation is sufficient to make people understand the core of the idea to enough of an extent that they grasp how it is, in fact, physically possible, if counterintuitive.
I wonder if you can do the same thing with water. If I'm shooting the rapids in a wave-powered boat, can the boat go faster than the water is moving?
Nope, because the boat cannot harness the power of the flowing water (to do anything but simply move with it) without attaching itself to some kind of ground reference (this is what the wheels in a DWFTTW vehicle accomplish). Well, except using the air (hopefully not moving at the same speed and direction as the water), but that's a little far-fetched. It would also work if you could somehow extend a wheel to solid ground or the bottom of the water body, but that's also not very practical.
It should, however, be theoretically possible to accomplish DWFTTW on a sailboat (unrelated to sailboats' ability to travel faster than the wind when not directly downwind), but it might not be very practical due to the different friction characteristics of a boat on water vs. a car on wheels.
You can only use it to change your velocity in the direction of the movement of that medium.
No, you can use it to change your velocity in any direction. It's easier to understand if you think about solid objects. Let's say you have a long open truck with a small vehicle on the back, and the truck is advancing on a highway. Now let's say you connect the wheels of the small vehicle, through an axle and some gears, to a wheel that you then lower onto the highway. The small vehicle will move forwards on the truck (assuming you got your gearing right), and therefore move faster than the truck, relative to the ground.
The same principle applies when the truck is the wind, except the system is less efficient.
Well said. I think it should be possible to gain some amount of velocity greater than wind speed on a sailboat with an added fan connected to an underwater turbine, but I'm not sure if the fractional speed gained will be useful. It would be a very cool demo to try, though, and even achieving 5% over wind speed would be very interesting.
I think the main problem with a boat is that you have a massive amount of friction with the ground (the water), while on a car the axle friction of the wheels can be made very small. On a boat, you need a large sail to extract a large amount of energy from the wind to overcome this friction and achieve a significant fraction of the speed of the wind, while a lightweight ground vehicle with a small sail can easily achieve a speed very close to that of the wind. On a boat, the friction with the water is hard to direct towards some kind of turbine and not towards the hull of the boat, while on a car you can easily use wheel motion almost exclusively to turn the fan (fully static friction between the wheel and ground), expending a relatively small amount of the energy as friction on the axle. I think this might very significantly undermine the ability to "port" this trick to a boat. I hope someone proves me wrong, though:)
So while the vehicle might be traveling faster than the wind in burst, it won't get you any place faster than the next wind powered vehicle.
. The vehicle accelerates to a a speed faster than the wind, then stays at that speed forever (as long as the speed of the wind is constant) and does not oscillate. It really will get you to your destination faster than e.g. a balloon traveling at precisely the speed of the wind.
There is a feedback loop, but it works like this: there is a wind velocity X, and a stable velocity Y for said X, where Y>X (for a properly designed vehicle using this technique). If the velocity momentarily exceeds Y, the friction losses of the wheels will be greater than the gain in push from the fan, and the car will slow down. If the velocity momentarily drops below Y, the friction losses of the wheels will be lower than the push from the fan, and the car will accelerate forward. It stabilizes at Y, faster than X. The feedback loop keeps it at that stable Y.
It'll slow down and stop. The energy is extracted from the difference in motion between the wind and the ground. No such difference, and the car degenerates into a simple energy feedback loop (i.e. a typical attempt to create a perpetual motion machine) where the wheels drive the propeller which pushes the car forwards. Since the system is (of course) not 100% efficient, it eventually stops.
The cool fact is that, with wind, this energy loss is offset and the system can usefully generate additional thrust, which is why it works. This is also why it doesn't accelerate to an infinite speed: the faster it goes, the more insignificant the wind's speed becomes relative to the vehicle's ground speed, and, as with no wind, the system (obviously) cannot generate energy out of nowhere.
One way to look at it is that the car always travels at a fixed multiple of the wind's speed. This isn't true in practice due to the varying efficiency of the system, but it would be true if you had perfectly static friction with the wind (the multiple would be a function of the gear ratio between the fan and the wheels). In reality, it always travels at a variable multiple of the wind's speed (but still a multiple). Wind speed = 0, car speed = 0.
It's simple: the vehicle must be able to move forwards faster than the wind forever, as long as the wind keeps blowing. In other words, the energy stored in the moving parts must not decrease and eventually cause it to stop working. Or in yet other words: the system must achieve a steady state where energy is flowing in and out at a constant rate, while traveling faster than the wind.
For a race where time matters, energy input initially into the system is relevant. However, for the purposes of proving that DWFTTW is possible, it isn't. Any amount of energy added initially will by necessity be dissipated in the friction losses of the system - you can't run a car forever on a fixed amount of energy. If it can, in fact, run forever on a steady wind, then you can discount any initially applied or stored energy, and conclude that it is being powered solely by the wind. If it does that while going faster than the wind, then you can conclude that DWFTTW is possible.
there is no differential to be stored or used in any fashion
Yes there is: the wheels are rotating. If the cart were a balloon, you'd be correct. However, the cart has contact with the ground, and can extract energy from that interface. It uses that energy to rotate the fan, which increases the apparent wind speed on the fan's blades and, thus, propels the cart forwards faster than the external wind.
Yes, these carts do in fact work when they are traveling at precisely the same direction as the wind, and can outrun the wind in every sense of the word. It's very counterintuitive, but once you understand the mechanics it makes perfect sense and doesn't violate any laws of physics.
On a treadmill, if the vehicle is moving forward (relative to the observer, not the treadmill belt), then it is moving faster than the wind (which is moving at velocity zero relative to the observer). It is simply a change of frame of reference. If you place the observer on the treadmill's belt, then the wind is blowing forwards as fast as the outside world is moving forwards, and the vehicle is moving forwards faster than that. On the flip side, if you take the real-world DWFTTW vehicle example, and place the observer on a balloon moving with the wind, then (just as in the treadmill scenario) the wind is moving at zero velocity relative to you, the ground is moving backwards (just like a giant treadmill), and the vehicle is moving forwards faster than you (just like in the treadmill example the car moves forwards relative to an outside observer, even though the treadmill moves backwards).
To answer the GP, see my post above. Everyone (including myself at first) immediately assumes this is a turbine-powered car using a wind turbine to drive the wheels. That's backwards, it's a sailcar (simply pushed by the wind) which in addition to that uses the wheels as generators to drive a fan (not a turbine) to push air backwards and increase thrust, thus actually achieving faster than wind speed.
Nope, you've got it backwards, the GP got it right, and this is absolutely the key to understanding how this works.
The car isn't using the propeller as a turbine as a source of energy to power the wheels. That, indeed, would be impossible, because once you reach wind speed the force exerted on the propeller is zero.
Instead, it works the other way around, as a fan to push air backwards and accelerate the car. The energy is transfered from the wheels to the fan.
Assume that, to begin with, the car is moving at wind speed. The wheels are spinning (because the car is moving) and you can use that energy (i.e. brake the car) to push the propeller. The propeller blows air backwards, which propels the car forwards. If your mechanism is efficient enough, that push more than counteracts the braking action on the wheels and the car actually accelerates forwards. As it accelerates, the efficiency drops and it eventually stabilizes at some speed, faster than the wind.
Now everyone is shouting "Perpetual motion! You're producing more energy with the fan than you're getting out of the wheels!". Nope. That's the final bit. Let's say that wind speed is 10km/h. If the car is moving at 11km/h (faster than the wind), then the motion on the wheels relative to the ground is 11km/h. However, the fan only has to push air backwards at 1km/h, as the wind is doing the rest and providing the base 10km/h of forward motion. This difference in velocity is what offsets the inevitable energy losses: the ground speed is whatever you're generating with the fan plus the velocity of the wind "for free". This "free velocity" goes down (as a fraction of total velocity) as you accelerate, until it matches the (in)efficiency of the system (energy loss), and this is the stable velocity that the car achieves, faster than the wind.
This really isn't an issue with perpetual motion. It's easy to see that you could use a stationary turbine to generate (say, electric) power from the wind, and then use that power to accelerate a car (say, powered by a laser, so it is not tethered) in a different (windless) location faster than the original wind. Output velocity can be greater than input velocity. The difficulty lies in grasping the interesting mechanics and interactions of the downwind-faster-than-the-wind car uses to achieve this within the original wind itself. It's a mechanics puzzle, not an energy conservation puzzle. Another way to look at it is that the energy lies in the difference between the velocity of the wind and the ground, and the car always has access to both of these moving entities via friction (friction with the wind, and friction of the wheels with the ground), and thus can harness that power regardless of what its own velocity is.
UEFI is extremely common. Modern laptop makers use it as a way to have a modern BIOS (e.g. InsydeH2O) instead of the horrible cesspool of 16-bit code that are traditional BIOSes. At least Acer and Sony seem to be using this kind of setup for all of their recent laptops for a few years now, and I'm pretty sure quite a few other manufacturers are doing the same.
Unfortunately, most of the time the EFI features are completely inaccessible to the user and OS. They just add in the usual BIOS emulation layer, the boot process is designed to resemble a ye olde BIOS, the Setup menu is modeled after a ye olde BIOS, EFI services are unavailable, there's no EFI console or boot from EFI media. Sadly, the goal seems to make it easier for them to make the BIOS, not to make it more useful to end users.
They didn't leave Other OS out to cut the cost, as Linux has been proven to run on the Slim pretty much exactly the same way as it does on older consoles. It was deliberately disabled because they felt like it; there is no good technical reason.
If you short the port, the internal circuitry turns off the power.
Unless you're using a powered no-name chinese hub (or many brand name ones that are just rebranded chinese hubs). In that case, the chance of the hub having current limiting capability is virtually 0. Results vary from the adapter handling it, through it crapping out, physically melting or catching on fire, to it shorting out to mains and taking your motherboard with it.
Be very afraid of powered chinese hubs. I've yet to find one that even has the required diode to avoid sending power back from the adapter into the host PC. Unpowered ones are mostly OK, as then any short will just propagate to the host and it will shut off the power.
Slashdot Mirror
A very important bit of processing (depth calculation) is in the Kinect. The depth camera sees a 1280x960 image of IR dots which is turned into a 640x480 depth reconstruction. This is criticial and quite complex to achieve. The kinect would be near useless if they would have moved this bit of processing to the Xbox. Instead, even though all the skeletal tracking stuff is still in the console, it's still extremely useful for all kinds of computer vision research.
Quite honestly, I don't have much experience with autotools. There are two reasons: what little I've seen looks, at first glance, as a nightmare, and, as a user, the experience is horrible. Specifically, autotools is slow . These days I spend more time ./configuring than I do actually compiling, especially with distcc (./configure not being parallelizable). Even worse, sometimes I need to rebuild all of the scripts due to some patch, and that adds even more time to an already ridiculously inefficient process. I mean, seriously, why do I need to check for a C compiler, determine the maximum length of commandline arguments, and figure out if I have 20 system headers and 30 libc functions every time I want to compile a package?
Meanwhile, CMake is a hell of a lot faster, uses a more modern language, and can integrate better with other build environments. I've used CMake for a couple of projects and, although the language does have its quirks, it's mostly been smooth sailing. Where I don't use/need CMake, I use simple Makefiles.
So no, I'm not in a position of familiarity with both systems to be able to do a detailed objective comparison as a developer, but as a user I can clearly say CMake is much superior (at least the way it is used by actual projects), and as a developer I can at least say CMake is nice. Several large projects have migrated from autotools to CMake, and I bet they had a good reason.
Meanwhile, most small projects using autotools only appear to be using them because "it's what everyone else uses" and don't really understand them. Maybe autotools is great if you're an autotools guru, but it's still slow, and most people aren't going to invest the time to properly learn a system based on arcane tools. As far as I'm concerned, it's the CVS of build systems - sure, it kind of works works, but honestly, I'd rather either use a modern DVCS or stick with tarballs and patches (bare Makefiles).
cmake is built on OS tools, including GNU make in the case of Linux. What you're thinking of is the use of cmake over GNU autotools. And we're all happy for it.
The GNU Compiler Collection isn't going anywhere (though competition from LLVM is good and welcome), but the sooner Autotools dies, the better.
The signal would be stronger (well, except for the walls of the ISS), but most consumer GPS chipsets are utterly confused at high altitudes and high ground speeds. No real reason it couldn't be made to work given suitable GPS firmware, but it won't work out of the box.
This is a somewhat different thing from what Johnny Lee did, though. Johnny took existing Wiimote driver code and used it to do some very cool things with the data, such as his famous head tracking demonstration. He didn't figure out the actual communications protocol, though (in fact, I did a lot of the early Wiimote reverse engineering hacks too; I guess I have a thing for wacky game controllers!).
Unfortunately for us engineers and low-level hackers, the people actually finding practical algorithms and cool uses for these devices tend to get more attention than the people hacking the low-level details ;). I'm genuinely excited to see what computer vision experts can do with the raw Kinect data, though (I personally can't do much more than apply a cheap heat map to the data like I did in my video).
The final device still does a ridiculous amount of processing onboard, compared to just about every other peripheral out there. In order to get the depth map, it has to analyze the IR picture (which is quite different from a depth map) and extract contour and depth info from the density of the IR point cloud. This is being done in the PrimeSense SoC chip.
There is also a Marvell SoC chip in charge of audio processing and echo cancellation. I believe it might also be responsible for triangulation of the audio source.
The processing to get gesture data and do voice recognition is software, but don't underestimate the amount of processing going on in the device just to get the depth map and echo-canceled cooked audio.
The box of my Kinect actually said, and I quote: Requires acceptance of software license agreement available in manual and at: www.xbox.com/sla. You accept by using the Kinect Sensor and your Xbox 360.
It's a good thing I never used my Kinect Sensor with my Xbox 360 since I don't own an Xbox 360 :)
Measure depth. And capture 4-channel audio with spatial location and echo cancellation (unconfirmed but likely). It also moves up and down and has an accelerometer. People are mostly interested in the depth thing, though.
What the Kinect does have is anti-cloning. The Kinect cryptographically authenticates itself to the 360 (but not the other way around, as far as I can tell). In other words, it should be very hard to clone, but this doesn't affect efforts to use it outside of the original Xbox platform.
It seems to me like the people in charge of those Microsoft PR statements don't really know what they're talking about. Sure, there's some "security" around the Kinect (in the general sense of anti-cloning and associated Xbox updates), but as far as I can tell, no effort has been made to prevent DIY use like this. Getting it to work was comparable to getting any other proprietary USB device to work: an exercise in reverse engineering and traffic replaying, but there were no deliberate obstacles along the way.
The PS Eye is just a webcam (OV534). The Kinect is a lot more interesting. It might actually be easier to interface, if it has more on-board processing and thus relies less on driver functionality (e.g. auto exposure).
Personally, if I can borrow a 360 and either borrow a USB analyzer or use some stuff I have as a crappy USB analyzer, and if I can get a Kinect tomorrow when it launches in the EU, I'll give it a shot.
Secure login doesn't matter. You need secure everything, or people can just steal your session cookie. That is almost as bad as having your login stolen.
I must admit that I haven't performed the mathematical calculations to fully grasp the mechanics involved, but I don't think I was that far off with my explanation.
What you say is, of course, correct, and I made reference to that fact when I mentioned that you brake the vehicle (oppose its motion) by drawing energy from the wheels. That energy didn't come from nowhere, it came from the wind. At no point did I claim that the vehicle is powered by torque applied to the wheels (in fact, I said this is not the case).
That is correct for the propeller blades when the propeller is in motion. My reference was to the fact that the force applied to the propeller as an abstract static component is zero from the vehicle frame of reference, when moving at wind speed. Sure, the propeller can spin (and it must if the vehicle is moving and it is mechanically linked to the wheels), but it can only be an energy sink at that point, not an energy source, as there is no external air motion relative to its mounting point. In fact, with the hypothetical (incorrect) configuration with the propeller driving the wheels (which is what I was referring to when I made that statement), the propeller would be blowing air forwards, actively impeding vehicle motion.
There is no energy in the wheels, but there is energy being transferred through the wheels. Again, I was contemplating the portion of the system involving the propeller and the wheels and the mechanical link between them. The energy in this system is being transferred from the wheels, through the mechanical link, to the propeller. The energy being drawn through the wheels comes from the vehicle's kinetic energy (thus, opposing vehicle motion). This kinetic energy, in turn, was provided by the aerodynamic interaction of the propeller with the wind (and, to a lesser extent, by the body of the car acting as a sail, but only before achieving wind speed). It all boils down to energy from the wind, of course. The wind is what supplies the continuous flow of energy to keep the system in motion at a stable velocity.
In terms of force, which may be a bit more accurate, the wind exerts a force on the propeller. This force is transferred to the body of the vehicle, accelerating it. Through the action of the wheels, this force is also coupled into torque at the axle, which is transferred to the propeller. This force acts against the wind, increasing the overall force acting on the vehicle.
I see what you're saying, and I agree that an analysis of the kinematics of the system as a whole is the only way to truly explain its behavior with mathematical rigor, and how it achieves a steady state at a velocity exceeding that of the wind, while still drawing energy exclusively from the wind (as that is the only energy source). However, I think my broken down explanation is sufficient to make people understand the core of the idea to enough of an extent that they grasp how it is, in fact, physically possible, if counterintuitive.
Nope, because the boat cannot harness the power of the flowing water (to do anything but simply move with it) without attaching itself to some kind of ground reference (this is what the wheels in a DWFTTW vehicle accomplish). Well, except using the air (hopefully not moving at the same speed and direction as the water), but that's a little far-fetched. It would also work if you could somehow extend a wheel to solid ground or the bottom of the water body, but that's also not very practical.
It should, however, be theoretically possible to accomplish DWFTTW on a sailboat (unrelated to sailboats' ability to travel faster than the wind when not directly downwind), but it might not be very practical due to the different friction characteristics of a boat on water vs. a car on wheels.
No, you can use it to change your velocity in any direction. It's easier to understand if you think about solid objects. Let's say you have a long open truck with a small vehicle on the back, and the truck is advancing on a highway. Now let's say you connect the wheels of the small vehicle, through an axle and some gears, to a wheel that you then lower onto the highway. The small vehicle will move forwards on the truck (assuming you got your gearing right), and therefore move faster than the truck, relative to the ground.
The same principle applies when the truck is the wind, except the system is less efficient.
Well said. I think it should be possible to gain some amount of velocity greater than wind speed on a sailboat with an added fan connected to an underwater turbine, but I'm not sure if the fractional speed gained will be useful. It would be a very cool demo to try, though, and even achieving 5% over wind speed would be very interesting.
I think the main problem with a boat is that you have a massive amount of friction with the ground (the water), while on a car the axle friction of the wheels can be made very small. On a boat, you need a large sail to extract a large amount of energy from the wind to overcome this friction and achieve a significant fraction of the speed of the wind, while a lightweight ground vehicle with a small sail can easily achieve a speed very close to that of the wind. On a boat, the friction with the water is hard to direct towards some kind of turbine and not towards the hull of the boat, while on a car you can easily use wheel motion almost exclusively to turn the fan (fully static friction between the wheel and ground), expending a relatively small amount of the energy as friction on the axle. I think this might very significantly undermine the ability to "port" this trick to a boat. I hope someone proves me wrong, though :)
.
The vehicle accelerates to a a speed faster than the wind, then stays at that speed forever (as long as the speed of the wind is constant) and does not oscillate. It really will get you to your destination faster than e.g. a balloon traveling at precisely the speed of the wind.
There is a feedback loop, but it works like this: there is a wind velocity X, and a stable velocity Y for said X, where Y>X (for a properly designed vehicle using this technique). If the velocity momentarily exceeds Y, the friction losses of the wheels will be greater than the gain in push from the fan, and the car will slow down. If the velocity momentarily drops below Y, the friction losses of the wheels will be lower than the push from the fan, and the car will accelerate forward. It stabilizes at Y, faster than X. The feedback loop keeps it at that stable Y.
It'll slow down and stop. The energy is extracted from the difference in motion between the wind and the ground. No such difference, and the car degenerates into a simple energy feedback loop (i.e. a typical attempt to create a perpetual motion machine) where the wheels drive the propeller which pushes the car forwards. Since the system is (of course) not 100% efficient, it eventually stops.
The cool fact is that, with wind, this energy loss is offset and the system can usefully generate additional thrust, which is why it works. This is also why it doesn't accelerate to an infinite speed: the faster it goes, the more insignificant the wind's speed becomes relative to the vehicle's ground speed, and, as with no wind, the system (obviously) cannot generate energy out of nowhere.
One way to look at it is that the car always travels at a fixed multiple of the wind's speed. This isn't true in practice due to the varying efficiency of the system, but it would be true if you had perfectly static friction with the wind (the multiple would be a function of the gear ratio between the fan and the wheels). In reality, it always travels at a variable multiple of the wind's speed (but still a multiple). Wind speed = 0, car speed = 0.
It's simple: the vehicle must be able to move forwards faster than the wind forever, as long as the wind keeps blowing. In other words, the energy stored in the moving parts must not decrease and eventually cause it to stop working. Or in yet other words: the system must achieve a steady state where energy is flowing in and out at a constant rate, while traveling faster than the wind.
For a race where time matters, energy input initially into the system is relevant. However, for the purposes of proving that DWFTTW is possible, it isn't. Any amount of energy added initially will by necessity be dissipated in the friction losses of the system - you can't run a car forever on a fixed amount of energy. If it can, in fact, run forever on a steady wind, then you can discount any initially applied or stored energy, and conclude that it is being powered solely by the wind. If it does that while going faster than the wind, then you can conclude that DWFTTW is possible.
Yes there is: the wheels are rotating. If the cart were a balloon, you'd be correct. However, the cart has contact with the ground, and can extract energy from that interface. It uses that energy to rotate the fan, which increases the apparent wind speed on the fan's blades and, thus, propels the cart forwards faster than the external wind.
Yes, these carts do in fact work when they are traveling at precisely the same direction as the wind, and can outrun the wind in every sense of the word. It's very counterintuitive, but once you understand the mechanics it makes perfect sense and doesn't violate any laws of physics.
On a treadmill, if the vehicle is moving forward (relative to the observer, not the treadmill belt), then it is moving faster than the wind (which is moving at velocity zero relative to the observer). It is simply a change of frame of reference. If you place the observer on the treadmill's belt, then the wind is blowing forwards as fast as the outside world is moving forwards, and the vehicle is moving forwards faster than that. On the flip side, if you take the real-world DWFTTW vehicle example, and place the observer on a balloon moving with the wind, then (just as in the treadmill scenario) the wind is moving at zero velocity relative to you, the ground is moving backwards (just like a giant treadmill), and the vehicle is moving forwards faster than you (just like in the treadmill example the car moves forwards relative to an outside observer, even though the treadmill moves backwards).
To answer the GP, see my post above. Everyone (including myself at first) immediately assumes this is a turbine-powered car using a wind turbine to drive the wheels. That's backwards, it's a sailcar (simply pushed by the wind) which in addition to that uses the wheels as generators to drive a fan (not a turbine) to push air backwards and increase thrust, thus actually achieving faster than wind speed.
Nope, you've got it backwards, the GP got it right, and this is absolutely the key to understanding how this works.
The car isn't using the propeller as a turbine as a source of energy to power the wheels. That, indeed, would be impossible, because once you reach wind speed the force exerted on the propeller is zero.
Instead, it works the other way around, as a fan to push air backwards and accelerate the car. The energy is transfered from the wheels to the fan.
Assume that, to begin with, the car is moving at wind speed. The wheels are spinning (because the car is moving) and you can use that energy (i.e. brake the car) to push the propeller. The propeller blows air backwards, which propels the car forwards. If your mechanism is efficient enough, that push more than counteracts the braking action on the wheels and the car actually accelerates forwards. As it accelerates, the efficiency drops and it eventually stabilizes at some speed, faster than the wind.
Now everyone is shouting "Perpetual motion! You're producing more energy with the fan than you're getting out of the wheels!". Nope. That's the final bit. Let's say that wind speed is 10km/h. If the car is moving at 11km/h (faster than the wind), then the motion on the wheels relative to the ground is 11km/h. However, the fan only has to push air backwards at 1km/h, as the wind is doing the rest and providing the base 10km/h of forward motion. This difference in velocity is what offsets the inevitable energy losses: the ground speed is whatever you're generating with the fan plus the velocity of the wind "for free". This "free velocity" goes down (as a fraction of total velocity) as you accelerate, until it matches the (in)efficiency of the system (energy loss), and this is the stable velocity that the car achieves, faster than the wind.
This really isn't an issue with perpetual motion. It's easy to see that you could use a stationary turbine to generate (say, electric) power from the wind, and then use that power to accelerate a car (say, powered by a laser, so it is not tethered) in a different (windless) location faster than the original wind. Output velocity can be greater than input velocity. The difficulty lies in grasping the interesting mechanics and interactions of the downwind-faster-than-the-wind car uses to achieve this within the original wind itself. It's a mechanics puzzle, not an energy conservation puzzle. Another way to look at it is that the energy lies in the difference between the velocity of the wind and the ground, and the car always has access to both of these moving entities via friction (friction with the wind, and friction of the wheels with the ground), and thus can harness that power regardless of what its own velocity is.
UEFI is extremely common. Modern laptop makers use it as a way to have a modern BIOS (e.g. InsydeH2O) instead of the horrible cesspool of 16-bit code that are traditional BIOSes. At least Acer and Sony seem to be using this kind of setup for all of their recent laptops for a few years now, and I'm pretty sure quite a few other manufacturers are doing the same.
Unfortunately, most of the time the EFI features are completely inaccessible to the user and OS. They just add in the usual BIOS emulation layer, the boot process is designed to resemble a ye olde BIOS, the Setup menu is modeled after a ye olde BIOS, EFI services are unavailable, there's no EFI console or boot from EFI media. Sadly, the goal seems to make it easier for them to make the BIOS, not to make it more useful to end users.
They didn't leave Other OS out to cut the cost, as Linux has been proven to run on the Slim pretty much exactly the same way as it does on older consoles. It was deliberately disabled because they felt like it; there is no good technical reason.
Unless you're using a powered no-name chinese hub (or many brand name ones that are just rebranded chinese hubs). In that case, the chance of the hub having current limiting capability is virtually 0. Results vary from the adapter handling it, through it crapping out, physically melting or catching on fire, to it shorting out to mains and taking your motherboard with it.
Be very afraid of powered chinese hubs. I've yet to find one that even has the required diode to avoid sending power back from the adapter into the host PC. Unpowered ones are mostly OK, as then any short will just propagate to the host and it will shut off the power.
None of those "plugs" actually say that, and none of them actually meet the USB spec. They just happen to work... most of the time.