Slew detection & calculation in code

It's not often that I cannot visualise code to answer questions about what some sensors are telling me about the real world.

But I've got a mental block on this one.

I want to monitor the slew (angle) of an excavator, that's the left/right rotation of the digger arm, it would probably be called yaw in other projects.

Inside the excavator there is a massive toothed ring that I can mount NPN or PNP Hall Effect proximity sensors to detect a tooth or a gap.

I need to ascertain the direction of rotation and of course the number of degrees (cog peak pulses) moved.

Do you think I can do this with two sensors or might I need three to reliably ascertain the directions - clockwise/counter-clockwise?


\ /
\ /
____/

^ That's a cog tooth.

v Sensors are perhaps at 'o'


o o
\ /
_o_/

Any thoughts on detecting the on/off wave form for detecting the direction of rotation and counting the pulses such that I can detect the slew angle.

Thanks

This sounds similar to the use of shaft encoders to monitor shaft rotation. You need two sensors, out of phase, to detect direction of rotation and to count passing stripes or teeth.

There are plenty of Arduino code examples or libraries on line for that.

^ Thanks - appreciate that guidance.

Your scheme has no way of determining where zero is or even which direction the boom is pointing when the program begins. So, what are you trying to accomplish?

Paul

ScrewLoose:
Inside the excavator there is a massive toothed ring that I can mount NPN or PNP Hall Effect proximity sensors to detect a tooth or a gap

Two sensors at that wheel would make what is called a quadrature encoder.

NPN output is usually easier to read with an Arduino.

Hi,
Have done this and where I work we supply such a system, use the gear teeth as quadrature encoder, use inductive sensors.

Place a reference point on the gear for another sensor to give you your reference point.

On startup, make an alarm ring, it can only be cancelled and the slew rate operation can only happen, after you have done a manual lowspeed slew to locate the reference point.

Tom..... :slight_smile:

TomGeorge:
Hi,
Have done this and where I work we supply such a system, use the gear teeth as quadrature encoder, use inductive sensors.

Place a reference point on the gear for another sensor to give you your reference point.

On startup, make an alarm ring, it can only be cancelled and the slew rate operation can only happen, after you have done a manual low speed slew to locate the reference point.

Tom..... :slight_smile:

Jeez that's a good idea. Thanks, I was considering using a magnetic compass, but a little tab welded to the cog ring that resets all the slew drift makes so much sense - I can't believe I didn't think of it!

I really appreciate all the effort you guys make to this forum, it's fascinating reading.

Paul_KD7HB:
Your scheme has no way of determining where zero is or even which direction the boom is pointing when the program begins. So, what are you trying to accomplish?

Paul

Yep, I was planning on storing the the slew angle in Program memory (I believe EEPROM would be limited by the number of writes).

I was reading that it is possible to detect a power down and 'buy' a small bit of time to write the current slew angle to permanent memory.

Tom has given me some food for thought, and the mention of quadrature encoders makes perfect sense.

Thanks everyone.
Really appreciate your ideas.

ScrewLoose:
Yep, I was planning on storing the the slew angle in Program memory (I believe EEPROM would be limited by the number of writes).

Technically possible. The EEPROM is guaranteed to take at least 100,000 writes (real world tests show failure after 1-2 million writes) so that should be no problem, especially with some wear levelling. But there is NO guarantee that your boom does not get moved while the Arduino is powered off. So it's still a less reliable method.

Detecting a power outage is quite easy, a largish capacitor should give you enough time (you need 10-20 ms) to do the detection and write a few bytes to EEPROM.