Author Topic: Community Project: Scanning sensor module (Read 12902 times)

hazzer123 · « **on:** April 28, 2009, 06:34:08 AM »

Ok I guess ill start off. The module i will first design is a Scanning Sensor Module (SSM). It will control a servo and take readings from an analogue sensor (Sharp IR for example).

I will try to document the module making process as thoroughly as I can, but this is also my first time formally designing and building, so be patient

+-------------------------+ Sensor ----analogue data----->| Scanning Sensor |<----I2C data---->[Other modules] Servo <---PWM data------------| Module | +-------------------------+

I think the SSM should have a multiple modes of operation.

Continuous Scanning mode - Module scans all the time and just transmits data from the most recent scan. The advantage of this is the reduced waiting time between a master asking for data, and a master getting data because the scan has already happened
Requested Scanning mode - Module scans only when data is requested. Data is requested, readings are taken and read out by the module
Point and Shoot Scanning mode - Module is given an angle and it returns a reading with the servo set at this angle. This is useful when more processing needs to be done on the main MCU
Following mode - Module locks the sensor onto a target and then reports back the angle where the target is found

They kind of data transferred on the I2C channel are instructions and data.

I think that's all for now. I'll make it on a member page later.

What do you think? Any added functionality?

Asellith · « **Reply #1 on:** April 28, 2009, 11:06:52 AM »

Looks great and a good idea/addition to the module list. One thing that sticks out to me. First with continuous scanning mode it might be better to store a lot of data and have the master get a big array dump every once in a while instead of all the time. So instead of sending data for every degree you would store all the data and send it after 180 degrees or 90 degrees. Also would be nice to have settings so that the main controller can ask for a 90 degree or 360 degree scan.

hazzer123 · « **Reply #2 on:** April 28, 2009, 11:12:16 AM »

Great thanks Asellith.

Yeah there should be a load of configurations inside the module for things like speed of scan, angle increment between readings, scan range, etc. Can you think of any others?

Asellith · « **Reply #3 on:** April 28, 2009, 12:09:14 PM »

An automatic alarm mode maybe. Something that can be set for a specific distance and then you only get an alert when something enters that range. So it can scan the front of the robot for objects. Also might be a good thing to be preprogram some common sensors into it. Also a custom one. This will just load a set value for the conversions based on the sensor used. Like if you use the EZ1 ultrasonic sensor or the sharp IR module it would work with several and then a way to custom set the value for anything else the user wants to put on it.

chelmi · « **Reply #4 on:** April 28, 2009, 12:50:50 PM »

Quote from: Asellith on April 28, 2009, 12:09:14 PM

An automatic alarm mode maybe. Something that can be set for a specific distance and then you only get an alert when something enters that range.

Maybe I missed something, but if this module is a i2c slave, then it cannot initiate a transfer to send the alert. The master will have to poll to get the warning.

hazzer123 · « **Reply #5 on:** April 28, 2009, 12:52:28 PM »

This one could be a master too

dellagd · « **Reply #6 on:** April 28, 2009, 06:02:24 PM »

I'm pretty sure masters can report to other masters, like a grand master master ( bow down to me, I am the master of all masters! (sorry I just had to put that)) also there should be a mode where it gets told to go to one position and then continually scan at that position.

Ro-Bot-X · « **Reply #7 on:** April 28, 2009, 07:46:57 PM »

Nice idea, the module could also be small size, a Tiny25/45/85 could do the trick easily. It has PWM, analog pins, TWI, all in 8 pin DIP. No hardware problems. The magic is allways in the software...

hazzer123 · « **Reply #8 on:** April 29, 2009, 02:34:58 AM »

Could this programmer (used in the $50 robot) program the ATTinyx5 series? The sparkfun page doesn't list it, but support for these chips has been recently added in the ponyprog software.

I'm a PIC guy... but these chips seem much nicer for this application.

Ro-Bot-X · « **Reply #9 on:** April 29, 2009, 05:54:25 AM »

Yes, it can program any Tiny chip if the support is added in the loader program (PonyProg).

hazzer123 · « **Reply #10 on:** April 29, 2009, 01:15:57 PM »

Oh i just had another thought... How about a mode where the data passed back has already been processed (with simple trig) into an array representing the location of detected objects.

So the scanning range could be divided up into a 10x10 grid (for example) and there could be 3 states of each cell in the grid:

Cell empty.
Cell occupied.
Cell contents unknown (cell is behind an object).

This could be nice i think.

Asellith · « **Reply #11 on:** April 29, 2009, 02:52:22 PM »

My advice on this is to get a simple version running as all the changes your mentioning involve software. So after time you can develop better firmware for the module and release it in stages. This will keep interest in the module fresh and your time to market will be shorter. That way you don't spend the next 3 months perfecting code that work for 75% of the people but some special mode is giving you trouble.

hazzer123 · « **Reply #12 on:** April 30, 2009, 04:42:17 PM »

So i've quickly made a spreadsheet of some of the various registers that will be needed in the module. - http://spreadsheets.google.com/ccc?key=rFsIT1y91nUqPNOPxtiEGaw

This is the kinda format i think we should go for in all the modules.

These tables will be placed in the manual along with detailed descriptions of what all the jargon means etc.

Trumpkin · « **Reply #13 on:** April 30, 2009, 06:41:59 PM »

It won't allow me to see the spreadsheet.

Webbot · « **Reply #14 on:** April 30, 2009, 06:54:21 PM »

Same for me. Just get access denial msg.

hazzer123 · « **Reply #15 on:** May 01, 2009, 01:28:46 AM »

Oops sorry guys. Here is the spreadsheet published as a webpage - http://spreadsheets.google.com/pub?key=rFsIT1y91nUqPNOPxtiEGaw

SmAsH · « **Reply #16 on:** May 01, 2009, 01:41:12 AM »

that looks like a great way to have things set out. should we make this standard for all modules created?

dellagd · « **Reply #17 on:** May 01, 2009, 05:36:17 AM »

can someone plz explain this, and plz excuse my noodishness

Ro-Bot-X · « **Reply #18 on:** May 01, 2009, 06:06:49 AM »

1. You should add Ping))) sensor to the sensor byte.
2. You are talking about RAM, not EEPROM, right? I sugest to save the last register configuration in the EEPROM, especially the I2C address. Someone might want to change the address if it uses more than one module, so it needs to be saved so it doesnt have to repeat the change every time. Some other registers might need the same thing.

Webbot · « **Reply #19 on:** May 02, 2009, 11:49:18 AM »

Quote from: Ro-Bot-X on May 01, 2009, 06:06:49 AM

You are talking about RAM, not EEPROM, right? I sugest to save the last register configuration in the EEPROM, especially the I2C address. Someone might want to change the address if it uses more than one module, so it needs to be saved so it doesnt have to repeat the change every time. Some other registers might need the same thing.

I2C addresses are worthy of thought. Each SoR module type should come with a unique address but you still have the problem of connecting more than one of the same type of module as they will have the same address. So should the address be configured via jumpers/switches (adds space and cost to each module but simple to use) or by having an I2C command to change the address which is then held in EEPROM. The second method is a bit more complex for noobies. If they buy two 'scanning sensor modules' and these come with a default address of 0xB0, say, then they will need to write a small program to send a command to one of the modules to reconfigure its address. However: if 'everyone' can decide on a single command that works with ALL modules then this config program could be used to re-configure ANY module - making it easier all round.

SmAsH · « **Reply #20 on:** May 02, 2009, 04:14:16 PM »

i agree that the addresses should be easily configurable for ease of use. i i don't know about the switch route....
what happens if joe wants to have 3 or 5 scanning modules...
we don't want a clunky dip switch do we?
do you guys think the slave chip on the board should be easily re-programmed?
i mean with easy access to the programming pins?

dellagd · « **Reply #21 on:** May 02, 2009, 04:50:51 PM »

hmmm....
I think the answer should be yes unless it is possible that we could program the mod through a master?
Is this even possible?

SmAsH · « **Reply #22 on:** May 02, 2009, 05:04:02 PM »

maybe... but that may be getting too complicated and veering into territory we were not meant to go into.

Asellith · « **Reply #23 on:** May 02, 2009, 05:43:48 PM »

The PCB designs for home use should have access to the programming pins. Not sure if you make a commercial version if that is necessary. Might not be a bad idea to include code to change the address of a slave. Its just a number stored in a register. So you connect it to a master with a custom program that just sends the commands to the current address and a issues a change to another address. Might be worth having someone with some decent programming skills making a utilities library that can be used to do some crazy stuff. Something we may need to include is a handshake command that basically just says yes something is attached to this address and I am a whatever. The you could scan all the addresses and get returns from the network.

Actually now that I think about it a serial to I2C and USB to I2c module would be great. Then you could debug stuff from a PC.

SmAsH · « **Reply #24 on:** May 02, 2009, 05:49:47 PM »

wouldn't a usb-I²C module just be a small chip, like the one on the roboduino/arduino? forgot the name now... but of coarse with some other stuff too. all the basics...

dellagd · « **Reply #25 on:** May 02, 2009, 06:14:09 PM »

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.

Asellith · « **Reply #26 on:** May 02, 2009, 06:18:31 PM »

Yes its called the axon.

SmAsH · « **Reply #27 on:** May 02, 2009, 07:33:14 PM »

hah! all you would need is an mcu with uart capabilities so you can hook up a usb.
two possible masters for this project could be axon for more advanced users and the $50 board with more pins accessible and a usb connection for the beginners who dont want to fork over $130.

Webbot · « **Reply #28 on:** May 02, 2009, 07:44:52 PM »

There are certainly some commercial USB to I2C boards already out there so I think your efforts would be best targeted elsewhere as I'm not sure there is much you could add.

Re issuing a ping to all boards then you can issue a 'general' request to address 0x00 which, if the I2C is set up to receive, then it can take action (so its like a 'broadcast' to all slaves). However: the slaves cannot respond to the msg (as far as I know) because they would all be trying to talk back on the bus at the same time.

dellagd · « **Reply #29 on:** May 02, 2009, 08:48:11 PM »

Quote from: Asellith on May 02, 2009, 06:18:31 PM

Yes its called the axon.

oh

cool!
maybe could the masters be Axons and the slaves be like $50 boards.

News:

Author Topic: Community Project: Scanning sensor module (Read 12902 times)