Society of Robots - Robot Forum

Software => Software => Topic started by: SmAsH on April 28, 2009, 05:38:52 AM

Title: community project: software aspects.
Post by: SmAsH on April 28, 2009, 05:38:52 AM
this is a place to discuss all the aspects relating to software such as programming and communication.
Title: Re: community project: software aspects.
Post by: hazzer123 on April 28, 2009, 05:48:03 AM
I2C is designed by pros guys... its a very old and well tested protocol. Trust it! There won't be any problems with multi-master :)
Title: Re: community project: software aspects.
Post by: SmAsH on April 28, 2009, 05:49:55 AM
out with the old and in with the new? lol no... im trusting you on this one harry... don't let me down boyo...
Title: Re: community project: software aspects.
Post by: dellagd on April 28, 2009, 06:38:04 AM
from what I see, I2C seems really cool and a good choice. also very plug and play.
Title: Re: community project: software aspects.
Post by: Asellith on April 28, 2009, 11:07:55 AM
I2C is commonly referred to as the USB for chip to chip communications for a reason.
Title: Re: community project: software aspects.
Post by: dellagd on April 28, 2009, 01:47:30 PM
is I2C this easy?
take 2 I/O pins on like a atmega 8 (for SDA & SCL) and then program it properly (unless this is a ready amde I2C device) like to be a slave/master? I am just a little confused on how we set up the I2C connections.
Title: Re: community project: software aspects.
Post by: Webbot on April 28, 2009, 02:01:28 PM
Check out AVR311 and AVR315 for Slave and Master examples respectively on the Atmel website. And 'YES' it only needs two wires (hence it being called a two wire interface TWI - since I2C is copyrighted). There is a hidden 3rd wire - the ground wire..

Title: Re: community project: software aspects.
Post by: Asellith on April 28, 2009, 02:20:21 PM
Its even easier then you think dellagd. The ATmega8 uses PC4 and PC5 for SDA/SCL. It has registers and even configurable interrupts to help you use them. Its built in to the MCU. Now a good library will help the programming side a lot. AVRLIB I think has I2C code in it.
Title: Re: community project: software aspects.
Post by: dellagd on April 28, 2009, 02:24:42 PM
but when you start up the TWI system don't you have to declare the ATmega8 to be a slave? then the master takes over from there. another question. lets say I have I IR rangefinder mod. I am a TWI master. How would I get that info?
Title: Re: community project: software aspects.
Post by: Webbot on April 28, 2009, 03:12:55 PM
but when you start up the TWI system don't you have to declare the ATmega8 to be a slave? then the master takes over from there. another question. lets say I have I IR rangefinder mod. I am a TWI master. How would I get that info?
Apologies if I've misunderstood your question but... A slave device is one that only talks over the bus when someone sends it a question. Sensors for example can therefore only be slaves. They just monitor stuff and when a master asks it for its current value then it replies with the value. Otherwise it is dormant. Each device on the bus has it own unique address and so you address a given sensor by placing its address in the msg packet.
The main controller board is therefore a master and can 'ping' all the slaves, one at a time, to get (say) sensor values. This 'only speak when you are spoken to' handshaking guarantees that there are no collisions on the two wire bus. Its only if you add a second, third, etc master that collisions can start to occur - ie when more than one master tries to place a 'question' on the bus at the same time. The underlying protocol allows for this and will notify the master that their question was 'lost' and needs to be re-asked.

@Asellith - The AVRLIB does have I2C support (but only for a master device). You may need to modify it (as Admin did for the Axon lib) as the port/pins for SDA/SCL are hardcoded and therefore wrong for most processors. Alternative is to wait until my library, just announced here http://www.societyofrobots.com/robotforum/index.php?topic=7787.0 (http://www.societyofrobots.com/robotforum/index.php?topic=7787.0), adds more friendly master/slave I2C support.
Title: Re: community project: software aspects.
Post by: dellagd on April 28, 2009, 05:51:49 PM
you did. this is what I ment. what exactly does the master send to the slave?
I mean, does it just send numbers like 0110101? and how does this correlate to getting the distance form the IR sensor. Is the slave constantly waiting for a signal. and is 0110101 like a machine code code (if that makes sence :P ). so this somehow corrolates to "tell me your current reading IR sensor #28"? I get the concept just not the fine details.
Title: Re: community project: software aspects.
Post by: Razor Concepts on April 28, 2009, 05:58:58 PM
http://en.wikipedia.org/wiki/Binary_numeral_system (http://en.wikipedia.org/wiki/Binary_numeral_system)


Slaves has addresses (in binary). The master will basically put out a series of binary numbers that represents an address... all the slaves on the TWI line get the message, but the particular slave you want will read it and know "hey thats my address". Since now it knows the master is talking to it, it will read the next series of binaries which is the actual message the master is sending it.
Title: Re: community project: software aspects.
Post by: dellagd on April 28, 2009, 06:04:00 PM
and then that message somehow correlates to "give me your reading"?
Title: Re: community project: software aspects.
Post by: Razor Concepts on April 28, 2009, 06:07:55 PM
That can just be your choice. You can predetermine if the message was, say, 56, that means give me your reading. So the slave would be like if(message = 56) sendData();
Title: Re: community project: software aspects.
Post by: Webbot on April 28, 2009, 06:09:42 PM
The rest of the msg (after the address) can be as long/short as you want and is up to you re its format

A common technique is to use the rest of the msg to specify command or register numbers. So a distance sensor could have:
register 0:  when written to you write a value ie 1=inches, 2=cm and reading the register gives you the distance in that unit

or you could have read only registers eg
register 0: read only - gives distance in inches
register 1: read only - gives distance in cm
Title: Re: community project: software aspects.
Post by: dellagd on April 28, 2009, 06:46:54 PM
sounds good to me!
Title: Re: community project: software aspects.
Post by: Asellith on April 28, 2009, 06:55:49 PM
Also according to the specifications the actual commands need to be ASCII code that is human readable. So 0x53 (hex number) is not a valid message but something like IR1 or Read IR or even Distance Sensor 1

This makes debugging a lot easier and with a good library its as easy as a printf statement to do (hint hint Webbot :) )
Title: Re: community project: software aspects.
Post by: Webbot on April 28, 2009, 07:14:06 PM
Also according to the specifications the actual commands need to be ASCII code that is human readable. So 0x53 (hex number) is not a valid message but something like IR1 or Read IR or even Distance Sensor 1

This makes debugging a lot easier and with a good library its as easy as a printf statement to do (hint hint Webbot :) )

Thanks for the 'heads up' - got it covered as far as I can  :-X....but for an existing 3rd party device 'the supplier' specifies what their msg format is and if its not ASCII then we will still have to go with it. Obviously if its a SoR device then you can dictate the msg format to be more debug friendly.
Title: Re: community project: software aspects.
Post by: SmAsH on April 29, 2009, 02:50:53 AM
man am i screwed when it comes to programming my module... im really going to need your help guys :-[
Title: Re: community project: software aspects.
Post by: hazzer123 on April 29, 2009, 12:50:00 PM
Although sending all data as ASCII on the I2C bus sounds nice, and maybe it would help with debugging, it isn't the standard and would just confuse things when working with modules we didn't create.

The standard I2C sequence can be seen in these datasheets:


By having internal register addresses to read and write from, we can have standardised and well organised modules.

Also, using ASCII is much less efficient and could lead to bandwidth issues in extreme cases.
Title: Re: community project: software aspects.
Post by: Trumpkin on April 29, 2009, 03:40:10 PM
Hey, Smash, check out this site, it might help you with the programming http://www.robot-electronics.co.uk/htm/using_the_i2c_bus.htm (http://www.robot-electronics.co.uk/htm/using_the_i2c_bus.htm)
Title: Re: community project: software aspects.
Post by: hazzer123 on April 30, 2009, 06:47:51 AM
What do you guys think about changing the I2C sequence from ASCII to the more standard (what i'll call) register access method?
Title: Re: community project: software aspects.
Post by: Asellith on April 30, 2009, 06:54:21 AM
ASCII is easier to understand. It doesn't have to be full words but I think the point is to avoid sending hex numbers that require a lot of translation to understand. I gave a bad example of this to Smash in another thread about his motor controller. Sending something crazy like 0x8F to send the left motor full speed and 0x4F to make the right motor go full speed it is a little rough for noobs to understand. now sending the command "L100" or "R100" is a lot easier. takes 7 more bytes then the original command and at 100 Khz that would take ~ 0.56 ms longer to transmit. Now yes in extreme cases that half an ms might be important but that is why we need to make it easy for users that will be using that much data to be able to increase the speed to 400 kHz. That would drop the "wasted" time to .14 ms. To make programming that much easier for the inexperienced I think it would be worth keeping the ASCII code requirement.
Title: Re: community project: software aspects.
Post by: hazzer123 on April 30, 2009, 07:08:55 AM
Ok so for noobs it is easier... but what about the fact that using ASCII isn't the standard?

Maybe we should instead look at making thorough software libraries for the common controllers that 'noobs' use. This would provide them with a layer of abstraction which is easy to interpret.

I'm not sure that getting rid of standards is good for the new people in the long term anyway. They should (and will have to) learn them some day anyhow. But then i realise also that a beginners attention can be short and difficulties might discourage them in the early stages.

Hmmmm maybe supporting both standards could be a good idea. Essentially have the modules support both the high-level beginner commands, and the lower-level standards. It wouldn't take too much more work in the code i think.
Title: Re: community project: software aspects.
Post by: Asellith on April 30, 2009, 08:40:28 AM
I can agree that if you produce a library for your module that would include functions like setMotorSpeed(motor, precentSpeed) then you can use whatever you want to tell the module how that will work if it is hard coded into a library. If you want a noob to program their main program to send various commands to the module then they need to be simple to understand. Similar to what you would see with a piece of equipment controlled through serial/uart commands. I for one do not want to memorize hex number sequences to talk to a module. The command R75 is a lot easier to remember when programming and easier to parse together from other code as it include an actual integer, then the command 0x4B (which took a google search to figure out). I may just be rusty with my binary to hex conversions but the idea is still there. We are talking about reducing ease of use to accommodate a condition that might happen to advanced users with a lot of modules and a load of data running around.
Title: Re: community project: software aspects.
Post by: hazzer123 on April 30, 2009, 08:50:03 AM
Yeap i won't argue the point that ASCII isn't space efficient, because i know that problem will rarely crop up in anyone's applications. But i think it could be a good idea to conform to the standards in electronics. I think then it would be easier for people to also use the commercial modules that are widely available (like sparkfun's magnetic compass for example)

Yeap... it wouldn't be impossible to use ASCII sequences for the OSCAR platform, and then the standard register addressing sequence for non-OSCAR modules... but it's not the prettiest solution in the world...

I mean.. we could just have a list of compiler defines which the user just copies into his/her code. That would mean that you spend less time googling random numbers. And the user would just type I2CWrite(SSM, SSM_MODE, CONTINUOUS_SCANNING) or something like that (for the scanning sensor module).

Hmmm, what do you think about supporting both and giving the user the choice?
Title: Re: community project: software aspects.
Post by: Webbot on April 30, 2009, 08:59:14 AM
The main program is probably using variable motor speeds - so you already have the speed of the motor in a variable. This could a signed 8 bit number and you could use the range -100 to +100 to denote full reverse through to full forward. Then you can just put the value of that variable into the message/register without any conversions at all. Converting to an ascii string would add the overhead of having to use rprintf,sprintf etc to convert it into a string and then the motor controller has to turn it back into a variable again - which would take much more of an overhead than actually transmitting the varialble itself.
Title: Re: community project: software aspects.
Post by: chelmi on April 30, 2009, 09:16:15 AM
I don't think using ascii is really necessary. It's better to stick to the standard.
In my opinion each module should come with a well defined API, like
Code: [Select]
void motor_controller_set_speed(LEFT_MOTOR, 100);
void motor_controller_brake();

This is the only thing the user will see. He should have to write anything related to I2C.

Now, of course you (as a module developer) will have to deal with I2C... And still in my opinion it's waaaaayyyy easier to receive a register address followed by a value compared to a string I'll have to parse.

for instance, with the "standard" approach:

Code: [Select]
#define LEFT_SPEED_REG 0x01

uint_8 register = i2c_read_byte();
switch(register) {
  case LEFT_SPEED_REG: {
    uint_8 value = i2c_read_byte();
    set_pwm1(value);
  }; break;
}

This is clean and easy to understand if you know C.
We could even think of a nice library to ease the development of I2C modules on AVR MCU. Where you just define the list of registers with their types and
the library takes care of the mundane details.

By the way, this is a good time to define coding guidelines. There is nothing worse than an inconsistent, badly designed library (look at PHP for an example of what NOT to do)
Title: Re: community project: software aspects.
Post by: Asellith on April 30, 2009, 09:32:12 AM
Well we are straying deep into my weakest are which is programming. We do need to define some standards but I don't think they need to be rather extensive. We want to give people freedom so they don't spend hours trying to get something to work just because of the standard. I think each module should require a defined API for the end user. This would make things easier for noobs and eliminate the problem I was trying to keep out of the way and thats usability. Then it is up the the module programmer to decide what inputs and outputs he wants.

I also think a generic library should be used such as the one Webbot is working on. That way the APIs can build on a good base and everything should work nice together. Just like the $50 robot is built on the AVRlib, OSCAR should have a standard set of includes that are needed to run. Now would it be easier to create a single library for all modules so that it similar modules can take advantage of commands that would be become a standard. Such as motor speed setting functions. That way if I want to put a 2 amp motor controller and a 0.5 amp motor controller in they use the same commands but just have separate addresses? Is this doable and clean enough? It also lets us sort of control what modules get included in the approved list easier. So you only get on the official OSCAR list when you meet the standards and someone from here checks your code and puts any custom code into the library.

We also need to look into officially assigning addresses to modules but that might be another thread
Title: Re: community project: software aspects.
Post by: Webbot on April 30, 2009, 09:40:34 AM
@Aselith  I would be delighted for my library to be the starting point. http://www.societyofrobots.com/robotforum/index.php?topic=7787.0 (http://www.societyofrobots.com/robotforum/index.php?topic=7787.0)  This already abstracts how the motors work - so you can change between servos and various motor controller boards without changing your main loop at all.  So the call to set the motor speed would just do all the I2C stuff for you. Since its hosted on SourceForge then I can allow others to contribute and make releases available.

Regarding I2C addresses - then the original spec from Phillips says that you should apply to them (and hence pay!) to be assigned a unique address - but this means you can only have one device of a given type on the bus which is a nonsense. So most folk allow you to configure it either with jumpers/switches or via a program command. Incidentally: the spec also suggests that addresses E0 and above are reserved.
Title: Re: community project: software aspects.
Post by: Asellith on April 30, 2009, 01:31:47 PM
I updated the communications standard int he tutorial section to reflect some of this discussion.

In reference to addresses. I think (as I mentioned in the standard) That we need to make some default addresses but they need to be configurable. Also to make things easier I think the Main Controller where the user is inserting their robot specific code should have a mandatory address. Also maybe make it so that several addresses are reserved for sub-controllers so if you need several mini controllers

Also the standard mentions a router type module. Do we need to specify how that will talk on the network or that it is even needed. The point would be to connect several UART devices or a wireless/Ethernet connection to the I2C bus. does this need to be in the specifications?
Title: Re: community project: software aspects.
Post by: hazzer123 on May 04, 2009, 06:14:56 AM
Here is my brief proposal for the I2C standard. If you like it, we can work on making more thorough and sort out the small details -

The Write Sequence
Start bit --> Module's address and R/W bit set (Write mode)  --> Register's 8 bit address --> Bytes to be written (big-endian byte transmission) --> Stop bit

The bytes to be written must be equal to the number of bytes in the register. If not equal, then the transfer is void, the register is not changed and a corresponding error code will be placed in the warning register (see later on).

The Read Sequence
Start bit --> Module's address and R/W bit set (Write mode)  --> Register's 8 bit address --> Repeated Start bit --> Module's address and R/W bit clear (Read mode)  --> Bytes to be read (big-endian byte transmission) --> Stop bit

The bytes to be read must be equal to the number of bytes in the register. If not equal, then the transfer is void, the data is presumed corrupt. If possible, an error code is placed in the warning register (see later on).

After the read sequence has finished, another transmission of the module's address and R/W bit clear (Read mode) will result in the module sending the contents of the register again, and if the register has changed since, it is the new contents that will be sent.

The Command Sequence
A command is achieved by writing the address of the corresponding command register. These registers have a 0 byte length.

Start bit --> Module's address and R/W bit set (Write mode)  --> Register's 8 bit address -->  Stop bit

I2C specific registers
Each module which communicates over the I2C bus will have 4 special registers. The I2C address, I2c settings, device name and warning register.

We will use 7-bit addressing and clock-stretching is allowed.

I think that's it.

What do you think?
Title: Re: community project: software aspects.
Post by: Asellith on May 04, 2009, 07:17:57 AM
I like it so far but I have a few comments.

    Can we include a way to get more then one byte of data per transfer? Several problems I see with it. If I need a 2 byte data stream from a module. Not sure off hand what would need 2 bytes but if I do I am afraid of to much traffic getting things confused. Master A asks for the first byte from Slave A and at the same time Master B wants to send data to Master A. Master A wins the first round to get control of the bus and then tries to get the second byte from Slave A while Master B wins round two and Master A gets confused and puts Master B's byte into the wrong register. Now one solution might be to include a destination register in the data stream or a byte that indicates the expected length of the message. So Master A says I need 2 bytes from Slave A and in the long run we potentially save bandwidth on the bus. Same goes for the read sequence.

   Another thing I see is that this the will require a standard API designed for all modules. It needs to be simplified for noobs as this would stretch my limited program skills and I'm not a noob :) And if we do the warning message register then this needs to be standardized. We can add support to special codes for unique modules as we go but most modules will only have a few errors. Also how does the Slave tell the master I had an error? Can a slave initiate a response to any master communication? Is the an ACK message for the slave? If so then a flag can be sent in that.

Edit: Also I will plan on separating the standard from the usage tutorial for OSCAR. the standard needs to be complex to make it usable but this last post would scare the crap out of a noob. I'll write up something simple this week to give an overview of the project and introduction on how to use it for people not designing modules.
Title: Re: community project: software aspects.
Post by: hazzer123 on May 04, 2009, 07:49:56 AM
Multiple bytes can be sent at one time. You don't make requests for each byte separately. So if there was a sensor outputting 128 bytes, it would go like this -

Start bit --> Module's address and R/W bit set (Write mode)  --> Register's 8 bit address --> Repeated Start bit --> Module's address and R/W bit clear (Read mode)  --> 128 bytes to be read (big-endian byte transmission) --> Stop bit

There are examples of 4 byte transmissions in this datasheet (http://www.active-robots.com/products/fiveco/datasheets/12cmot-manual.pdf) (pages 14 and 15). Ours are the same :) What it does mean, is you always receive/write the full contents of the register and you cannot be interrupted by another master halfway through transmission.

The receiver sends the appropriate ACK bit based on its reception of the last byte only. The warning register serves to warn the other modules that something more 'high-level' than a communication error has occurred. e.g. if a module expects an array of 20 bytes and it receives 18 bytes, then the warning register should be changed appropriately.

I see this feature being used mainly for debugging for us guys designing the platform. We should just leave it to the masters to request other nodes' warning messages and never have any module say "I've errored!" because this adds more complication (which module do you tell that you have had an error?) But yeah... there hasn't been a huge amount of thought into this. I'm open to any suggestions.

If you make your module adhere to the specifications, then adding your module to the software library we create will be a matter of copy, paste and edit. Of course you can always ask in here :)

Yeah we should have a manual for the users, and a datasheet for the designers/advanced users. Good idea.
Title: Re: community project: software aspects.
Post by: dellagd on May 04, 2009, 03:42:24 PM
maybe a noobish question, by why do we even need a multimaster system? to me it sounds like it makes thinks a lot more complicated.
Title: Re: community project: software aspects.
Post by: SmAsH on May 04, 2009, 03:45:50 PM
some people will want multimaster systems, personally i think one master if its the axon could handle even the most wacky robots.... but some people are weird... but multimasters do have some benefits...
Title: Re: community project: software aspects.
Post by: hazzer123 on May 04, 2009, 03:53:11 PM
Multi-master hasn't complicated things much. The only difference is a module must check it is actually controlling the line when it sends each high bit. Other than that... its no different.

The huge advantage is that you don't need to keep asking a sensor questions all the time. Asking a displacement sensor "Are we there yet?" all the time fills up the communication channel, takes up more processing, and is boring. Having the sensor as a master means it can monitor itself and then shout "Ok we're here!" when it needs to. The master is free to do the more important stuff :)
Title: Re: community project: software aspects.
Post by: SmAsH on May 06, 2009, 05:17:06 AM
ahh, so in theory you could tell the master sensor something like:
when sensor reading>55 send certain data?
Title: Re: community project: software aspects.
Post by: hazzer123 on May 06, 2009, 05:22:48 AM
yeap exactly :)
Title: Re: community project: software aspects.
Post by: SmAsH on May 06, 2009, 05:41:22 AM
wow, that could be a real advantage! but it does make things a bit more complicated...
and btw, i love your sig, but still don't really get it ;D
Title: Re: community project: software aspects.
Post by: Webbot on May 06, 2009, 06:59:15 PM
Don't want to be a total downer  ::) but I think there is a slight danger of running before walking and over complicating stuff.

So I'm going to act as 'devils advocate' here - and you may just say 'no worries its all sorted'.

Multiple masters sounds ok in theory- but there are complexities.

If you now have sensors that are masters then it means that 'primary' masters, such as your main cpu, also need to be slaves (to receive the signal from the master sensor). I'm just worried that if you go with unlimited masters and slaves that there could be so much contention on the bus, as everything is trying to talk to everything else, that things start to fall apart. Tower of Babel.

If all sensors are now going to be augmented with an I2C interface etc then you are adding lots of hardware, and cost, to every sensor so as to relieve the master controller of the work. ie for a sonar module you still need to buy the sonar device (ping,devantech,etc) and then a module to plug it into. So for a simple robot it will be over-cpu'd and over-priced. And all this extra stuff is just to make coding easier (ok and mechanical connections). So a newbie has to pay a lot more money for an easy system.

Since library software can make all sonars, all motors, etc appear the same to the application developer then I wonder why you need to add all this extra I2C hardware and cost.

Of course a single CPU may struggle to cope with lots of servos, motors, sensors etc. But, if that is the problem,  then the alternative is to say: have one standard cpu board, running standard libraries, that can interface to all the servos, motors, sensors without extra hardware - and then just use I2C to link multiple cpu boards. So there is only one master 'cpu' board that runs the main program, but it can delegate work to other slave boards. Since there is only one board design then it would be easy to make them stackable.

That way you only have to design a single cpu board that is capable of being the one and only I2C master or as a slave - and servos/motors/sensors can plug into any of them. Must be more efficient than designing a brand new board for every sensor, motor controller etc under the sun.

Thats put the shark in with fishies..... ;D

Title: Re: community project: software aspects.
Post by: dellagd on May 06, 2009, 07:05:35 PM
I agree with you
but I do See what multi master advantages there are.
but it seems like multimaster makes things WAY more complicated.
but if we can pull of the coding it seems that we would have something resembling a milticore processor
Title: Re: community project: software aspects.
Post by: Webbot on May 06, 2009, 08:18:36 PM
My suggestion is 'multi-core' by delegating functionality to other cpu boards. The cpu boards can talk to devices (sensors etc) in their normal way - no need to add I2C to augment other devices.

Each cpu board has zero-or-one parent (master) board and zero-or-many child (slave) boards. Bit like a folder/directory structure on your computer.

Devices may be added to any board. ie a board may use some devices and may delegate work to child boards.

So you could have a 'primary motion' board that has no sub-boards but can talk to a motor controller to control, say, 2 motors with encoders to move in a straight line.

Its parent board could be a 'primary reflex' board that has some bump switches and/or sonars. When told by its parent board to 'go fwd' then it tells the child 'primary motion' board to go fwds but reads the switches/sonars to take evasive action when necessary irrespective of what its own parent board is asking it to do.

The top level board runs your main program which could be some kind of goal seeking app. It may have other boards, beyond the primary reflex board, such as a compass or gps to read inputs from and then tells the 'primary reflex' board to travel in a certain direction - but that board will override the command if it has, or is about to, run into something.

This structure means you could use a buffered TTL RS232 link between boards and so you could hook up any board to your computer to issue commands to it, and its child or descendent boards. Once debugged you know that node in the tree, and below, are ok so now you do the same with the level above until you get to the top level - ie the whole network of boards is debugged.

This is hard to do in I2C as PCs cant do it - without expensive USB/I2C cards.

Although UARTs are slower than I2C then the difference is that each board is a 'brain' and so the amount of comms with its parent is much less and quicker. Whereas, as I understand it, the current community spec is all about a central CPU talking to individual sensors - ie the only distributive processing is to handle the io with each sensor. The main CPU still has to run the whole intelligent part of the program. Whereas my design means that the main CPU board can delegate entire tasks to child boards.
Title: Re: community project: software aspects.
Post by: Asellith on May 06, 2009, 11:59:33 PM
@Webbot

   The I2C bus design is very open ended. The point is not to create a robot or some complex multi core design. The point is to make a free form module system that can be as complex or as simple as needed. To make something slightly more complex then the $50 robot with your system will be way over kill. The main point of the project is to create a standard that creates boards that are slightly more complex individually then the $50 robot but still inside the grasp of a noob. This will let then quickly develop more and more complex robots using things like GPS and LCDs that are really complicated but the construction is simple. The flip side is to have the system support a structure like your talking about for more advanced users. If we design a cheap USB to I2C module then connection to a computer is possible and the computer can then talk directly to every board master or slave. Your idea would restrict communication to tiers and make things more and more complex as peices are added. Not to mention a really strict communication protocol to keep things in line. The simple idea is to have one central "brain" to control the entire project. This does not need to be the case however. You can layer the entire thing to a grand scale. Eventually the bus will be over run and speed would need to be increased or the max capacitance of the bus reach. If I remember that is 400 pf.

If designed properly the primary motion board would be the motor controller module. This module would come with 2 motor controllers built in but be expandable to several others. The reflex board would be its own sensor module and take in the information needed from the sensor and process it according to the main brains instructions. So the master brain would say tell me when something is within 15 cm of your sensors. Then the reflex board waits and sends an alert when something enters that range. On the flip side a second controller that is running a mapping program can ask the same board for sensor updates on a more regular basis and compile them into a map. Then when the main brain needs to retrace its steps it asks the mapping board to give it a direction to turn in or in a more complex method it can say I need to return to coordinates 25, 40. To the mapper takes control of the motor controller and begins moving that way.

A uart system would require a detailed architecture developed and programming and that would remove flexibility. With the I2C system you eliminate the need for a defined structure. Slap all the boards together and your main board or if needed several main boards can all talk to everyone on the bus. The UART system you defined would be really hard to do on a small scale. It would work for a massive system but its the small one or two modules systems that are going to be built the most. However the I2C system allows for the existence and easy use of both the massive system and the smaller one.

I guess my vision of this system is that the main brain is used for higher functions and decision making. If programmed correctly the main board only needs to tell the lower modules a set of commands at startup. Then as things change it can change those commands as needed. Really the entire project rises and falls on how well the modules are programmed. Thats where we who have more experience come in. But a noob who just built the $50 robot is all excited and starts buying several new boards and connects them all together, he will be able to program is robot in a simple way to do simple things but as he grows he can build more and more complex systems without buying a ton of new parts.

Also a note that some might not be getting. I do think a slave will be a rare thing in this system. An example of a slave would be a motor controller. Something that is really just dumb. However any module that takes data in would need to be a master. If it needs to make a decision then it must be a master so it can tell others that decision. Even a motor controller with an encoder can still be a slave because it will store the data and follow directions given it. Like Move 20 inches forward. But if a mapping module needs to ask it how far have we gone it can respond with the answer stored in its memory.
Title: Re: community project: software aspects.
Post by: SmAsH on May 07, 2009, 12:38:46 AM
from what you guys have said i understand that there should be one "main" master eg the axon but you can have other masters that don't run main programs eg sonar, sharp ir...

we do not want this project to get over complicated before we start...

for the time being i think we should stick to one "main" master controller instead of more as this would make my brain go like an egg in the microwave...

i have my exams right now, so for the next week or two im going to be studying my ass off to get good marks...
because in my family good marks=money for me... well $20 or so dollars... but its still good ;D

i have all the stuff i need to etch some boards so i may do that next time i take a break from studying...
Title: Re: community project: software aspects.
Post by: dunk on May 07, 2009, 03:20:56 AM
hey guys,
the communication specs we came up with last year when we were first discussing this allowed for communication with either i2c or UART.
http://docs.google.com/Doc?id=ddp2r5j8_21dgt72qgz&hl=en (http://docs.google.com/Doc?id=ddp2r5j8_21dgt72qgz&hl=en)

presumably only some modules would need to be able to connect to a UART. (eg, an i2c to UART bridge for connecting your device to a PC.)
most modules would not have a UART so those modules would not need the more complex code to use it.
i do believe it is necessary to allow for UARTs in the communication standard though. better to have it in the standard than have them included as ugly one off hacks later.

i am not saying that document on communications is the right way to go.
indeed, i think is may be too complicated which will frighten people away from wanting to implement it.
feel free to abandon it and come up with something else if you think that is best.

what *is* needed in a communication standard is
1. a way to assign every module with an address and
2. for the modules with more than one port (eg, an i2c port and a UART) some way of telling that module which port incoming data should go to.



as for multimasters on the i2c bus, all the i2c multimaster code already exists in Atmel (for AVRs) and Microchip (for PICs) application notes so there is very little extra work implementing it.
if you want an example, the module template already has this built in.
http://www.societyofrobots.com/member_tutorials/node/69 (http://www.societyofrobots.com/member_tutorials/node/69)
that example can do multimaster and communicate over both the UART and i2c.

as long as all masters on the bus can handle multimasters it allows users to decide for them selves if they want to use them or not.
if your application needs multimasters then you can use them. if you only need a single master then you only need to have one.

personally i would try to poll devices for data from a single master wherever possible as this makes writing the control program more simple but i can see why sometimes it would be beneficial to push data from a sensor to the module running the main control program. eg, bump sensors on the front of a bot should stop the drive motors immediately. this would require the sensor to also be on a master module.


anyway,
enough from me.
if you want direct advice on any of this feel free to ask but after the 15th of May it might take me a while to get round to replying.
(last day at work is the 15th! wooohooo!!)

dunk.
Title: Re: community project: software aspects.
Post by: SmAsH on May 07, 2009, 03:32:29 AM
i agree with you on the fact that some modules should have both I2C and uart but only in the circumstance that they really need it, like your I2C-pc example. for adding uart capability to your module, for the hardware part would it be as easy as just connecting the rx, tx and gnd pins one the uc to headers and letting software do the rest?

PS: good luck with your trip ;D
Title: Re: community project: software aspects.
Post by: hazzer123 on May 07, 2009, 03:42:24 AM
Flexibility and easiness for noobs are the main objectives. The I2C bus contributes nicely to these and so i still back it. I do however see your point about the rapidly increasing cost associated with having an I2C module for each sensor. But i think it isn't totally the scenario we have created. While there could be, and probably will be, a board dedicated to handling just 1 analogue sensor, there will also be boards which handle 16 sensors. If there is a need for it, it will sooner or later be built. The idea is to have a huge array of modules, and then you just make/buy the ones which are most suitable to your application. A board with 16 IO sounds better than one with a single IO, but not if you are building a bot that requires 1 analogue sensor.

And although there may be a need for a single analogue sensor module, the need will be very small. So it would probably be a bad idea to design it before you create a high-demand module. In the initial stages, at least, we need to create a list of modules and their associated demand in order to make the platform useful as early as possible. When we do have all the most common boards built and tested, we can move to the more flowing module design method of designing to your own personal needs. So then if you need a text to speech module, design one for the platform. Now though...we need to focus.

For the software, our library should abstract from the I2C bus so that we think we are just playing around with the sensors and the actuators directly. It would be cleaner to say "left_wheel_motor.setSpeed(10)" rather than "motor_controller_board.setSpeed(motor_left, 10)".

And regarding the debugging advantages of RS232 over I2C. It would take only a simple module, or even just some software for a main controller, to output all the data on I2C to UART. It could even output only the interesting data to the computer. A USB to I2C module could be easily developed using just an AVR chip (see V-USB (http://www.obdev.at/products/vusb/projects.html)).

I think it would be great to develop some software for the arduino (and all -duinos) to make it able to communicate over our bus. It could be daunting for a beginner to have to build/buy a stack of modules. Most already have an arduino... they could use that along with one of our modules and build their collection of OSCAR boards up gradually.

Hmmm last thing, the modules should have a variety of operating modes. Amongst these should be master and slave. You're right that if everything is master, it could get confusing and messy, but then you could turn off the master mode on most of the modules, and have all your processing done more centrally. You will have the flexibility to do whatever you want. Slave modes should be default, to help the noobs. :)
Title: Re: community project: software aspects.
Post by: SmAsH on May 07, 2009, 03:57:30 AM
does there need to be any extra hardware to change between master and slave?
Title: Re: community project: software aspects.
Post by: hazzer123 on May 07, 2009, 04:02:39 AM
No. If you look at the modes of operation for the scanning sensor module, you will see there is an 'Alarm mode'. This one means it will alert you when an object comes within a certain range of the sensor. All the other modes are slave. To make a master into a slave through software, all you do is ensure it never initiates communication on the bus.
Title: Re: community project: software aspects.
Post by: SmAsH on May 07, 2009, 04:43:36 AM
ahh ok, that makes me understand the difference a bit better ;D
Title: Re: community project: software aspects.
Post by: Webbot on May 07, 2009, 07:27:03 AM
as for multimasters on the i2c bus, all the i2c multimaster code already exists in Atmel (for AVRs) and Microchip (for PICs) application notes so there is very little extra work implementing it.
if you want an example, the module template already has this built in.
http://www.societyofrobots.com/member_tutorials/node/69 (http://www.societyofrobots.com/member_tutorials/node/69)
that example can do multimaster and communicate over both the UART and i2c.

Dunk - the tutorial contains some links to Google docs - but when I click on them I get 'Page Not Found Errors'
Title: Re: community project: software aspects.
Post by: Asellith on May 07, 2009, 08:48:00 AM
Google docs documentation is here
http://docs.google.com/Doc?id=ddp2r5j8_21dgt72qgz&hl=en (http://docs.google.com/Doc?id=ddp2r5j8_21dgt72qgz&hl=en)


there are links to the other documents posted inside that document

Also a ton of information is here. http://www.societyofrobots.com/member_tutorials/node/328 (http://www.societyofrobots.com/member_tutorials/node/328)

Plus Dunks tutorial that makes all the generated documentation to date. If you have not read it please do. Also might be a good idea to browse some of the other threads on this topic.
Title: Re: community project: software aspects.
Post by: Ro-Bot-X on May 17, 2009, 06:57:54 PM
Have you guys looked at this site? It shows a problem with a multi-master TWI on AVR micros... The guy found a software workaround, just wanted to make sure it is taken into consideration. Thanks!

http://www.robotroom.com/Atmel-AVR-TWI-I2C-Multi-Master-Problem.html (http://www.robotroom.com/Atmel-AVR-TWI-I2C-Multi-Master-Problem.html)