search

fredyvilla / opencog-to-minecraft

Interface linking Minecraft to OpenCog using ROS
1 stars 0 forks source link

Ability to destroy a block #5

Closed fredyvilla closed 8 years ago

fredyvilla commented 8 years ago

A new action is needed to destroy a block in front of the bot.

kdexd commented 8 years ago

I will like to occupy myself currently by working up on this issue !

fredyvilla commented 8 years ago

It this task complete?

AndrewBuck commented 8 years ago

So this is basically complete now. Currently the bot will send a DIG_START, then wait 5 seconds which sending the 'swing arm' animation repeatedly, then send a DIG_STOP and wait a few more seconds standing still. The extra wait at the end could probably be removed, and it would be nice to be able to specify how long to dig for.

Also, during the timers while the bot is digging, it is just standing there paused. This causes the single time step the bot is executing to take 8 seconds, rather than the 1 second maximum it is supposed to take. A better way to do this is to send the dig start and then finish that time step, with the intention of continuing to monitor the state of the block being dug during the upcoming time steps. This would allow the bot to watch for enemies and look around or do other planning/thinking while it is digging the block out. This would mean, however that we need to do something like set a preferred action for the next one after this. This is probably something we want to do anyway, but figuring out the best way to do it is tricky.

fredyvilla commented 8 years ago

I was thinking that actions would be based on perception stis so that the bot has the basic ability of multitasking and seizing an opportunity presented by a high sti. The Bot needs to support focused tasks driven by a high demand and also background tasks that take over if there are jo other demands. Lets say the bot has 9 health hearts out of 10. The bot will continue to explore looking for wood blocks, but if a pig block walks by, the bot changes to hunting to seize the opportunity, while hunting it sees a diamond block, and it presents a higher sti because it is so rare. Stis are constantly changing based on demands and bot values. This models a more AGI approach were the bot defines his own background tasks and we can give it some few hardwires demands like hunger and pain/damage.

On Jan 15, 2016, at 4:28 PM, AndrewBuck notifications@github.com wrote:

So this is basically complete now. Currently the bot will send a DIG_START, then wait 5 seconds which sending the 'swing arm' animation repeatedly, then send a DIG_STOP and wait a few more seconds standing still. The extra wait at the end could probably be removed, and it would be nice to be able to specify how long to dig for.

Also, during the timers while the bot is digging, it is just standing there paused. This causes the single time step the bot is executing to take 8 seconds, rather than the 1 second maximum it is supposed to take. A better way to do this is to send the dig start and then finish that time step, with the intention of continuing to monitor the state of the block being dug during the upcoming time steps. This would allow the bot to watch for enemies and look around or do other planning/thinking while it is digging the block out. This would mean, however that we need to do something like set a preferred action for the next one after this. This is probably something we want to do anyway, but figuring out the best way to do it is tricky.

— Reply to this email directly or view it on GitHub.

AndrewBuck commented 8 years ago

I like that idea. I was actually thinking along similar lines of boosting a block's sti if it is in the vision during this particular vision frame. Also, we should spread the sti values to neighbouring tiles so that you don't end up forgetting little "holes" of space unless there are much larger areas that are not being visited.

One of the current goals of the bot is "Look around" which is designed to go back to areas explored a while ago that have started to fade from memory and try to "refresh" them. It is something designed to be very low priority, but to allow the bot to try to build a sense of its home environment by patrolling an area to gain familiarity with it. Since only a certain size area can be patrolled in the limited time allocated to that goal, only a limited size area will become "home" to the bot where it is confident it knows what is there, and it feels safe when it is in that area. This desire to stay in the home area and learn about it works in opposition to the "Explore" goal which desires to go out and discover new areas that the bot has never been before.

fredyvilla commented 8 years ago

I'm wondering if the bot's spatial memory should be more stable and less prone to sti loss overtime. Human spatial memory is uncanny and I believe it provides a fundamental framework we should emulate. I like your idea of having the bot form a concept of home based on his most familiar surroundings. Returning to this home after venturing beyond hid mapped areas. I find high value in the bot having excellent spatial memory so that he can tap into this memory to fulfill his goals. We can keep his world small initially, maybe an island? To push his spatial abilities beyond a contained area, we would need to rely on more agglomerate clustering. I dont think this is necesary just yet. The bot would become an expert on his island. Mastering its resources, features and geography. It would develop its own value system. Now imagine another bot on another island with a different biome. He would develop a totally different survival strategy. Instead of teaching a bot every type of block and terrain, we spawn 100 bots in mini biomes and then merge their knowledge bases using any and all agglomarate methods to create an amazingly knowledge minecraft bot.

On Jan 15, 2016, at 6:17 PM, AndrewBuck notifications@github.com wrote:

I like that idea. I was actually thinking along similar lines of boosting a block's sti if it is in the vision during this particular vision frame. Also, we should spread the sti values to neighbouring tiles so that you don't end up forgetting little "holes" of space unless there are much larger areas that are not being visited.

One of the current goals of the bot is "Look around" which is designed to go back to areas explored a while ago that have started to fade from memory and try to "refresh" them. It is something designed to be very low priority, but to allow the bot to try to build a sense of its home environment by patrolling an area to gain familiarity with it. Since only a certain size area can be patrolled in the limited time allocated to that goal, only a limited size area will become "home" to the bot where it is confident it knows what is there, and it feels safe when it is in that area. This desire to stay in the home area and learn about it works in opposition to the "Explore" goal which desires to go out and discover new areas that the bot has never been before.

— Reply to this email directly or view it on GitHub.