It is often a mistake to equate word count with depth of feeling.
Second Life® is a registered trademark of Linden Lab.
Second Life® is a registered trademark of Linden Lab.
Links
Second Life
New World Notes
Second Life Herald
Who Am I?
SkyPod 4 @ Louise
SkyPod 4 Twitter Log
Last 10 Entries
Going for a Walk
Flash, Bang
Virtual Solipsism
Invisiprim
Minor Progress
Wired
Live from SL
Banshee
GoD Beta
Simplification
Archives
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
May 2008
August 2008
September 2008
December 2008
July 2009
September 2009
February 2010
March 2010
July 2011
April 2012
July 2012
Sunday, August 20, 2006
A More Scenic Walk
Well, this project has officially gotten out of hand. I can always tell that this has happened when it looks like R2D2 threw up all over my office. As soon as I hit "publish" here, I think I'm going to spend the next half hour or so bundling and organizing wires.
I went ahead and added a keyboard tray to my setup. It's just a sheet of masonite pegboard, attached to the legs of the pushup stands I'd already added previously. Those pushup stands have turned out to be well worth the dollar I spent on them at a local garage sale a while back. They've formed the framework for most of the modifications and additions I've made for this project. The keyboard now fits quite nicely in the unused space between the handlebars. Unfortunately, there was no room for a mouse, so I expect I'll have to either make do without, or spring for a keyboard with a trackball. I think I'll wait and see how much I actually use this contraption before I decide.
I also added a kill switch for the reed switch attached to the treadmill pulley (described previously). That's the little black paddle switch and bundle of electrical tape attached (with foam tape and zip tie) to the control column at center. Now I can easily cut the signal to the forward direction contacts without having to step off the treadmill and shut it down. This also keeps the contacts from being locked closed in the event that the treadmill pulley stops with the encoder magnet near the reed switch. It's not pretty, but it seems to work.
Finally, as you can see, I rigged up a spare 17" monitor in front of the treadmill. In order to get the right elevation, I stacked two wooden TV trays on top of each other, and did what I could to make them stable. This involved using a bungee cord to lash the lower tray to the frame of the treadmill, then taping the legs of the upper tray in place with duct tape. I also added some cross bracing on the upper tray using a length of PVC piping and a few zip ties (not shown in the picture- added after testing). It still wobbles a little bit, but it seems reasonably stable. I guess I'll have to see how long I can stand working/playing at my desk with the Monitor of Damocles hanging over my head.
On a related note, this morning (before installing the monitor and keyboard- used the monitor on my desk), I took my morning walk inside SL. It was actually kind of fun, or as fun as walking and sweating can be. I walked for half an hour and about 1.2 miles, as usual, at an average speed of around 2.4 miles per hour (1.1 m/s). Yeah, I know, that's not much of a workout. But I only started three weeks ago. Given my sedentary lifestyle and somewhat cetacean physique, that's quite enough for me.
I started my walk at the beginning of the road on the east edge of Abitibi, and followed it roughly westward (give or take some meandering) to Whiskey, a trip of approximately 6.3 kilometers. According to the Debug menu velocity HUD, I was moving at about 3.5 m/s (7.8 MPH). (This is a little faster than the normal walking speed of 3.0 m/s. Apparently tapping the forward key squeezes more speed out of a walk than holding it down. I have no good explanation for that. Perhaps the rig is signaling faster than the keyboard repeat rate?) As you can see, there's a bit of a disparity between SL walking speed and my walking speed. According to Wikipedia, average human walking speed is about 1.0 to 1.5 m/s (2.2 to 3.4 MPH). Avatars appear to walk two to three times faster than their RL human counterparts.
For reference, avatars run at a bit under 5 m/s (11.2 MPH) (and fly at about 15 m/s, or 33.6 MPH). World record setting sprinters have been clocked at 10.3 m/s (22.8 MPH), while accomplished long distance runners can manage a 4 minute mile (15 MPH, or 6.7 m/s). It seems like SL avatar running is a little more realistic, at least for normal human speeds.
The upshot of all this is that SL avatars walk too fast. (And I'll bet that's the first time anyone's ever said that.) That's fine for scenic walks in the country, or on the back roads of the grid, but I think I might be obligated to script some kind of limiter attachment to hold my avatar's speed down to realistic levels when the walking matters. It seems a bit like cheating.
Addendum, 9/29/06
This project was featured on Make: blog! Now, a bit over a month later, I'm still using the treadmill and interface more-or-less daily (four or five times a week, typically). Kind of a nifty way to see SL, anyway, and it helps counter some of the intrinsic feeling of futility that goes with walking on a treadmill. I'm still not getting anywhere, but at least my avatar is.
Posted by Moriash Moreau at 5:09 PM
Comments:
Return to Main Page
Moriash, I've posted about your contraption on SecondLifeInsider.com; I hope you don't mind the publicity! If there's anything you think the readers should know, please feel free to comment. THanks!
Wooo, neat project! I was actually working on something similar, though I am now without treadmill since I moved. :(
I recommend using a vehicle that responds to chat commands or something similar in order to set movement speed. That's the only way you're going to get simulated analog input.
What's the resolution on your encoder? I was just using a reflectance sensor and white tape on the tread, heh. Low-fi, but it did the job.
I recommend using a vehicle that responds to chat commands or something similar in order to set movement speed. That's the only way you're going to get simulated analog input.
What's the resolution on your encoder? I was just using a reflectance sensor and white tape on the tread, heh. Low-fi, but it did the job.
# Posted by 
: 9/11/2006 1:13 PM
: 9/11/2006 1:13 PM
Ah, yeah, I remember seeing mention of trying your rig with a treadmill in your bicycle article. Speaking of, is your article on using libSL in place of keyhooks for control comms up somewhere? I checked on the Nonpolynomial Labs and Slashdong sites. Would it be elsewhere? You mentioned it in a previous comment, and I've been eagerly waiting to
look at it puzzledly :-)
Honestly, my encoder resolution is far too high for the project, if I understand what you're asking. Check for a description and pictures of the rig: http://moriash.blogspot.com/2006/08/going-for-walk.html My treadmill happened to already have a magnet in a drive pulley (it uses a Hall effect sensor for speed calcs), so I was able to simply add a reed switch in the general vicinity. (I actually considered using a patch of conductive foil tape directly on walking belt and a couple of contactors that'd drag over it, but that would be subject to wear and riddled with all sorts problems from the get-go.) So, I get one signal (closed reed switch) per rotation. I've been pleased with the performance of the reed switch, incidentally. I expected it to succumb to fatigue, but it's gone a few dozen miles now with no problems. I guess sometimes the low-tech solution will do the trick.
Just did some measuring. The walking belt has a circumference of 96 inches. The front roller (which is directly connected to the pulley with the magnet) has a circumference of 4.7 inches, and will deliver one signal per revolution. That works out to about 2.5 signals per foot walked. At my typical walking speed of about 2.4 MPH, that comes out to 8.8 signals per second. Quite a bit more than I really need.
I suppose I could switch to some kind of scheme that'd trigger off the walking belt (there must be a better term for that), but honestly it's just not necessary. It's a motorized treadmill that operates at a constant speed during use (give or take 0.2 MPH). As such, my speed in game (even if I limited it to normal walking speed) wouldn't vary enough to worry about. For normal walks, a simple On/Off switch to hold down the forward key would do the job. I can just tell any vehicle script I'm walking at 2.4 MPH directly and save some real-time number juggling.
But, yeah, I'll have to come up with something better when I do my version of the man-powered bicycle (as you've already done). Its speed will vary in a significant fashion. I was kind of kicking around coming up with some kind of vehicle or attachment to measure the time between signals and back out the speed (the radius of the wheel is known, so I can get linear speed from RPM). But, yeah, if I go with something more sophisticated and use a full controller and an outside program to send control signals, I'll have to have some method of communicating speed to the game, as you say. At this point, I'm still leaning toward the basic keypad interface, though. I agree it's not as sophisticated, and has
innate focus issues, but it's much easier to work with, especially for simple tinkering.
look at it puzzledly :-)
Honestly, my encoder resolution is far too high for the project, if I understand what you're asking. Check for a description and pictures of the rig: http://moriash.blogspot.com/2006/08/going-for-walk.html My treadmill happened to already have a magnet in a drive pulley (it uses a Hall effect sensor for speed calcs), so I was able to simply add a reed switch in the general vicinity. (I actually considered using a patch of conductive foil tape directly on walking belt and a couple of contactors that'd drag over it, but that would be subject to wear and riddled with all sorts problems from the get-go.) So, I get one signal (closed reed switch) per rotation. I've been pleased with the performance of the reed switch, incidentally. I expected it to succumb to fatigue, but it's gone a few dozen miles now with no problems. I guess sometimes the low-tech solution will do the trick.
Just did some measuring. The walking belt has a circumference of 96 inches. The front roller (which is directly connected to the pulley with the magnet) has a circumference of 4.7 inches, and will deliver one signal per revolution. That works out to about 2.5 signals per foot walked. At my typical walking speed of about 2.4 MPH, that comes out to 8.8 signals per second. Quite a bit more than I really need.
I suppose I could switch to some kind of scheme that'd trigger off the walking belt (there must be a better term for that), but honestly it's just not necessary. It's a motorized treadmill that operates at a constant speed during use (give or take 0.2 MPH). As such, my speed in game (even if I limited it to normal walking speed) wouldn't vary enough to worry about. For normal walks, a simple On/Off switch to hold down the forward key would do the job. I can just tell any vehicle script I'm walking at 2.4 MPH directly and save some real-time number juggling.
But, yeah, I'll have to come up with something better when I do my version of the man-powered bicycle (as you've already done). Its speed will vary in a significant fashion. I was kind of kicking around coming up with some kind of vehicle or attachment to measure the time between signals and back out the speed (the radius of the wheel is known, so I can get linear speed from RPM). But, yeah, if I go with something more sophisticated and use a full controller and an outside program to send control signals, I'll have to have some method of communicating speed to the game, as you say. At this point, I'm still leaning toward the basic keypad interface, though. I agree it's not as sophisticated, and has
innate focus issues, but it's much easier to work with, especially for simple tinkering.
Ah, yeah, I remember seeing mention of trying your rig with a treadmill in your bicycle article. Speaking of, is your article on using libSL in place of keyhooks for control comms up somewhere? I checked on the Nonpolynomial Labs and Slashdong sites. Would it be elsewhere? You mentioned it in a previous comment, and I've been eagerly waiting to
look at it puzzledly
That article doesn't exactly exist yet. I'm stupidly behind on the writing I'm supposed to be getting done, but I'm hopefully getting to the point where I can deal with that now. I'm posting the code to the trancevibe SL stuff tonight definitely, you can use that as a start, but it's really, really rough.
Honestly, my encoder resolution is far too high for the project, if I understand what you're asking.
Ok, the way you rigged up the encoder on your treadmill was the exact same method I used on my bike. However, where your's was much higher than need be, mine was much, much too low. Only getting 1 encoder tick per turn of the pedals was awful. I tried a few methods to increase that, but nothing I got decent results with, and now the bike is gone. *sigh*
I suppose I could switch to some kind of scheme that'd trigger off the walking belt (there must be a better term for that), but honestly it's just not necessary. It's a motorized treadmill that operates at a constant speed during use (give or take 0.2 MPH). As such, my speed in game (even if I limited it to normal walking speed) wouldn't vary enough to worry about. For normal walks, a simple On/Off switch to hold down the forward key would do the job. I can just tell any vehicle script I'm walking at 2.4 MPH directly and save some real-time number juggling.
Yup, that'd work just fine. That design issue was something I tried to figure out, but didn't have much luck with. There's really not much you can do to make a treadmill like that more immersive, and things like the FPS GameRunner (http://www.fpgamerunner.com/), while looking interesting, seem like a horrible idea to me (Just wait until something jumps out at you and you fall of the thing, heee).
I agree it's not as sophisticated, and has innate focus issues, but it's much easier to work with, especially for simple tinkering.
I'm not sure I follow on your point of keypad being easier to work with. Why don't you just have a uC translate the encoder ticks to serial and ship it over the serial port? It's something you can easily do in under 15 lines on an AVR chip, then you can pick up the serial and simulate keystrokes if you must, though doing chat injection in libsl will give you 10-15hz polling with movement vector scaling if you're using a vehicle that responds to chat. I'll try and put together some demo code for this, but I'll warn you that my track record on followthrough for stuff like this is less than stellar lately. x.X
look at it puzzledly
That article doesn't exactly exist yet. I'm stupidly behind on the writing I'm supposed to be getting done, but I'm hopefully getting to the point where I can deal with that now. I'm posting the code to the trancevibe SL stuff tonight definitely, you can use that as a start, but it's really, really rough.
Honestly, my encoder resolution is far too high for the project, if I understand what you're asking.
Ok, the way you rigged up the encoder on your treadmill was the exact same method I used on my bike. However, where your's was much higher than need be, mine was much, much too low. Only getting 1 encoder tick per turn of the pedals was awful. I tried a few methods to increase that, but nothing I got decent results with, and now the bike is gone. *sigh*
I suppose I could switch to some kind of scheme that'd trigger off the walking belt (there must be a better term for that), but honestly it's just not necessary. It's a motorized treadmill that operates at a constant speed during use (give or take 0.2 MPH). As such, my speed in game (even if I limited it to normal walking speed) wouldn't vary enough to worry about. For normal walks, a simple On/Off switch to hold down the forward key would do the job. I can just tell any vehicle script I'm walking at 2.4 MPH directly and save some real-time number juggling.
Yup, that'd work just fine. That design issue was something I tried to figure out, but didn't have much luck with. There's really not much you can do to make a treadmill like that more immersive, and things like the FPS GameRunner (http://www.fpgamerunner.com/), while looking interesting, seem like a horrible idea to me (Just wait until something jumps out at you and you fall of the thing, heee).
I agree it's not as sophisticated, and has innate focus issues, but it's much easier to work with, especially for simple tinkering.
I'm not sure I follow on your point of keypad being easier to work with. Why don't you just have a uC translate the encoder ticks to serial and ship it over the serial port? It's something you can easily do in under 15 lines on an AVR chip, then you can pick up the serial and simulate keystrokes if you must, though doing chat injection in libsl will give you 10-15hz polling with movement vector scaling if you're using a vehicle that responds to chat. I'll try and put together some demo code for this, but I'll warn you that my track record on followthrough for stuff like this is less than stellar lately. x.X
# Posted by : 9/12/2006 4:00 PM
: 9/12/2006 4:00 PM
Heh, as for the last bit, I'll tell you why: because I only understood about one word in three of what you just said. I should clarify that it's easier for me to work with. I'm operating at a very rudimentary level here, with very little previous digital electronics, coding (aside from LSL), or computer interface experience. I'm fairly handy with mechanics (I'm a mechanical engineer- very little comp. sci. or EE experience, though) and basic wiring, though. Soldering a few wires onto an existing electronic device that already works fairly well for most of what I want to do is sufficient for my needs, and is about all I understand ATM. I plan on digging deeper into it and doing more sophisticated projects, at some point, but for now wiring extra bits into the basic keyboard controls is sufficient. I've got a rather steep learning curve between me and any kind of serious controls scheme like you describe.
And toward that end, I'll definitely be poring over anything you write on the subject. It's helpful to have something specific to work toward when you're teaching yourself something like this.
That's handy to know, re: the encoder ticks on the bike. I had intended to use a single signal per revolution, but I hadn't really sat down and thought about the numbers (linear distance vs. speed vs. RPM) in detail. Fortunately, with the reed switches I've been using, it's an easy fix: just stick more magnets on the wheel!
And toward that end, I'll definitely be poring over anything you write on the subject. It's helpful to have something specific to work toward when you're teaching yourself something like this.
That's handy to know, re: the encoder ticks on the bike. I had intended to use a single signal per revolution, but I hadn't really sat down and thought about the numbers (linear distance vs. speed vs. RPM) in detail. Fortunately, with the reed switches I've been using, it's an easy fix: just stick more magnets on the wheel!
Just looked at the GameRunner. I kind of wonder about both its life and its ease of use. Most of the non-motorized treadmills I've used tended to bog down fairly easily, leaving you to draaag each step, instead of just walking. But, to be fair, I expect I weigh more than the design spec. I notice they don't list a recommended weight limit on the site.
This looks SO AWESOME. Cube Linden and Jerry aka SNOOP both directed me over here. I am looking for more ways to use my feet when in Second Life. What a great innovation, Moriash!
Post a Comment
Return to Main Page