?? readme
字號:
$Id: README,v 1.9 2003/10/05 05:17:42 dwalters Exp $-- Open Automaton Project: http://oap.sourceforge.net -- HEAD CONTROL MODULE INTRODUCTION--------------------------------This README covers the source code and circuit schematics for the Open Automaton Project Head Control Module.The Head Control Module is a hardware device that controls the Pan and Tiltservomotors of the head, as well as taking passive infrared sensor readingsfrom the head-mounted Eltec infrared sensor. This device passes control and sensor readings data to and from the robot's mainboard via the I2C interface,using the SMBus protocol.The circuit schematic (head_control_module.sch) was developed in gschem, partof the gEDA package, version 20030525.Circuit schematic symbols that are not in the symbol library bundled with gEDAare included as separate sym files (these .sym files can be copied into yourlocal symbol directory, typically /usr/local/share/gEDA/sym/local/).LICENSING---------All source code and electronic circuit designs are copyright (C) 2003, Dafydd Walters.The Open Automaton Project software is distributed under the terms of the GNUGeneral Public License. See the file COPYING.SOFTWARE for details.Please see the file COPYING.ELECTRONICS to see the terms under which theelectronic circuit designs of the Open Automaton Project are distributed.CIRCUIT NOTES-------------The Eltec passive infrared human body heat sensor detects movement of heatsources along a particular axis (along the same direction as the tab on theperimiter of the detector's metal body). It is important to mount this sensorso that it is oriented to detect movement along the same axis as the Panservo. A polyethylene freznel lens should be mounted at the appropriate distancefrom the detector to ensure that infrared energy is focused on to the detectorcorrectly (the sensor kit from Acroname includes the lens and a cut-outpattern which can be used to construct a suitable concentrating cone that holds the lens and the detector at the correct distance apart).This circuit provides power to the servos from a 7805 voltage regulator. The7805 (with a heatsink attached) can deliver up to 1A. The current consumedby the other components is negligible, so servos that draw an absolute maximum current of 490mA each should chosen for Pan and Tilt.Due to surges and spikes associated with motors, it's important to placetantalum bead supply decoupling capacitors very close to each of the Pan andTilt RC servo connectors. If you can completely separate the power supplies of the servos from the rest of the circuit, so much the better.Most servos specify a PWM period of 20ms, with an "on-time" pulse width range of 1ms to 2ms. However, this range does not allow servos to reach theirpotential maximum positions, so the Head Control Module outputs a PWM pulsewhich can be driven anywhere in the range 0.5ms to 2.5ms. This extended rangealows the servos to be driven to their end stops. HOWEVER, you shouldestablish what the drive limits of your particular servos are, because you should never drive servos quite as far as their end stop postions. You can establish by trial and error what drive setpoint values correspond to these positions just short of the end stops, by using the oap-head utility.SMBUS INTERFACE---------------This module is a slave on the I2C SMBus, with the fixed address 88(the address can be changed by modifying the source code and re-compiling).The device responds to the following host (master) commands:Read Byte Data, Command = 1: Report Pan servo setpoint (one data byte). The actual driven position of the servo will eventually "catch up" with this value, depending on the value of the "Maximum Change Per Period" setting.Read Word Data, Command = 2: Report Pan servo actual driven position (two data bytes). The first data byte is the actual driven position of the servo, and the second is the current 8-bit timer count (20ms per tick).Read Byte Data, Command = 3: Report Tilt servo setpoint (one data byte). The actual driven position of the servo will eventually "catch up" with this value, depending on the value of the "Maximum Change Per Period" setting.Read Word Data, Command = 4: Report Tilt servo actual driven position (two data bytes). The first data byte is the actual driven position of the servo, and the second is the current 8-bit timer count (20ms per tick).Read Byte Data, Command = 5: Report "Maximum Change Per Period" setting (one data byte). This is the maximum change per update period (which is 20ms) of the servo's driven position. The smaller this value is, the slower (and smoother) the servos will appear to respond to changes in setpoint. See the command 102 for more information on this setting.Read Byte Data, Command = 6: Report raw analog IR sensor reading (one data byte). This is useful only for testing (and establishing a suitable value for the "IR Sensor Neutral Value" setting). Triggered IR detections (see commands 9,10,12,13) should be used when actually sensing heat sources.Read Byte Data, Command = 7: Report the value of the "IR Sensor Neutral Value" setting (one data byte). This is the ADC count that the IR sensor is expected to hover around when there's no moving heat source present.Read Byte Data, Command = 8: Report the value of the "IR Sensor Trigger Threshold" setting (one data byte). This is the number of ADC counts above or below the "IR Sensor Neutral Value" setting that triggers a detection event.Read Byte Data, Command = 9: Report the value of the Pan servo actual driven position for the stored IR detection event (one data byte). Host should use command 10 first to check if a detection event occurred, and to "lock" it (i.e. prevent it from being overwitten by another event).Read Byte Data, Command =10: Report the IR triggered event status (one data byte). The data byte returned is zero if no event has been triggered, and one if an event has been triggered. When 1 is returned, this command has the side effect of "locking" the event data so that it cannot be overwritten by another event when the triggered event mode is "Last Event" or "Maximum Event" (the lock has no effect if the triggered event mode is "First Event"). The purpose of the lock is to allow all the characteristics of the event to be read by the host (using commands 9,12,13) without fear of another event being triggered in between the calls to the various commands to read the event
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -