To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.spyboticsOpen lugnet.robotics.spybotics in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / Spybotics / 337
336  |  338
Subject: 
Re: Spybot Upgrade Kit ? was Spybot Hardware Hacking
Newsgroups: 
lugnet.robotics.spybotics
Date: 
Tue, 6 Apr 2004 15:59:54 GMT
Viewed: 
7185 times
  
In lugnet.robotics.spybotics, Speedsthatbeat wrote:
Can you comment a bit on the performances in a scenario in which the PIC would
take care of data acquisition from a variety of sensors?
Which would be the max I/O speed?

Performance is an interesting question.  For the article example where I used a
Devantech SRF04 Sonar and a Sharp GP2D12 IR Rangefinder, the performance is
limited by the senors.

The SRF04 has a minimum cycle time of at least 10ms (this is the 10ms edge of
echo to start of trigger). The absolute cycle time depends on when an echo is
received.  The maximum cycle time is about 50ms.

The GP2D12, although giving a continuous analog output, updates every 50ms or so
(38.3ms +/- 9.6ms).  Polling any faster will just result in the same reading.

The PIC easily keeps up with these sensors.

The I2C bus would probably be the next limiter.  Assuming 400KHz I2C operation,
reading the same byte over and over (not very efficient), would take 48 clocks
(as long as the slave responds immediately), or 120uS.  I'd have to go back and
look at the Spybot to see exactly what clock rate it runs the I2C bus at, and
what code is generated to poll an EEPROM location.  I suspect that it doesn't
"cache" opcodes and will re-read instructions from the EEPROM as well,
increasing the polling time.

Of course, neither of these scenarios can be looked at in isolation.  Depending
on what code is executing on the Spybot, the PIC could be tied up responding to
I2C interrupts, and may not have enough time to handle sensor processing.  An
efficient method would be to figure out a resonable sensor polling rate, have a
task pull back all sensor readings in one operation (have all the sensor values
be 32 byte page aligned), then save these values in global variables on the
Spybot for other tasks to use.

On the PIC, interleaving of sensor operations helps too.  For example, trigger a
sonar Ping, read the IR rangefinder (this takes A/D conversion time), then check
to see if the echo has been received.


In lugnet.robotics.spybotics, Speedsthatbeat wrote:
I was wondering if it makes sense for you to put this in the form of a 'upgrade
kit'. I would be very interested in buying it if the price is reasonable. I
believe that I will not be the only one ....

I had considered this, but with some reservations.  After the article went out
for publication, I found out that Lego will not support the Spybot product line
past what is already in the sales channels (they're keeping the RCX, but Spybots
as we know them will be gone).  Maybe the user community can convince Lego
otherwise.

Second, it's not an easy upgrade due to the surface mount components both on the
upgrade board and removal from the Spybot.  I didn't really look forward to
remote debugging of solder problems!

I there is enough interest, I could supply the PCB and maybe a kit of parts.  It
would have to be with the understanding that it is not an easy assembly project,
and you could kill your (now unreplaceable) Spybot.

--Jay



Message is in Reply To:
  Spybot Upgrade Kit ? was Spybot Hardware Hacking
 
(...) Jay, Ok thanks. First of all: Good Job!! I have not read the article but I think the idea is very good. Can you comment a bit on the performances in a scenario in which the PIC would take care of data acquisition from a variety of sensors? (...) (20 years ago, 2-Apr-04, to lugnet.robotics.spybotics)

12 Messages in This Thread:



Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR