Project Logs

Collapse

• Results from Lots of Testing and the Plan Going Forward

  finallyfunctional • 02/15/2021 at 04:36 • 0 comments

  I've tested and used the shoes a lot in the past 2 weeks. I was able to smooth out the motion of the shoes so that it feels really good to walk with them. I describe some of the algorithm changes I made to smooth out the motion here. I was able to walk around in a couple of games. However, there are some issues with the shoes and it looks like I'll need to make a new version. 

  Wear and Tear

  The biggest issue is wear and tear. In the last week I've had to make several repairs, or just take a portion of the shoe apart to re-align a gear. All the gears are showing wear and I've had to replace 1 of them yesterday because a tooth chipped. I broke part of the platform a couple days ago because I pushed on the metal rods too hard. One of the buttons on the platform also broke today and had to be replaced.

  I want a new more durable design with less parts to resolve some of these issues and to replace the buttons on the platform with capacitive sensors.

  Turning

  As you may have noticed in the video, I struggled a bit with turning. I believe adding an IMU will help resolve some of the issues and will later write a project log that goes into the algorithm changes I'm going to make once I add an IMU. But there are other issues with turning an IMU will not solve.

  I'm going to use X, Y, and Z axes to describe the issues and a few more later in the article. The X axis is forward, Y is sideways, and Z is up. 

  When I turn my foot about the Z axis quickly, I have a tendency to also tilt my foot about the X axis a bit. This causes the whole shoe to tilt about the X axis and cases the electronic box on the side to hit the ground.

  When turning, the point I need to turn around is behind me. Notice how the tethers connecting my safety harness to the ceiling hook go up behind my head. If I back up too much, the tethers hit me in the back of the head. So I need to stand ahead of the tethers and of the ceiling hook. The ceiling hook is my pivot point when turning, so I have to turn around a point that is behind me, making turning more difficult. Naturally, the ideal scenario is to have the pivot point directly above my head.

  Lastly, when I turn my foot, the wheels skid on the ground. The shoe is only capable of going forward and backward, so during turning the wheels are not helping and create resistance. I knew this would be an issue when I designed this version, and it's not that big of a deal for the walking I do in my videos. However, if I want to turn rapidly, like do 180 degree turns rapidly (imagine playing a fast paced shooter), the resistance becomes an issue. I bet that it will also be more of an issue if I use the shoes on carpet or a neoprene mat.

  Speed

  I attempted to increase the speed of the shoes past the walking I was doing in the video. Like when turning my foot rapidly, I seem to have a tendency to tilt my foot about the X axis the faster I try to walk with the VR shoes, causing the shoes to tilting and, again, the electronic box hits the ground.

  Solutions to Wear and Tear

  The biggest problem is wear and tear. I can't have the shoes breaking down after only a few weeks of use, especially if I ever want to sell them or recommend others build the VR shoes. I have several ideas for reducing wear and tear.

  First, I need eliminate the gears as much as possible. I currently have 12 or 13 gears per shoe. A gear train runs along the whole shoe. I need to replace these with a power transfer mechanism that reduces the part count and/or uses stronger materials. I could use a belt with pulleys or chain with sprockets. Both will require a tensioning mechanism. I could also try a coupling rod, like what trains use.

  I will update as many parts as I can to use flexible material, like TPU, instead of rigid material, like PETG. PETG can easily break if pulled too hard. A part made of TPU will just bend under strain, not snap. If I drop a PETG piece on the cement...

  Read more »

• Short Update on Smoothing Motion

  finallyfunctional • 02/11/2021 at 02:17 • 0 comments

  I'm working on smoothing the motion. See my previous project log if you want to know the details. 

  Walking is now pretty smooth and feels pretty good. Turning needs some work and I have some ideas to make it better, and I still need to add an IMU to each shoe.

• Smoother Motion

  finallyfunctional • 02/01/2021 at 00:21 • 0 comments

  This log will go over the ideas I am going to implement to make the motion for my VR shoes as smooth as possible. If you haven't already seen it, check out my walk in No Man's Sky with my VR shoes. The motion I have now is already pretty good, but as you'll read, it can get even better.

  
  

  Note that I will not be going over the return to center algorithm in this article. If you're wonder how the shoes know when to move, you can read about the algorithm here. Essentially, the shoe going forward tells the other shoe to go backwards at the same speed. This article will be going over the additional actions I'll take to smooth the motion. In an ideal world the return to center algorithm on its own would be perfect, but latency for communication between the shoes and start-up time for the motors means that additional actions need to be taken.

  The first action I have already taken is to update that algorithm so that a single stride can only have one speed. Previously, as I would bring my foot forward, the speed at which I did so would vary a bit. This caused the other shoe to try to move backwards and vary it's speed similarly. The variable speed made the motion feel choppy and hard to balance. So, I updated the code so that once the shoe starts moving backwards, it stays at one speed to create a smooth motion. Drift can be compensated by the next stride. In the future I may update the code so that a single stride as one speed or can only accelerate or deaccelerate from there, but I'm not going to do that for now.

  That is the action I have already taken. The rest of the things are actions I plan on implementing.

  Part of the motion algorithm can be described using a state machine diagram.

  The shoes can be in the following states.

  * Stopped - The shoes are not moving.
  * First Step - The user has started to move. The first step is being taken.
  * Walking - The user is beyond the first step and is walking.

  I will have different code for going from stopped to the first step, and from going to the first step to walking. Stopped to the first step will prioritize a smooth, slower startup. The shoes will more gradually gain speed in the first step to make going from stopped to walking feel smoother. Starting up the motors too fast when starting from 0 RPM will feel like a jolt of speed and may through the user's balance off.

  Going from the first step to walking will prioritize maintaining speed and eliminating drift. During walking, the shoes will start up faster. Since the user is already moving the jolts of speed that the motors provide will be less jarring.

  In addition to the state machine I've already shown, the shoes will be in different additional states depending on where they are in the stride. This state machine will apply when the shoes are in the walking state.

  The shoe will be in the following states.

  * Front of stride - The shoe is in front of the user and the user has just put is foot down.
  * Middle of stride - The shoe has been moved (by the motors) to the middle of the stride. The shoe is directly under the user or close to it.
  * Back of stride - The shoe is behind the user and the user is lifting his foot again to start another stride.

  These additional states will be used to increase the responsiveness of the shoes. As the user walks, the user is constantly alternating his legs back and forth. When the legs change direction there is a moment when the speed of the shoe will decelerate, be zero, then accelerate again. During this moment, according to my return to center algorithm, the shoe in front of the user is waiting until the other foot lifts up off the platform and starts to move forward. Once the other shoe has done that, it sends a message to the front shoe that it's good to start actuating the motor and moving backwards. All of this creates a delay.

  How can we get rid of the delay, or minimize it as much as possible? One option is for the front shoe to not wait for a signal from the back shoe. The front shoe will...

  Read more »

• The Return to Center Algorithm

  finallyfunctional • 01/31/2021 at 23:52 • 0 comments

  In this log I'll explain the algorithm I use to the control my VR shoes. Please refer to the following image.

  When the rectangle is solid, that means that the user’s foot is on the motorized shoe. When a rectangle is dotted, that signifies that the user’s foot is in the air and the user is bringing the shoe forward (or to the side) along with their foot.

  Step 1 is the starting position of the user, where they are standing still, shoulder-width apart. In step 2, the user starts taking a step forward. The right foot is in the air, and the motorized shoe is being brought forward along with the user’s foot. The sensor in the right shoe will detect an acceleration in the positive Y direction. The acceleration in the positive Y direction in the right shoe will trigger the left shoe’s main motor to turn on. The left shoe will be start moving backwards at the same speed the right shoe is moving forwards. The speed to use can be calculated by using the accelerometer data (integrating to get the velocity) or by using motor encoders. So put in other words, When the user takes a step forward with his right foot, the left foot is moved at the same speed in the opposite direction.

  In step 3, the user has put their right foot down on the motorized shoe again. In step 4, the user lifts their left foot and begins moving it forward. Just like in step 2, when motion is detected in the left foot, the right foot’s shoe will start bring the right foot back at equal speed in the opposite direction.

  In step 5, the user has brought their left foot down. Now the user decides to take one last shorter step, and then to stop. The shorter step is shown in step 6. In step 7, when the user brings their right foot down, she does not start to move their left foot. Since she doesn’t move their left foot, no motion in the left foot is detected, so the motors in the right foot’s shoe do not start up.

  Let’s now imagine that in step 5, instead of the user taking another step forward, she decides to take a step to the side, as shown in below.

  Shown in step 6, the user will lift their right foot and start moving it in the positive X direction. In step 7, the user has put their right foot down. In step 8, she continues their strafing to the right. She brings their left foot up and starts moving it I the positive X direction. Since motion in the left shoe is detected, the right shoe will start moving sideways in the opposite direction. In step 9, the user brings their left foot down.

  An additional thing to consider with strafing and that I think I’ll need to incorporate into the algorithm is that, with strafing, the user’s feet should not crisscross. If the user lifts his right foot and moves it X distance to the right, the right foot’s shoe should not move back a distance greater than X.

  Braking must also be considered in this algorithm. When the user is standing still, the motors should lock the wheels in place so that the user feels like he has stable footing. When the user is walking, for example, straight forward, the motor in charge of moving side to side will hold its position so that the shoe does not move to either side when it’s supposed to only move straight backwards. To detect the user lifting his feet, buttons will be on the top of the platform. When the buttons are compressed, the user’s foot is on the platform.

  The algorithm, step by step, is as follows.

  1. When the user is standing still with both feet on the platforms, the motors should resist any motion.
  2. When the user lifts one of his feet to start walking, his foot will come off the platform. That will be detected by the buttons on the platform. This will cause that shoe’s motors to stop holding their position.
  3. A 2D vector will be constructed that indicates the direction and speed the user is moving his foot and the shoe in.
  4. The other shoe, where motion is not detected and the user has not lifted his foot, will have its motors activated so that the motorized shoe starts to move. It will move at the...

  Read more »

• Introduction - The Problem and my Solution

  finallyfunctional • 01/31/2021 at 22:57 • 0 comments

  A problem with current virtual reality set ups is that you have to stand in one spot. If you walk forward, you will run into whatever is in front of you (a wall or physical object). To make the virtual reality experience more immersive, it would be ideal to be able to walk infinitely in the virtual world, in any direction, but stay in the same spot in the real world.

  Solutions for this problem already exist; they are called omni-treadmills. Below are examples of omni-treadmills.

  • http://www.virtuix.com/
  • http://katvr.com/
  • https://www.infinadeck.com/

  You can see that the first two consist of a platform that is slippery so that the user can slide her feet. The Infinadeck relies on conveyors. All of the treadmills are bulky and heavy. I also wonder how natural it feels to walk on a slippery surface and slide your feet back.

  My Solution

  At a high level, my idea is a motorized shoe that allows a person to walk while staying in the same physical location. Using this device and other VR equipment, a user can walk infinitely in a video game while staying in the same physical location in the real world.

  Omni-treadmills are large and heavy contraptions, making them hard to move and store. My motorized shoes are lightweight and can easily be stored in a closet. My design will also have of a safety harness connected to a support structure or a hook in the ceiling to make sure the user does not fall over.

  My Design

  I have gone through many designs at this point. My current design is explained in this video.

  My current design can go forward and backward, but doesn't have sideways motion. It utilizes one motor, speed control, and an ESP32 as the microcontroller. It communicates over bluetooth.
  

  The most notable difference with my VR shoes when comparing them with others is the flexible binding. A common issue with VR shoes is weight. All the components to make a motorized shoe, especially one that can go fast and can handle heavier people, adds weight to the shoe and makes it heavy to lift and use. My design gets around that problem by making it so the user never actually lifts the shoe off of the ground. Instead, the user's foot is strapped to the flexible binding and the binding can move up and down the 2 guide rods, but is still coupled to the shoe. The user can still lift his foot like he normally would when walking and the shoe gets moved by the user. The shoe is on wheels, so the resistance is negligible. Having to lift a 10 pound shoe would feel very heavy. Rolling a 10 pound shoe on wheels is easy.

  Safety Rig

  In addition to the shoes, a safety rig is required. The rig is there in case the user falls. Even if I could make the shoes so perfect so that the user doesn't fall 99% of the time, there is still the 1% chance that they will. Edge cases like that include if the shoes break, run out of power, or the user falls over for some reason unrelated to the VR shoes (don't drink and use VR shoes without a harness). Given that a user will likely use the shoes for many hours, hopefully over many years, the 1% event will happen. Think of it like a seat belt. I personally have technically never needed one, but it's still smart to wear one.

  My current safety rig consists of a hook in the ceiling, a safety harness, and a tether connecting the two. This was the simplest setup to get going, as all I had to do was buy off the shelf parts. It's also very easy to store when I'm not using the VR shoes. Right now I'm also using a couple of bungee cords to help me balance while using the shoes. I'm hoping I can eventually get rid of them. Additionally I have two additional hooks within reach that I hang the headset and controllers on.

  My current setup makes it so that it only takes a few minutes (or less) to strap in and start playing.

  1. Put the harness on. You can do this where ever.
  2. Strap the shoes on.
  3. Hook the tether to the ceiling hook.
  4. Grab the controllers and headset.

  Of course, there are many safety rigs that...

  Read more »

View all 5 project logs