Community Project: Scanning sensor module

[Asellith]

Master just means it can take control of the bus and send a message. Slaves have to be told what to do. They wait for a master to send them a command and then they do what it tells them and either send back an acknoledgment that they did it or they give the master the data it asked for I.E. sensor data. Inside the OSCAR system an axon can be a master or a slave. That depends on programming.

[dellagd]

I know that
I was saying that the axons powers would come in handy as a master

[SmAsH]

axon doesn't really have much more in the area of powers for I²C as an roboduino... roboduino has a faster processor, little less memory and $90 cheaper...
and PS: this isn't the thread for this stuff. we need to keep it organized or it may fail again

[Razor Concepts]

Axons would be a little too pricy.

Does a default "master" board have to be part of the project? Maybe one can be made but it would be great to allow different MCUs with I2C to communicate with the slave boards. This way people with experience can use whatever MCU they are familiar with to control everything.

[SmAsH]

nope, axon was just a candidate because it was made by the admin..
any mcu with I2C should do fine..
hell even an atmega8 would do...

[Ro-Bot-X]

axon doesn't really have much more in the area of powers for I²C as an roboduino... roboduino has a faster processor, little less memory and $90 cheaper...
and PS: this isn't the thread for this stuff. we need to keep it organized or it may fail again

Axon has the same speed as Roboduino, 16MHz!

[dellagd]

maybe admin would give us a discount since this is SoR OSCAR

[dellagd]

heres an idea
dont know if this is possible, but could we make a mod (master) that has the ability to take inputs from a computer via a usb?
then we could make a simple program that has access to the USB port and via that port the I2C master gets signals, and based on thoes signals the master can carry out operations, be it changing a slaves address.

yes its called the axon 

this is why I thought we should use the axon if you didn't catch this part

[Asellith]

Ok just to clarify the OSCAR was designed to work with the Axon. We chose our PCB designs to make it fit nicely with it because the dimmensions of the board don't matter that much but tailoring it to the axon benefits a lot of people.

NOW: The axon is not the only main controller possible. This system is very flexible. The main controller does not have to fit into the standard. I hope to see several boards that comply to the standard and include things like PICAXE, PIC, and even BASIC boards. The possibilities are endless. You could even use a computer. If you have a roboduino then use it. The only stipulation is you need to talk on the I2C bus. For some devices (I.E. Computer) an interface board would be needed.

The standard is designed to be really loss for a reason. We want everything to talk nice and fit nicely together but in the end the sky is the limit. If you want to see a feature then build it. The more modules we see the better. I would even like to see several versions of the same modules using different tech. Basically a AVR and a PIC version because most people stick with one or the other.

Just a side note. for a really complex design the system could support several controllers. So you could be processing video on a laptop while an axon controls sensor inputs and navigation with a few smaller units coordinating servos or something.

[hazzer123]

We should have variable length registers (whole number of bytes only though obviously). To execute a command, you just write to a register that has a length of 0 bytes. This should be standardised across the whole platform.

Examples of 0 byte length registers are "Save user settings to EEPROM" and "Reset module".

I think that, for thoroughness, the modules should have registers which contain the firmware revision number, a module ID (a unique number we give to each of the modules) and a module name (~16 byte ASCII null-terminated string which the user can overwrite).

More specific to this Scanning sensor module -
I think the storage of multiple look up tables for each possible sensor is silly. Changing of the sensor connected to the module will happen infrequently and so it is a waste to store the data. It would require an extra external EEPROM chip, and that is just unnecessarily complex. Instead the user will just have to use I2C or their programmer to send and store a single LUT on the MCU's internal EEPROM.

Another (closely related) idea was the module's own internal conversion between units (volts, cm, inches...). This is now unnecessary since if the user wants to convert to inches (i can't ever see them needing to do this while the robot is running anyway) then they just unload a new LUT to the module.

This module should also support sensors which output a pulse where the width is related to the sensor reading.

Do you think that LUTs are a good idea for the sensor data conversion? Or do you think we could use some more maths instead? Maybe we could approximate sensor characteristics with a polynomial. The ATTinyx5 series has 2 cycle multiply so this would be easily achievable. And all we would have to store in the EEPROM is a few coefficients. Actually i will look into this aswell, seems sensible

I will change the spreadsheet i posted earlier and re-publish it soon.

EDIT: Ooops i read the wrong datasheet. The ATTinyx5 series don't have hardware multipliers, ill have a look at the software implementations and see if approximating sensor characteristics is still possible with power series.

[fiflak666]

hi guys, you're not the first who tries to build "Scanning sensor module"

I know two amateur-made robots that use this kind of stuff, both from Poland and both minisumo type

- Hunter
http://www.dioda.com.pl/forum/topics7/robot-minisumo-lowca-vt1756.htm
Robot Challenge 2009 Wien Łowca / Hunter 141 part1

- and mine, KISS 2 (still under construction); mine uses Atmega16, two Tower-Pro servos, two SHARP sensors and SPI/UART interface; looks like this:

[Asellith]

Yes but we are the first to make it comply with a standard that hundreds of future modules will comply with

[SmAsH]

yep, check out the original thread in the misc section...

[dellagd]

I think this project could make it big, like a revolution in robotics

[SmAsH]

that's what were hoping for

[hazzer123]

Ok, so i have build a circuit using stripboard and im going to create software for the first prototype over the next few weeks (i have exams to study for too... so not much time to dedicate to this project right now).

It seems that for now this module will have to be a slave only, until i can either find code for the ATTiny85's USI which supports I2C with multimaster arbitration, or i write my own. The USIDC (Data Output Collision) bit in the USISR register may make this easy. But anyway, for now slave only will be fine and it should be easily extend-able..