Society of Robots - Robot Forum
Electronics => Electronics => Topic started by: omkar on January 23, 2012, 05:49:39 PM
-
Hi...
http://www.societyofrobots.com/robotforum/index.php?topic=14973.0 (http://www.societyofrobots.com/robotforum/index.php?topic=14973.0)
The above link is what I am using to get rpm values from two wheels on my robot. I plan to use this number to keep the robot going along planned trajectory and in the future work on ESC for variable friction surfaces (dreams)... here is a very basic question:
The way the setup for the rpm sensor currently works is as follows: Every time the Hall effect sensor is tripped the pin 2 on the arduino issues an interrupt and (i think) this stops the arduino from doing whatever that it was doing and it runs the rpm measurement function and then continues (hopefully) doing what it was.
I am not sure this is the best way to do this if you have only one controller doing multiple other things like driving the wheels (PWM), reading distance from sonic sensors, working on wireless (using wifi) etc.
I dont have a background in embedded systems but am prety sure thats where this bit of knowledge resides.
Any guidance on this? Any books that I should read up? dont mind reading big fat books to learn so point away....
Cheers
-
Hi,
The way the setup for the rpm sensor currently works is as follows: Every time the Hall effect sensor is tripped the pin 2 on the arduino issues an interrupt and (i think) this stops the arduino from doing whatever that it was doing and it runs the rpm measurement function and then continues (hopefully) doing what it was.
When an interrupt is seen, the controller finishes the current instruction, stores the program counter + offset to the following instruction on the stack and handles the interrupt. When done, it pops the stack and gets back to what it was doing.
The time taken from the interrupt is issued to the point where the interrupt routine actually starts is called interrupt latency (not an issue in your app though, but good to know).
I am not sure this is the best way to do this if you have only one controller doing multiple other things like driving the wheels (PWM), reading distance from sonic sensors, working on wireless (using wifi) etc.
Consider the present load on the controller. If under 80% worst case, you have ample overhead - updating a counter is a 20µs business (with sloppy programming, less than half should be easy) and then you are back - total latency might be another 2..3µs tops.
That is using assembly (or inline assembly) for the interrupts of course, as the overhead of high level programming can be murder on interrupts and on general program execution as it has to insert INT checks after each instruction, where they are needed.
Quite another (and IMO better) angle to this is using a multi-processor setup.
Controllers are cheap and comes in all sizes (like the PIC10F-family that is around $1 for 3 controllers and Atmel have copied the idea with their ATtiny10-series, but i don't know their price).
A PIC10F222 could be used to count the ticks and whenever the main controller needs to know the count, it just polls the PIC10F and gets the number(s) via IIC or similar. The PIC10F has got 3 I/O pins and a fourth input only (plus 2 supply pins of course), lending itself perfectly well to the task.
You can do the same with the Atmel ATtiny10 I'm sure, but I don't have any hands-on with them.
Either complicate your code trying to handle it all, or make your sensors smart :)
And those little buggers are good for a lot of stuff besides the obvious. Like eg. where you'd normally spank a 555 into a long term, but somewhat unreliable 2 hour timer with a handful of other components. With a PIC10F, you need no external components (bar the obligatory supply cap) unless you need more current than the 3 outputs can supply in parallel (up to ~75mA) and you get much greater accuracy than the 555 can provide when over a few minutes - even if you need time intervals of a year or more.
Everyone dabbling in electronics should keep a stock of a range of small controllers, they are so versatile, that most logic circuits and quite a few analog ones I'd have made with discrete chips back in time simply don't make sense anymore.
Any guidance on this? Any books that I should read up? dont mind reading big fat books to learn so point away....
Big fat books are too heavy to read in bed and on the can ;D
And usually, only a small part of them will be what you seek, so I'd recommend the web for starters.
These days I only buy the BFB's when they're specialized around a single or a few topics that I like to have collected in a BFB, but over the years, and before the web existed, I usually checked the books I wanted via the public library or bought on recommendations/reviews in electronics magazines.
If I was starting out today, I'd concentrate on getting good at using search engines - most stuff is out there, if you search thoroughly.
A PDF enabled eReader or tablet is a very good help - enables you to read when on a bus/train/plane, in bed, cooking dinner, returning same etc.
Oops, got a little long. Good thing that you like to read ;D
-
thanks Soeren .... will keep everyone posted how it all goes...