Author Topic: community project: software aspects. (Read 9743 times)

Asellith · « **Reply #30 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?

hazzer123 · « **Reply #31 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.

I2C address (1 byte long) - The I2C address of the individual module is stored in the 7 least significant bits of this register. Each module has a default I2C address of 0xBB.
I2C settings (1 byte long) - The least significant 3 bits of this register will specify the speed of the I2C communcation. 000 is low speed (10 kbit/s), 001 is normal speed (100 kbit/s), 010 is high speed (400 kbit/s). The remaining bits are reserved for future use.,
Device name (16 bytes long) - An array of ASCII characters creating a string which describes the modules. An example of a good name would be "Front Left IR". Any remaining bytes in the register should be filled with NULL characters.
I2C Warning register (4 bytes long) - If the module detects something has gone wrong, then an error code will be placed in the most significant byte, and some relevant data (specified in the warning's documentation) will be in the remaining 3 bytes. The warning will not be overwritten by another warning until a master clears the warning register. This register is also used for non-communication related errors.

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

I think that's it.

What do you think?

Asellith · « **Reply #32 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.

hazzer123 · « **Reply #33 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 (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.

dellagd · « **Reply #34 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.

SmAsH · « **Reply #35 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...

hazzer123 · « **Reply #36 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

SmAsH · « **Reply #37 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?

hazzer123 · « **Reply #38 on:** May 06, 2009, 05:22:48 AM »

yeap exactly

SmAsH · « **Reply #39 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

Webbot · « **Reply #40 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.....

dellagd · « **Reply #41 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

Webbot · « **Reply #42 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.

Asellith · « **Reply #43 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.

SmAsH · « **Reply #44 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

i have all the stuff i need to etch some boards so i may do that next time i take a break from studying...

dunk · « **Reply #45 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

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
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.

SmAsH · « **Reply #46 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

hazzer123 · « **Reply #47 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).

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.

SmAsH · « **Reply #48 on:** May 07, 2009, 03:57:30 AM »

does there need to be any extra hardware to change between master and slave?

hazzer123 · « **Reply #49 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.

SmAsH · « **Reply #50 on:** May 07, 2009, 04:43:36 AM »

ahh ok, that makes me understand the difference a bit better

Webbot · « **Reply #51 on:** May 07, 2009, 07:27:03 AM »

Quote from: dunk on May 07, 2009, 03:20:56 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
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'

Asellith · « **Reply #52 on:** May 07, 2009, 08:48:00 AM »

Google docs documentation is here
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

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.

Ro-Bot-X · « **Reply #53 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

News:

Author Topic: community project: software aspects. (Read 9743 times)