AI

[Humanoido]

Nox: I think you also need storage, and realistically an onboard computer, like a gumstick - then writing some code that was capable of changing atleast its data would be easy, and prossible in robobasic, but exporting your changes out may be tougher - it would have to start from the beginning each time you switched it on then. Writing code that would allow itself to change itself is a bit of a nightmare from what i can see. You would almost need code that would run changeable sub-code. Still, will have more time to play once i've got the new (removed by spam filter) put in.

The way I see it, multiple processor controllers is the way to go. They have to be small, inexpensive, easy to use, and simple to program. We already have the first one, on RN, which can handle all the motions. Another controller can be dedicated to sensor management. A third to decision making. Now, we have those ETX etc. lines that we can communicate back and forth with, and no need for Bluetooth. Nox, congratulations on your first post and your brilliant ideas, but get that (removed by spam filter) finished soon!

humanoido

[Humanoido]

Gort: Page 43 the attributes of the hierarchical paradigm
Sense ------> Plan --------> Act
robot primitives ----- input -------- output
Sense ------ sensor data ----- sensed information
plan ----- information ----- directives sensed and/or congnitive
act ---- directives ----- actuator commands

This is really good stuff, Gort.

Using a multiple controller approach:
1) Sense ------> Plan --------> Act
2) robot primitives ----- input -------- output
3) Sense ------ sensor data ----- sensed information
4) plan ----- information ----- directives sensed and/or congnitive
5) act ---- directives ----- actuator commands

Using 3 Controllers:
(SERVOS) Controller 1: robot primitives ----- input -------- output
act ---- directives ----- actuator commands

(AI) Controller 2: Sense ------> Plan --------> Act
plan ----- information ----- directives sensed and/or congnitive

(SENSOR) Controller 3: Sense ------ sensor data ----- sensed information

[Pev]

Nox: I think you also need storage, and realistically an onboard computer, like a gumstick - then writing some code that was capable of changing atleast its data would be easy, and prossible in robobasic, but exporting your changes out may be tougher - it would have to start from the beginning each time you switched it on then. Writing code that would allow itself to change itself is a bit of a nightmare from what i can see. You would almost need code that would run changeable sub-code. Still, will have more time to play once i've got the new (removed by spam filter) put in.

The way I see it, multiple processor controllers is the way to go. They have to be small, inexpensive, easy to use, and simple to program. We already have the first one, on RN, which can handle all the motions. Another controller can be dedicated to sensor management. A third to decision making. Now, we have those ETX etc. lines that we can communicate back and forth with, and no need for Bluetooth. Nox, congratulations on your first post and your brilliant ideas, but get that (removed by spam filter) finished soon!

humanoido

Nested/Distributed processing has been an approach used for many years for complex robotics control. I have used it myself on many occasions. With regard to the RN 1 I believe the distributed approach is more than valid but would suggest looking at the I2C bus for inter-processor communications rather than the ETX/ERX ports, due to its poor basic language support and poor performance (single byte only etc). I2C slave processors are relatively easy to build using the AMTEL processor range and are even supported in languages such as BASCOM AVR (a basic for Amtel processors).

Pev

[Humanoido]

Pev wrote:

Nested/Dirstributed processing has been an approach used for many years for complex robotics control. I have used it myself on many occasions. With regard to the RN 1 I believe the dustributed approach is more than vali but would suggest looking at the I2C bus for communications rather than the ETX/ERX ports.

You are absolutely correct about nested distributed processing. This technique works well for extremely powerful microprocessors that can handle nesting and produce fast results. Being that we are at the hobby level, at least in my tiny lab, pretty much the only thing affordable would be some small dedicated hardware processors, like the Basic Stamp and those previously mentioned. IC2 is a great idea for communications. It has implementations on most microcontrollers.

humanoido

[Humanoido]

There are a lot of AI programs posted on the net for download. Many of these involve conversations that can remember data during the dialog. Some various good sources for this and other AI info are at:

http://www.simtel.net/category.php%5Bid ... simtel.net
http://www.alanturing.net/turing_archiv ... %20AI.html
http://www.developer.com/java/other/article.php/1546201
http://www.agt.net/public/bmarshal/aiparts/readme.htm
http://www.markwatson.com/
http://norvig.com/paip.html
http://library.thinkquest.org/18242/essays.shtml
http://blogs.msdn.com/devschool/archive ... gence.aspx

humanoido

[Pev]

Pev wrote:

Nested/Dirstributed processing has been an approach used for many years for complex robotics control. I have used it myself on many occasions. With regard to the RN 1 I believe the dustributed approach is more than vali but would suggest looking at the I2C bus for communications rather than the ETX/ERX ports.

You are absolutely correct about nested distributed processing. This technique works well for extremely powerful microprocessors that can handle nesting and produce fast results. Being that we are at the hobby level, at least in my tiny lab, pretty much the only thing affordable would be some small dedicated hardware processors, like the Basic Stamp and those previously mentioned. IC2 is a great idea for communications. It has implementations on most microcontrollers.

humanoido

Sorry I obviously wasn't clear. I have built nested/distributed processing systems using ATMega8 processors and I2C with a Basic X24 as the master controller. The ATMega 8 processors are less than £2 each and the BASCOM compiler is available as a free demo (up to 4k of code I think)

Pev

[i-Bot]

Th MR-C3024 uses the 2 wire interface to connect to the program EEPROM. On power up it searches for the EEPROM in the range 0 to 3. The board EEPROM is at address 3. I use this to plug in extra memories at address 0 and know this works.

If you appear to the controller as a slave and respond to adddress 0 as a slave, then you could send byte code instructions like group moves for execution. There are some timeouts, so likely you would have to use an interrupt routine. Just send a NOP (FF), if you dont want any actions

[Pev]

I also remember a post ages ago about bit banging one of the other ports to support an I2C interface. I think it was KurtE who posted it but I may be mistaken

Pev

[Humanoido]

So what would be involved in using this approach with the MR-C3024, I2C interface, and Basic X24? (hardware and software) or basic stamp, etc...

humanoido

[Pev]

So what would be involved in using this approach with the MR-C3024, I2C interface, and Basic X24? (hardware and software) or basic stamp, etc...

humanoido

Now there is a leading question. Firstly I found these post from KurtE:

*********************************************************
I finally had some success with bit banging out an I2C interface in RoboBasic. I ended up not using the SDA/SCL pins on the board as they are used by an EEPROM on the board and it is unclear in RoboBasic what IOPORTS are assigned to thise signals. Currenty I am using the ATOI 1 (33) and ATOI 2 (34) pins for SCL and SDA.

I have now can do pings on a Devantech SRF10 Range Finder.

*********************************************************
I believe a copy of the source code is still up at:
http://robosavvy.com/Builders/KurtE/I2C_Test.bas

The ATI pins are up upper right hand side of the board. At the point I did the post I was using ATI 1 and 2 as 0 was used for a GYRO. Currently I am using ATI 2 and 3 and I am now playing with two gyrsos and they use 0 and 1.

I hope this helps.
**********************************************************

So that has the code for making the MR-C3024 an I2C master. The tricky bit would be making it a slave so that it's "functions" could be called over I2C so for example a motion could be called by writing a motion number (11 for walk forward) to an I2C slave register.

Then a Master Processor ( the Basic X24 for example) could act a the primary and call the motions and also communicate with other I2C processors or units such as sonar LCDs etc etc

All very theoretical in reality other than the fact I have made an MR-8 CPU Board acting as a slave I2C device for another project driven by an AMTEL processor.

The Software for that system was all written in BASCOM basic.

Pev

[Humanoido]

Very Important Key Quote:
Pev Wrote:

So that has the code for making the MR-C3024 an I2C master. The tricky bit would be making it a slave so that it's "functions" could be called over I2C so for example a motion could be called by writing a motion number (11 for walk forward) to an I2C slave register.

Then a Master Processor (the Basic X24 for example) could act a the primary and call the motions and also communicate with other I2C processors or units such as sonar LCDs etc etc

All very theoretical in reality other than the fact I have made an MR-8 CPU Board acting as a slave I2C device for another project driven by an AMTEL processor. The Software for that system was all written in BASCOM basic.

The Key to Developing Robonova AI
Indeed, for AI, I think we are on to something here that can be very useful. The key is to develop an interface to go from the MR-C3024 to another MCU, using I2C. As I understand, this would be ideal for accessing numerous sensors capable of I2C communications. Say we use the MR-C3024 as the dedicated motion board. And say we use an add-on processor, be it the MR-8 CPU board, Basic Stamp IIpx, Basic X24, or other board. This opens up an entire new door for very powerful AI processing.
--------------------
I'm starting to look for and evaluate microprocessor boards with I2C built in for AI add-on to Robonova. If anyone has any suggestions, and/or is constructing some simple systems to illustrate the concept, I'd be glad to hear about it. Also some references to "working I2C systems" with multiple processors would be helpful.

humanoido

[Pev]

Humanoido

As the MR-C3024 is not by default an I2C slave how about this:

1. Add one (initailly) additional AI processor with both serial and I2C interaces.
2. Slave the MR-C3024 to the AI processor over the serial connection for calling motions.
3. Slave sensors and additional sub-processors to the AI processor over I2C.

Thus the 'intelligence' can utilise the sensors etc to make descisions and then call the appropriate motion.

I Think I have enough stuff knocking about to try this, certainly have an MR-8 board and couple of I2C sensors knocking about.

Pev

[Humanoido]

Pev, this is a brilliant idea. I've found a BS2px processor that has the power I'm looking for and it would make an ideal test bed. It has both serial and I2C. I'm looking into the interface wiring at this moment, and if the I2C interface can be pinned, then I plan to use it for AI.

Here are some specs on the board:

Technical Specifications
Processor Speed 32 MHz Turbo
Program Execution Speed ~19,000 instructions/sec.
RAM Size 38 Bytes (12 I/O, 26 Variable)
Scratch Pad RAM 128 Bytes
EEPROM (Program) Size 8 x 2K Bytes ~4,000 Instructions
I/O Pins 16+2 Dedicated Serial
Voltage Requirements 5 - 12 vdc
Current Draw at 5V 55 mA Run / 450 μA Sleep
PBASIC Commands 61
Size 1.2"x0.6"x0.4"

http://www.parallax.com/detail.asp?product_id=BS2PX-IC

Another processor I'm looking at is the propeller. It could be much more challenging to program. The one chip has eight 32-bit processors in one chip for real simultaneous multi-processing! (I can envision software dedicated to each processor, such as vision interpretation, interpretive speech, continuous speech recognition, ideas and cognition, and sensor arrays.) It took eight years to develop. It looks something like this:

Propeller Specifications
Package Types 40-pin DIP, 44-pin LQFP, 44-pin QFN
Model Number P8X32A
Parallax Stock Codes P8X32A-D40 - DIP package
P8X32A-Q44 - QFP package
P8X32A-M44 - QFN package
Power Requirements 3.3 volts DC
External Clock Speed DC to 80 MHz
(4 MHz to 8 MHz with Clock PLL running)
Internal RC Oscillator 12 MHz or 20 KHz
System Clock Speed DC to 80 MHz
Global RAM/ROM 64 K bytes; 32K RAM / 32 K ROM
Processor RAM 2 K bytes each
RAM/ROM Organization 32 bits (4 bytes or 1 long)
I/O Pins 32
Current Source/Sink per I/O 40 mA

http://www.parallax.com/propeller/index.asp

Previously I didn't want to tie up the RN serial port, thinking about adding Bluetooth. But now, there's no need for BT when an AI package is installed. It can make the decisions, not the large computer.

Pev, I would highly encourage you to go ahead with the circuit you described using the parts and board you have. I will continue along the same venue using the parts I have. It looks like this could be one powerful AI system for all RNs, and perhaps all humanoids.

If we get a powerful workable AI hardware system platform developed, one idea would be to open source the software. Considering the complexity of AI, it's going to take a lot of human minds working together to create such a vast system.

humanoido

[Gort]

Linux Robotics: programming smarter robots By D. Jay Newman

I just bought this book. Has a lot of source code in the book or for download. It also looks like you can read most of the book online

http://books.google.com/books?id=mxHKcq ... =1#PPP1,M1

[Humanoido]

More on Linux and AI

http://linuxgazette.net/issue19/ai.html
http://www.linux.com/howtos/AI-Alife-HOWTO-2.shtml

I had also talked about Open Source AI and then
found this site!

http://openai.sourceforge.net/

humanoido