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

0 Members and 1 Guest are viewing this topic.

Offline SmAsHTopic starter

  • Supreme Robot
  • *****
  • Posts: 3,959
  • Helpful? 75
  • SoR's Locale Electronics Nut.
community project: software aspects.
« 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.
Howdy

Offline hazzer123

  • Supreme Robot
  • *****
  • Posts: 460
  • Helpful? 3
Re: community project: software aspects.
« Reply #1 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 :)
Imperial College Robotics Society
www.icrobotics.co.uk

Offline SmAsHTopic starter

  • Supreme Robot
  • *****
  • Posts: 3,959
  • Helpful? 75
  • SoR's Locale Electronics Nut.
Re: community project: software aspects.
« Reply #2 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...
Howdy

Offline dellagd

  • Contest Winner
  • Supreme Robot
  • ****
  • Posts: 731
  • Helpful? 5
  • Come to the dark side... We have cookies!
    • Exodus Rocketry
Re: community project: software aspects.
« Reply #3 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.
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: software aspects.
« Reply #4 on: April 28, 2009, 11:07:55 AM »
I2C is commonly referred to as the USB for chip to chip communications for a reason.
Jonathan Bowen
CorSec Engineering
www.corseceng.com

Offline dellagd

  • Contest Winner
  • Supreme Robot
  • ****
  • Posts: 731
  • Helpful? 5
  • Come to the dark side... We have cookies!
    • Exodus Rocketry
Re: community project: software aspects.
« Reply #5 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.
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 Webbot

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 2,165
  • Helpful? 111
    • Webbot stuff
Re: community project: software aspects.
« Reply #6 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..

Webbot Home: http://webbot.org.uk/
WebbotLib online docs: http://webbot.org.uk/WebbotLibDocs
If your in the neighbourhood: http://www.hovinghamspa.co.uk

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: software aspects.
« Reply #7 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.
Jonathan Bowen
CorSec Engineering
www.corseceng.com

Offline dellagd

  • Contest Winner
  • Supreme Robot
  • ****
  • Posts: 731
  • Helpful? 5
  • Come to the dark side... We have cookies!
    • Exodus Rocketry
Re: community project: software aspects.
« Reply #8 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?
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 Webbot

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 2,165
  • Helpful? 111
    • Webbot stuff
Re: community project: software aspects.
« Reply #9 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, adds more friendly master/slave I2C support.
Webbot Home: http://webbot.org.uk/
WebbotLib online docs: http://webbot.org.uk/WebbotLibDocs
If your in the neighbourhood: http://www.hovinghamspa.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: software aspects.
« Reply #10 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.
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 Razor Concepts

  • Supreme Robot
  • *****
  • Posts: 1,856
  • Helpful? 53
    • RazorConcepts
Re: community project: software aspects.
« Reply #11 on: April 28, 2009, 05:58:58 PM »
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.

Offline dellagd

  • Contest Winner
  • Supreme Robot
  • ****
  • Posts: 731
  • Helpful? 5
  • Come to the dark side... We have cookies!
    • Exodus Rocketry
Re: community project: software aspects.
« Reply #12 on: April 28, 2009, 06:04:00 PM »
and then that message somehow correlates to "give me your reading"?
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 Razor Concepts

  • Supreme Robot
  • *****
  • Posts: 1,856
  • Helpful? 53
    • RazorConcepts
Re: community project: software aspects.
« Reply #13 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();

Offline Webbot

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 2,165
  • Helpful? 111
    • Webbot stuff
Re: community project: software aspects.
« Reply #14 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
Webbot Home: http://webbot.org.uk/
WebbotLib online docs: http://webbot.org.uk/WebbotLibDocs
If your in the neighbourhood: http://www.hovinghamspa.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: software aspects.
« Reply #15 on: April 28, 2009, 06:46:54 PM »
sounds good to me!
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: software aspects.
« Reply #16 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 :) )
Jonathan Bowen
CorSec Engineering
www.corseceng.com

Offline Webbot

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 2,165
  • Helpful? 111
    • Webbot stuff
Re: community project: software aspects.
« Reply #17 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.
Webbot Home: http://webbot.org.uk/
WebbotLib online docs: http://webbot.org.uk/WebbotLibDocs
If your in the neighbourhood: http://www.hovinghamspa.co.uk

Offline SmAsHTopic starter

  • Supreme Robot
  • *****
  • Posts: 3,959
  • Helpful? 75
  • SoR's Locale Electronics Nut.
Re: community project: software aspects.
« Reply #18 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 :-[
Howdy

Offline hazzer123

  • Supreme Robot
  • *****
  • Posts: 460
  • Helpful? 3
Re: community project: software aspects.
« Reply #19 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.
Imperial College Robotics Society
www.icrobotics.co.uk

Offline Trumpkin

  • Supreme Robot
  • *****
  • Posts: 1,176
  • Helpful? 5
Re: community project: software aspects.
« Reply #20 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
Robots are awesome!

Offline hazzer123

  • Supreme Robot
  • *****
  • Posts: 460
  • Helpful? 3
Re: community project: software aspects.
« Reply #21 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?
Imperial College Robotics Society
www.icrobotics.co.uk

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: software aspects.
« Reply #22 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.
Jonathan Bowen
CorSec Engineering
www.corseceng.com

Offline hazzer123

  • Supreme Robot
  • *****
  • Posts: 460
  • Helpful? 3
Re: community project: software aspects.
« Reply #23 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.
Imperial College Robotics Society
www.icrobotics.co.uk

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: software aspects.
« Reply #24 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.
Jonathan Bowen
CorSec Engineering
www.corseceng.com

Offline hazzer123

  • Supreme Robot
  • *****
  • Posts: 460
  • Helpful? 3
Re: community project: software aspects.
« Reply #25 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?
Imperial College Robotics Society
www.icrobotics.co.uk

Offline Webbot

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 2,165
  • Helpful? 111
    • Webbot stuff
Re: community project: software aspects.
« Reply #26 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.
Webbot Home: http://webbot.org.uk/
WebbotLib online docs: http://webbot.org.uk/WebbotLibDocs
If your in the neighbourhood: http://www.hovinghamspa.co.uk

Offline chelmi

  • Supreme Robot
  • *****
  • Posts: 496
  • Helpful? 15
    • Current projects
Re: community project: software aspects.
« Reply #27 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)

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: software aspects.
« Reply #28 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
Jonathan Bowen
CorSec Engineering
www.corseceng.com

Offline Webbot

  • Expert Roboticist
  • Supreme Robot
  • *****
  • Posts: 2,165
  • Helpful? 111
    • Webbot stuff
Re: community project: software aspects.
« Reply #29 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  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.
Webbot Home: http://webbot.org.uk/
WebbotLib online docs: http://webbot.org.uk/WebbotLibDocs
If your in the neighbourhood: http://www.hovinghamspa.co.uk

 


Get Your Ad Here

data_list