Build Log Day 61:
I’ve spent two days training gripper – camera coordination. For the sake of versatility, I’ve let it practice both moving the gripper to a target object, as well as placing an object held by the gripper on a target location. It’s now at a point where I’m satisfied with the performance. On the negative side, I’ve noticed some performance issues, the limb with the gripper isn’t moving as fast as it was just a few days ago, and I can’t see any clear explanation for this. I will keep monitoring this issue, in the mean time it’s back to working on the adaptive gripping algorithm.

Build Log Day 62:
Today I’ve been working on the adaptive gripping algorithm. I built a feedback loop where each finger bends until the Nerve sensors on every section of a finger registers contact with the object. At that point the fingers continue to move until the desired pressure is reached. The desired pressure is defined by fuzzy logic as either loose, standard or tight. Some early tests shows that this works well for solid objects of a certain size and shape. Any object that differs too much from this acceptable range off size and shape cannot be gripped. Object that are soft can be gripped but it’s difficult to reach desired pressure.

To get around the first issue I have added a set of rules for different desired grips. In the standard grip every section of each finger is in contact with the object but there are a number of special grips where only certain fingers or certain sections may contact the object. For example I have a special grip where it’s only the very tips of two opposing fingers that touch. This should enable the gripper to grasp objects much smaller than itself. I did a few quick tests and it seems to work. That’s all I had time for today.

Build log Day 63:
I started the day with a couple of rounds of testing and calibration and I got the gripping algorithm to work really well for the standard grip. The rules for special grips that I added greatly expands the range of acceptable object shapes and sizes but so far I have to manually select which grip it should use. I also have to manually select the desired gripping pressure. Since it worked well for object targeting I’ve decided to train the B.R.A.I.N to select a grip as well as gripping pressure by itself. That way the gripping action can become truly adaptive.

I set up a trial and error type training loop for the B.R.A.I.N where it will select one grip and pressure setting for an object then try to grasp it. If it succeeds it moves on to the next object. If it fails it has to select another grip and pressure combination and try again. When it succeeds it gets rewarded, when it fails it gets punished and if it breaks the object by using too much pressure it gets punished. The fewer tries it needs, the bigger the reward and conversely the more tries it needs the bigger the punishment. I didn’t have time to do any actual training today, will work on that tomorrow.

Build Log Day 64:
This morning I started running the trial and error training loop that I talked about yesterday. I didn’t take long before I noticed a drop in performance, just like a few days ago. I started monitoring everything closely while the Man kept running the training loop. After a couple of hours I figured out what was going on. Back near the start of this build I added a Liver series filter unit for preventing byproducts from the energy conversion process to contaminate the hydraulic fluid. Analyzing a small sample of hydraulic fluid, I came to the conclusion that despite the Liver filter, the hydraulic fluid still becomes contaminated over time, which upsets the chemical balance of all the additives in it. I thought of installing a second Liver but the contaminants are so small that a regular filter would remove a lot of the additives as well, so that wouldn’t work. By pure chance I found that the same company that produces the Liver filter also make a series of osmosis based purifiers called Kidney. I think these should be able to remove contaminants and rebalanced the chemical additives but I’m afraid one wont be enough so I ordered two.

Build Log Day 65:
The Kidney purifiers arrived this morning with express mail. I immediately installed them and did a couple of small scale tests. They work, the hydraulic fluid that comes out is pure and has the correct chemical balance. What I hadn’t counted on is that the osmosis process means that some liquid is removed along with the contaminants. It is expelled via a short tube on the under side of the Kidney. This gives me two problems. First, the Man will need to replenish the hydraulic fluid somehow. Second, I don’t want the Man to go around dripping liquid waste everywhere so I have to find a better way to dispose of it.

The second problem was easier to solve so I fixed that immediately. I installed a small rubber reservoir or “bladder” as I like to call it, and connected the waste output tubes from both Kidneys to it. I have a simple “level full” sensor on the bladder and a valve for emptying out the waste liquid. I also programmed a small subroutine for emptying all the liquid at once when the bladder becomes full.

Replenishing hydraulic fluid is more difficult but I’m working on a solution. I have figured out that I don’t need to add actual hydraulic fluid, as long as the additives stay in the system, all I need to do is add some simple base liquid e.g. water. I should be able to add the Kidney purifiers to the main hydraulic loop and let all the fluid slowly circulate through them. If I increase the concentration of additives slightly, there should be no problem to inject water directly into the system and let the Kidneys automatically take care of any chemical imbalance. The only question is, where do I get the water from?

Build Log Day 66:
I spent the evening yesterday trying to figure out where to get water for replenishing the hydraulic fluid. This morning I realized I had been missing the forest for all the trees. The energy converter is using a wet process to convert biomatter into energy; solids are separated out as waste while the energized liquid gets filtered through the Liver before transferring it’s energy to the hydraulic fluid. I have installed a small valve to siphon off some of this liquid right at the output of the Liver. In order for the energy converter to not run dry it just needs to add more water into the conversion process. For this reason I have added an additional general task for the Man: except for consuming biomatter, it must also consume water.

With all the sub-systems for hydraulic fluid filtration in place, I ran a large scale test this afternoon. I started by running all of the hydraulic fluid through the Kidneys to purify it. There must have been more contaminants in the system than I thought because I had to empty the bladder twice during processing. Afterwards I noticed that pressure in the system had dropped a bit due to loss of fluid, so I poured a liter of water into the energy converter then let it run for 30 minutes. I then triggered the valve to siphon off some liquid and inject it in the hydraulic loop, and let let it circulate through the Kidney purifiers once more. I took samples of the fluid both at the start and end of processing. The system works well, all values look a lot better after purification than before. Tomorrow it’s back to working on the adaptive gripper.

Build Log Day 67:
I spent the whole day running the trial and error training loop that I was talking about before the whole Liver and Kidney business interrupted my work. I managed to fit in a few hundred repetitions for every object type in the database. It is now able to select the correct grip and pressure for any object in the database on the first try. I previously mentioned that it had problems gripping soft objects with the correct pressure. I started with solid ones and as it progressed I started using softer and softer objects. The B.R.A.I.Ns capability to learn is better than I expected because it managed to adjust to holding very soft and delicate object without damaging them. Checking the logs I realized it had created an additional pressure category for delicate objects, all on its own. It’s hard to say at the moment what the implications of that may be but it’s incredible it managed to do that. The end result of all this is that the Man is able to target any known object (in the database) and reach out with the gripper until it makes contact, then grasp it using an appropriate grip and pressure, in less than one second.

Build Log Day 68:
I think I’ve reached a kind of milestone in the project. To Summarize, the current capabilities of the Man are:

  • Moving around
  • Obstacle avoidance
  • Object recognition and identification
  • Object targeting and grasping

I designed a test area to test the combination of all these capabilities. In a big room I set up a kind of maze of walls and some other obstacles, all screwed to the floor. I then put a number of objects, both consumable ones and nonconsumable ones, on random spots in this maze. Lastly I made two collection boxes, one for consumable objects and one for nonconsumable objects. I set the Man in the room and gave it the task to find all objects, identify them and sort them by bringing them to the proper collection box. I thought this would be easy but the Man failed miserably. It got to the first object, grasped it, then just stood there, unable to move. The reason it failed is because I had only programmed one movement pattern which is based on using all four limbs. With one limb holding the object, that was no longer possible. I’ll work on solving that over the coming days.

Build Log Day 69:
On a bit of a whim I decided I will try to let the Man learn how to move around only using three limbs. I first made a small configuration file containing all the data on the four limbs including size, movement range etc. This will make the B.R.A.I.N aware of its body. I then marked one of the limbs as unusable and set it a task of moving a short distance to a certain spot. At first it solved this task by falling in that direction, getting up and falling again, until it reached the goal. While this works it’s not what I want so I gave it a few reward points for reaching the goal but punished it for the technique. I can’t think of any good metric to judge movement technique so for now I will stick with manually giving out reward / punishment points. I tried a few more times but it just kept falling over and getting up, but faster each time. I then adjusted the rewards and punishments and that finally got it to try a slightly different technique but it’s still too similar to the fall forward method. I will have to keep working on it. Since I’m manually rewarding / punishing the Man I think this will be a very slow process.

Build Log Day 70:
I decided to try to speed things up a bit by automating the training process. This meant focusing on some simple criteria for rewards / punishments and skipping technique which is entirely subjective and therefore impossible to formalize. Movement speed has worked before so I decided to base my training around that. I made a small auxiliary software that handles rewards/punishments. It basically just measures the time it takes the Man to reach a goal and compares it with the time for the last goal. The more it can increase the speed, the more reward points it gets. I then set a course with several goals in a loop so that the Man can just move endlessly from one to the next. With this done I set it to run over night. Let’s see how it’s doing in the morning.

Build Log Day 71:
When I came down to the test chamber this morning the Man was acting utterly crazy. It was falling, rolling, wiggling and sort of just spazzing out, but managing to move from goal to goal at a surprisingly high rate of speed. There was no way of gaining control over it and I had to shut the thing down by force.  To avoid this situation in the future I built in a killswitch that can be remote operated. It works by cutting off the power to the little Arduino that controls the bellows and hydraulic pump.

Once I had everything back under control and properly put together again I went back to the task at hand. Instead of simply disabling a limb I had it actually grasp a random object and told it to bring the object to the goal location. I then restarted the training loop. When I came back to the the test chamber a couple of hours later the Man was racing around at and incredible speed. Apparently it had figured out it could throw the object towards the next goal then move there using the standard four limb technique and pick up the object again once it reached the goal. I had to use the killswitch to stop this loop. I don’t like having to use it right after implementation, I will need to find a better way to communicate remotely with the Man. Before working on that however, I needed to stop if from running wild. I added a rule to the reward/punishment mechanism that severely punishes the Man for dropping the object. I then ran a limited number of training loops. It quickly unlearned the previous behavior.

It was interesting to see what can happen when the Man is set a simple task without any rules. I need to be more careful with this in the future. Unfortunately, I’m basically back to square one here, will have to rethink my strategy a bit until tomorrow.

Build Log Day 72:
Today I started by limiting training to 100 loops. That way I’m better able to control the Man and add rules as it moves along. I then tweaked the rules a bit and started the first round of training for the day. By the end of 100 loops it had developed a kind of crawl technique where the limb grasping the object is held up in the air while it uses the remaining three limbs to sort of wriggle it’s way towards the goal. This is already better than the fall forward method from day 66. I continued training the Man and refining the rules for the rest of the day. I’ve seen limited progress since the first crawl technique.

Build Log Day 73:
To speed things up a bit I created a file containing an algorithmic description of the basic four limb movement pattern. I fed this into the B.R.A.I.N as a reference then started the training. Progress is still slow but after a full day it’s finally reached a point where it’s no longer crawling on the floor. This movement pattern is not optimal, I think it can do better with time, but this will have to do for now.

Build Log Day 74:
Though it wasn’t in my original plan for this build, I’ve decide the Man really needs the  remote command system I was talking about a few days ago. I’ve been looking at som different solutions and come to the conclusion that a voice command system would be the best. I started by looking for some microphones for the Man. A Chinese company called Tingli makes an interesting system called Binaural where two microphones are placed in such a way that they can pick up sounds from a 360 degree field. This is great because it lets me give the Man commands wherever it is in the room. I immediately ordered a set.

The next step was voice recognition. I created a small database of basic commands like “Start sequence”, “End sequence”, “STOP!” and so on. I connected a simple microphone to the B.R.A.I.N and made a small add on software that displays the selected command on the diagnostic screen. I then started training, speaking a command into the microphone and rewarding/punishing it depending on if it selected the correct one or not. It’s already at a point where it can recognize every command in the database when spoken directly into the microphone. As soon as I’m not speaking into the microphone, it fails to recognize the command. Hopefully the Binaural mics will take care of that.

Build Log Day 77:
This morning the Binaural mics had arrived in my mail box. I installed them on the sides of the B.R.A.I.N box and wired them up. I did a few quick tests to see if they work. After a bit of adjustment I got them to pick up sounds from the full 360 degrees. I then ran a few tests with the voice commands that I had been training a few days ago. No matter which angle I had relative to the Man it could pick it up as long as I was close enough. When I got further away it seems the sound got too distorted. I spent the afternoon training the Man to recognize voice commands both at long distance and with some background noise.

Build Log Day 78:
With the voice recognition working, I linked the voice commands to the actual controls of the Man. I ran a series of test and they all worked well. I then did a final test where I started a loop and used a voice command to stop it roughly half way through. This also worked meaning I no longer have to rely on the kill switch if the Man gets stuck in an endless loop. I now went back to working n the three limb movement that I put on hold on day 70. I started an endless training loop and let it run over night. Let’s see how it’s going in the morning.

Build Log Day 79:
During the night there’s been an extraordinary development. The Man isn’t moving around on three limbs like I had expected. Instead it gets up on two limbs, takes a few steps, then looses its balance and gets back down on three, all the while holding the object safely up from the ground. It’s really incredible that the B.R.A.I.N could come up with such a solution without any input from me. Clearly the reward/punishment learning algorithm is a powerful one.

Day 79 Continued:
After observing the Man for a little while I used a voice command to get it to stop. At first it seemed the command wasn’t working but eventually it stopped. Looking at it I realized it had completed the current loop before stopping. I analyzed the two limb gait it was using and it’s far more effective for moving around while holding an object than any three limb gait. This shows that given enough time, the B.R.A.I.N can come up with an optimal solution. The only problem right now is that’s only alible to balance on two limbs for a few seconds.

Pages: 1 2 3