Patrick McDowell
Download 0.83 Mb.
|
|
Even though the grow.vi program did its job, it seemed that it would take an excessive amount of time to come up with a good walking gait using this method. Again, if the genetic algorithm were driving a simulation, the solution would take much less time. But considering it takes between 30 seconds and a minute for each individual to run in the grow.vi program, and it could hundreds if not thousands of generations to get the gait right, there had to be a better way. Another major consideration was servo life. How long could they take a beating and not fail? Logical reasoning and practical experience leads one to believe that walking can be broken down into some sub-tasks. One may be balancing, another may be reaching out with a foot, and another would be pulling with the foot once it was in contact with the ground. If the robot could not loose its balance, for example a well built six leg bug type robot would not need to worry too much about balance, then its primary concern would be reaching and pulling with its feet. If acceptable reach and pull movements were available, then the problem of walking would boil down to finding the right timing for the reach and pull movements. Said another way, if each leg had a controller that guided it through a reach or pull movement at the right time, then walking would be a team effort for the legs. This reasoning closely parallels Subsumption Theory that MIT developed for some of their walking robots, and it turns out that biologist say that this is how real bugs walk. Each leg in bug has neurons in it that manage the task of figuring out when and how to move. Walking for bugs is a collaboration of the neurons in the legs, not a centrally directed effort. The f0.vi program works using the concepts outlined above. By taking advantage of LabViews multitasking capabilities a virtual controller for each leg was created. Each virtual controller has a reach section and a pull section. Stubby was stable enough to ignore the balance problem for the time being, and concentrate on the gait timing. The initial idea was to let each leg controller know what the other legs were doing, and then it would make a decision to reach, pull, or wait. The m0.vi program was used to create acceptable reach and pull sequences. During testing, user setable binary flags were used to fire the reach and pull sub-controllers. Figure 12 shows the control screen for the f0.vi program. Note the gait control flags in the lower center of the screen. 
Figure 12. The control screen of the f0.vi program. Note the buttons on the left for firing of individual virtual sub-controllers. Also note the binary gait flags in lower central area of the screen. The four square green lights at the very lower central are the foot up/down indicators. By looking at the MIT Leg Labs website simulations for four legged walkers, by watching their video of their Quadruped (1984 – 1987), reading their literature, and by observation of cats, the quadruped gait for trotting was selected as the default gait. The trotting gait, like many others, uses the legs in pairs. The diagonal legs are paired up. That is the front left and right rear legs pull at the same time, and the left rear and right front legs reach at the same time, and vice versa. It produced a walk that was not perfect, but much better than previously achieved. Figure 13 shows a basic data flow diagram for the f0.vi program. 
Figure 13. This block diagram shows the basics of the software architecture for the f0.vi program. Note that all the processes in the rectangular boxes operate asynchronously. Performance is surface dependent, that is the robot works better on a surface that is forgiving, i.e. slippery. A similar condition occurs when a football player runs on astroturf. When he gets tired and his leg motion gets sloppy he has an excellent chance of tripping because his traction is so good. For ball players, it’s a double edged sword, a perfect motion creates incredible speed, but less than perfect motions cause tripping and injury. It all boils down to, the somewhat slipper surface masks errors in the gait, such as dragging feet during a reach motion, toe stubbing, etc. At this point in the development cycle, improvements such as sensing that a foot is down during a reach movement, adapting the reach and pull movements to each leg, and using and letting each virtual controller set its reach and pull flags have been studied but not implemented. Eventually the functionality of the virtual controllers will be off loaded to board computers, letting the PC handle higher level behaviors, and letting the board computers control the mechanics of moving. Directory: Academics -> Faculty -> pmcdowell Faculty -> Chapter 1 “Preliminaries” Reasons for Studying Concepts of Programming Languages Faculty -> Chapter 7 “Expressions and Assignment Statements” Faculty -> Deleuze and Analytic Philosophy by Faculty -> Curriculum Proposal Title of Proposal: Course Status Change Faculty -> Chapter 6: Arrays Faculty -> Chapter 5 Introduction pmcdowell -> Guide to Intelligent Systems; Second Edition; Michael Negnevitsky Faculty -> Carmen Sara Cañete Quesada Faculty -> Economic Conditions for Regional Development and for First Nations Download 0.83 Mb. Share with your friends:
|