go away spammer

Author Topic: Community Project - Module Housing  (Read 19533 times)

0 Members and 1 Guest are viewing this topic.

Offline dellagd

  • Contest Winner
  • Supreme Robot
  • ****
  • Posts: 731
  • Helpful? 5
  • Come to the dark side... We have cookies!
    • Exodus Rocketry
Re: Community Project - Module Housing
« Reply #60 on: April 27, 2009, 02:17:53 PM »
I like the idea of having a node that is just a breadboard and I/O pins. correct me if I am wrong. I2C is like a network that allows microcontrollers to communicate with eachother?
Innovation is a product of Failure, which leads to Success.

If I helped, +1 helpful pls

I Won!
3rd place! I'm taking $100

Offline Asellith

  • Contest Winner
  • Supreme Robot
  • ****
  • Posts: 648
  • Helpful? 9
  • "I'm a leaf on the wind. Watch how I soar"
    • CorSec Engineering
Re: Community Project - Module Housing
« Reply #61 on: April 27, 2009, 04:03:40 PM »
The point of using I2C is to make it plug and play well sorta plug and play the main controller needs to be told what to do and if the programmers of the modules do the extra work and develop libraries for each then it is the MCU version of plug and play. This I/O board you want will need to be able to talk to the main controller some how. The main MCU will have a limited range of I/O on its board. Be it the axon or a whatever. An I/o Extension board is not a bad idea but it will still need an MCU to talk to the network. I/O interupts can be messy when using with a mapping program or something along those lines. But if the interupts where handled by their own I/O module and the only thing that happened would be the I/O board would take control of the bus and send info to the main controller when needed. Or if all it does is a programmed motor response then the main mcu just needs to be told it happened and it can go on mapping the room or whatever it is doing while the I/O board talks to the motor controller.
Jonathan Bowen
CorSec Engineering
www.corseceng.com

Offline SmAsH

  • Supreme Robot
  • *****
  • Posts: 3,959
  • Helpful? 75
  • SoR's Locale Electronics Nut.
Re: Community Project - Module Housing
« Reply #62 on: April 27, 2009, 04:32:47 PM »
i am really happy to take a look at uart, but it just seems more complicated for beginners to get a grasp on.
about the programmer issue, i really think usb should be a standard or some form of communication that lets usb take hold, maybe a 4pin header the user can plug into that has usb on the other end? most people don't really want to buy a programmer as the good ones are a bit expensive or they don't have a serial/parallel port...
Howdy

Offline dellagd

  • Contest Winner
  • Supreme Robot
  • ****
  • Posts: 731
  • Helpful? 5
  • Come to the dark side... We have cookies!
    • Exodus Rocketry
Re: Community Project - Module Housing
« Reply #63 on: April 27, 2009, 05:02:18 PM »
a MCU can also be a slave on a  I2C network right?
Innovation is a product of Failure, which leads to Success.

If I helped, +1 helpful pls

I Won!
3rd place! I'm taking $100

Offline Asellith

  • Contest Winner
  • Supreme Robot
  • ****
  • Posts: 648
  • Helpful? 9
  • "I'm a leaf on the wind. Watch how I soar"
    • CorSec Engineering
Re: Community Project - Module Housing
« Reply #64 on: April 27, 2009, 05:07:01 PM »
Yes actually most modules will be slaves. There will be very few modules that will not have some sort of MCU on them.
Jonathan Bowen
CorSec Engineering
www.corseceng.com

Offline SmAsH

  • Supreme Robot
  • *****
  • Posts: 3,959
  • Helpful? 75
  • SoR's Locale Electronics Nut.
Re: Community Project - Module Housing
« Reply #65 on: April 27, 2009, 06:31:59 PM »
so, the "master" is the  device that is allowed to request info from the other devices. a "slave" not not allowed to request anything but only reply to a master. this is why slave devices are much easier to code because all thy have to do is the dirty work and reply to the master. and i thought for i2c all modules would have to have a microcontroller of some sort if they weren't pre-bought?
Howdy

Offline dellagd

  • Contest Winner
  • Supreme Robot
  • ****
  • Posts: 731
  • Helpful? 5
  • Come to the dark side... We have cookies!
    • Exodus Rocketry
Re: Community Project - Module Housing
« Reply #66 on: April 27, 2009, 06:43:39 PM »
I am pretty sure you are correct smash
Innovation is a product of Failure, which leads to Success.

If I helped, +1 helpful pls

I Won!
3rd place! I'm taking $100

Offline TrickyNekro

  • Contest Winner
  • Supreme Robot
  • ****
  • Posts: 1,208
  • Helpful? 15
  • Hardware and Firmware Designer
    • The Hellinic Robots Portal
Re: Community Project - Module Housing
« Reply #67 on: April 27, 2009, 07:29:14 PM »
having more than one master on the bus requires protocol.... that's for sure...
And implementing a com protocol isn't for absolute vodkas....... :P
For whom the interrupts toll...

Offline Asellith

  • Contest Winner
  • Supreme Robot
  • ****
  • Posts: 648
  • Helpful? 9
  • "I'm a leaf on the wind. Watch how I soar"
    • CorSec Engineering
Re: Community Project - Module Housing
« Reply #68 on: April 27, 2009, 08:49:35 PM »
I2C is a protocol. It inherently handles multi-master. Each unit master and slave have an address. Only difference between a master and a slave is the ability to take control of the bus. Each node waits for the bus to be clear and then takes control by initializing the start bit sequence. Then it transmits its messages and waits for its response. The slave just wait for a master to tell them what it needs them to do and they send back an ACK with or without data depending on what the slave is doing. Any master can take control as long as the bus is not being used.
Jonathan Bowen
CorSec Engineering
www.corseceng.com

Offline SmAsH

  • Supreme Robot
  • *****
  • Posts: 3,959
  • Helpful? 75
  • SoR's Locale Electronics Nut.
Re: Community Project - Module Housing
« Reply #69 on: April 28, 2009, 03:08:24 AM »
so, to sum it up. the reason I2C is a good interface to have is because its faster than just using I/O pins because the other microcontrollers (slaves) do all the time consuming and repetitive tasks then let the master take care of the decision making?
and, psssst guys this topic is about the module housings! not communication protocol. if you see needed start a new topic about that ;)
Howdy

Offline TrickyNekro

  • Contest Winner
  • Supreme Robot
  • ****
  • Posts: 1,208
  • Helpful? 15
  • Hardware and Firmware Designer
    • The Hellinic Robots Portal
Re: Community Project - Module Housing
« Reply #70 on: April 28, 2009, 05:08:04 AM »
Even though you "have" a I2C protocol it's not the protocol I talk about...
Imagine multiple masters co-existing in a same bus....

There MUST be a router that sets the timeslots for each to speak, then the speaker should inform
how much he will speak and with who....

I2C is a method of transmitting data, not a way to behave in public places...
For whom the interrupts toll...

Offline hazzer123

  • Supreme Robot
  • *****
  • Posts: 460
  • Helpful? 3
Re: Community Project - Module Housing
« Reply #71 on: April 28, 2009, 05:23:15 AM »
Multi-master I2C requires no router or time-slotting.

Either one master starts transmitting and the others be quiet, or multiple transmitters start transmitting at the same time and they have a 'race'. The winner of the 'race' is the master which sends out a message with the most zeros (ie the lowest message byte). Each of the other masters realise that they didn't win the 'race' and then they wait their turn.
Imperial College Robotics Society
www.icrobotics.co.uk

Offline TrickyNekro

  • Contest Winner
  • Supreme Robot
  • ****
  • Posts: 1,208
  • Helpful? 15
  • Hardware and Firmware Designer
    • The Hellinic Robots Portal
Re: Community Project - Module Housing
« Reply #72 on: April 28, 2009, 05:27:40 AM »
Am I confusing something or data collision is a hole in water for every device???
For whom the interrupts toll...

Offline SmAsH

  • Supreme Robot
  • *****
  • Posts: 3,959
  • Helpful? 75
  • SoR's Locale Electronics Nut.
Re: Community Project - Module Housing
« Reply #73 on: April 28, 2009, 05:28:55 AM »
Am I confusing something or data collision is a hole in water for every device???
explain?
Howdy

Offline hazzer123

  • Supreme Robot
  • *****
  • Posts: 460
  • Helpful? 3
Re: Community Project - Module Housing
« Reply #74 on: April 28, 2009, 05:35:05 AM »
ok the data lines are pulled up. So to clock data out, the devices either let the line go and it will be pulled up to +ve (for a 1 bit), or they pull the line down to negative (for a 0 bit).

Say master 1 wants to transmit byte 00101001 and master 2 wants to say 00100101

First both say 0 - they have no way of telling that there is another master on the line so they both carry on.
Again both transmit a 0 - again no way of detecting another master
Both transmit 1 - still no way
Both transmit 0 - "
Master 1 transmits 1 letting the line go free, master 2 wants to transmit a 0, so it pulls the line to ground. The line actually is in '0' state. Now master 1 can detect another master on the line. So it quits and waits its turn. Master 2 is oblivious to this and carries on happy.

The byte which is transmitted is 00100101.

The nice thing is, if both transmit the same bytes, they never realise and they don't need to realise. So its doubly quick compared to a time sharing system :D But thats a very extreme case...
Imperial College Robotics Society
www.icrobotics.co.uk

Offline dellagd

  • Contest Winner
  • Supreme Robot
  • ****
  • Posts: 731
  • Helpful? 5
  • Come to the dark side... We have cookies!
    • Exodus Rocketry
Re: Community Project - Module Housing
« Reply #75 on: April 28, 2009, 05:38:20 AM »
I am confused here too
of course it would be better if they just had a race (I rooting for master #2  :D )
but I think Tricky is right. 2 signals can't travel on the same line as far as I know.
but hazzer could also be right. I just don't know enough on the subject to make a definitive answer. also we really need to move this conversation. Right now I am making a new topic "SoR Project - protocol".

EDIT: now I get it. makes sense. I see what you mean hazzer. I post just as you were :P
« Last Edit: April 28, 2009, 05:40:48 AM by dellagd »
Innovation is a product of Failure, which leads to Success.

If I helped, +1 helpful pls

I Won!
3rd place! I'm taking $100

Offline SmAsH

  • Supreme Robot
  • *****
  • Posts: 3,959
  • Helpful? 75
  • SoR's Locale Electronics Nut.
Re: Community Project - Module Housing
« Reply #76 on: April 28, 2009, 05:40:23 AM »
so your saying there would be no problem with them interfering with each other?
and as i said before this thread is called "module housing" for a reason! http://www.societyofrobots.com/robotforum/index.php?topic=7778.0
post this kind of stuff there!
dellagd, imagine two fat guys (masters) running to get into an elevator (line) which ever one gets in first gets in... the other fat guy realizes that the other guy is in the elevator and waits for it to come back (finish transmitting). sorry, needed an easy way to remember...
EDIT: oh shiz, dellagd beat me to it
« Last Edit: April 28, 2009, 05:44:10 AM by SmAsH »
Howdy

Offline dunk

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 1,086
  • Helpful? 21
    • dunk's robot
Re: Community Project - Module Housing
« Reply #77 on: April 28, 2009, 06:51:00 AM »
ok the data lines are pulled up. So to clock data out, the devices either let the line go and it will be pulled up to +ve (for a 1 bit), or they pull the line down to negative (for a 0 bit).

Say master 1 wants to transmit byte 00101001 and master 2 wants to say 00100101

First both say 0 - they have no way of telling that there is another master on the line so they both carry on.
Again both transmit a 0 - again no way of detecting another master
Both transmit 1 - still no way
Both transmit 0 - "
Master 1 transmits 1 letting the line go free, master 2 wants to transmit a 0, so it pulls the line to ground. The line actually is in '0' state. Now master 1 can detect another master on the line. So it quits and waits its turn. Master 2 is oblivious to this and carries on happy.

The byte which is transmitted is 00100101.

The nice thing is, if both transmit the same bytes, they never realise and they don't need to realise. So its doubly quick compared to a time sharing system :D But thats a very extreme case...
hu?
sorry Hazzer but no.
in a multimaster i2c system a master that wants to take control of the bus takes control of the SCL line.
if the SCL line is high and does not have another master's clock pulse on it then any master can presume the bus is free.
any master can pull the SCL line low for a clock pulse signaling to all other masters that the bus is busy.
on vary rare occasions 2 masters might take control of the bus at exactly the same time so testing for this must also occur.

TrickyNekro, i think this answers your questions too.


dunk.

Offline hazzer123

  • Supreme Robot
  • *****
  • Posts: 460
  • Helpful? 3
Re: Community Project - Module Housing
« Reply #78 on: April 28, 2009, 06:55:46 AM »
Hmm u sure? I have seen the system i described in a different protocol. And from this page it seems the same.

Ahh well, i guess the important thing is that it supports Multi-master and is implementable.

EDIT: maybe the thing i read is the way to sort out the rare condition where they take control at the same time.

EDIT2: Oh.. here is some more info - http://www.esacademy.com/faq/i2c/general/i2carbit.htm -  it's called arbitration -

 I'm quite sure now that i was correct...
« Last Edit: April 28, 2009, 07:07:01 AM by hazzer123 »
Imperial College Robotics Society
www.icrobotics.co.uk

Offline dunk

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 1,086
  • Helpful? 21
    • dunk's robot
Re: Community Project - Module Housing
« Reply #79 on: April 28, 2009, 07:15:45 AM »
EDIT2: Oh.. here is some more info - http://www.esacademy.com/faq/i2c/general/i2carbit.htm -  it's called arbitration -

 I'm quite sure now that i was correct...
just to be clear,  your EDIT2 is correct.
yes this is one way i2c multi-masters can deal with the *rare* cases when they both end up in control of the bus at the same time.
with a properly operating system this will hardly ever happen.

in *normal* cases the multi-masters just monitor the SCL line to see if the bus is free.
monitoring the data on the bus is not required.


dunk.

Offline hazzer123

  • Supreme Robot
  • *****
  • Posts: 460
  • Helpful? 3
Re: Community Project - Module Housing
« Reply #80 on: April 28, 2009, 07:21:16 AM »
Either one master starts transmitting and the others be quiet, or multiple transmitters start transmitting at the same time and they have a 'race'.

Im pretty sure i was correct :P Although my language was slightly fuzzy...

Anyway, i say we should monitor the data on the bus, i.e. always check that when you write a 1 to it, check that it is a 1. Its not a big deal in terms of program complexity and despite the face that its unlikely... its possible and easy to fix. I'd like to cross out as many chances of failure as possible.

And people always seem to get back luck when reliability matters most :P
Imperial College Robotics Society
www.icrobotics.co.uk

Offline Weird Fishes

  • Full Member
  • ***
  • Posts: 60
  • Helpful? 0
Re: Community Project - Module Housing
« Reply #81 on: April 28, 2009, 08:24:56 AM »
Just to be clear, we've abolished the idea of cubes, correct? I see it this way:

I want to build an autonomous robot that drives around and looks out for obstacles and tries to get to a certain GPS coordinate. Thing is: I need 142 IR sensors (exaggeration for effect), a GPS, 2 cameras, and 4 main MCU's for data crunching(again exaggeration for effect).

With this system, I could go to SoR, get the schematics and parts lists for those modules, send the schems in to a fab house and get myself 142 IR sensor boards, Gps, etc, etc. Then I can assemble all those PCB's and install the boards on my RC car chassis. Quick and painless (except for the assembling of 142 IR sensor boards ;)), plus I have code libraries.

With cubes this scenario is ridiculous. first, I'd have to buy all the cubes, which seem redundant for 99% of applications anyway, and I might as well order the boards too, since I'm getting that product anyway. Hey, my budget just quintupled!? What happened!


Cool, but impractical, and unfitting for this application. This is better served for an individual project, or a product, which is not what we're doing.

No offense to anyone, but I just feel it goes against all of our design goals.

Offline Asellith

  • Contest Winner
  • Supreme Robot
  • ****
  • Posts: 648
  • Helpful? 9
  • "I'm a leaf on the wind. Watch how I soar"
    • CorSec Engineering
Re: Community Project - Module Housing
« Reply #82 on: April 28, 2009, 09:12:33 AM »
I agree. Cubes would be cool for a single project but does not meet the goals of this project. The cubes would work better if every module was a single unit with its own set of sensors/equipment that was standardized and you developed it like a hive system and they all worked together. Now if someone wants to design a housing that could connect the individual modules together and protect them as well as be expandable like the modules then more power to them.
Jonathan Bowen
CorSec Engineering
www.corseceng.com

Offline hazzer123

  • Supreme Robot
  • *****
  • Posts: 460
  • Helpful? 3
Re: Community Project - Module Housing
« Reply #83 on: April 28, 2009, 09:36:28 AM »
We should definitely take the idea of physical modularity aswell as electronic modularity from the cube design. So all our modules should fit on a 1inch grid, and have holes at each point in the grid to allow stacking of PCBs using standoffs. Of course 1 inch is just an arbitrary choice that can change. I think sth on the scale of a few cm is nice and we should look at making a final decision ok these standards soon.
Imperial College Robotics Society
www.icrobotics.co.uk

Offline dellagd

  • Contest Winner
  • Supreme Robot
  • ****
  • Posts: 731
  • Helpful? 5
  • Come to the dark side... We have cookies!
    • Exodus Rocketry
Re: Community Project - Module Housing
« Reply #84 on: April 28, 2009, 12:31:43 PM »
woah woah woah
I want a yes or a no or if it is inbetween give me a reason and what it is
are we doing cubes or not!
Innovation is a product of Failure, which leads to Success.

If I helped, +1 helpful pls

I Won!
3rd place! I'm taking $100

Offline Weird Fishes

  • Full Member
  • ***
  • Posts: 60
  • Helpful? 0
Re: Community Project - Module Housing
« Reply #85 on: April 28, 2009, 12:32:43 PM »
My vote is a big fat No.

Offline hazzer123

  • Supreme Robot
  • *****
  • Posts: 460
  • Helpful? 3
Re: Community Project - Module Housing
« Reply #86 on: April 28, 2009, 12:34:29 PM »
Mine is a no too.
Imperial College Robotics Society
www.icrobotics.co.uk

Offline dellagd

  • Contest Winner
  • Supreme Robot
  • ****
  • Posts: 731
  • Helpful? 5
  • Come to the dark side... We have cookies!
    • Exodus Rocketry
Re: Community Project - Module Housing
« Reply #87 on: April 28, 2009, 12:37:02 PM »
ok now that I think about it my vote is a no too. cubes not as flexable.
Innovation is a product of Failure, which leads to Success.

If I helped, +1 helpful pls

I Won!
3rd place! I'm taking $100

Offline HyperNerd

  • Robot Overlord
  • ****
  • Posts: 139
  • Helpful? 5
  • N3rd1n80r
Re: Community Project - Module Housing
« Reply #88 on: April 28, 2009, 02:18:09 PM »
I agree with Asellith, cubes are a good idea, but just not for this project.
There are 10 types of people in the world - those who understand binary, and those who don't.

Offline SmAsH

  • Supreme Robot
  • *****
  • Posts: 3,959
  • Helpful? 75
  • SoR's Locale Electronics Nut.
Re: Community Project - Module Housing
« Reply #89 on: April 28, 2009, 02:19:44 PM »
my vote has always been a no for this project ;D
Howdy

 


Get Your Ad Here

data_list