Sensor Feedback to the Servo Controller

Sal has hacked the boards to bypass the op-amp so we can use the hall effect sensors (the output of these looks very nice). 4 new boards have been made with these hacked schematics (numbered 0-3) and have had the following board addresses assigned: (the 7bit I2C? address is being treated as a 6bit board address and a 1bit sensor select bit, in the lsb of the 7bit address).

-- BarrettHeyneman - 26 Aug 2006

Four more boards have been made for use on Stickybot II. They have been assigned addresses to work with the current main board code:

000100 - Front left leg
000101 - Front right leg
000110 - Rear left leg
000111 - Rear right leg

-- BarrettHeyneman - 12 Apr 2007

Board Number	6-bit Address	Status	Date
0	000100	Working	8-22-06
1	000101	Working	8-22-06
2	000110	Working	8-22-06
3	000111	Working	8-22-06
4	000100	Working (1 bad bus connector)	4-12-07
5	000101	Working	4-12-07
6	000110	Working	4-12-07
7	000111	Working	4-12-07

We should keep this updated as we make/break boards

-- JonathanKarpick - 27 Apr 2006

Now that sensor board and main controller board are communicating - the sensor circuit needs help. The trans-resistive circuit is not stable - huge oscillations (2V p2p) in the circuit board set-up. (Didn't happen on the breadboard - weird). A cap placed in parallel with the feedback resistor calms things down, but it affects bandwidth in a way which I need to calculate.

Alternative is to revert to running the phototransistor through a resistor and pulling the voltage off of the top of the resistor. This is what Sangbae did when he was playing around with these... The transresistive is supposed to be "better." That has yet to be true. A little hacking on the PCB can turn it in to the simpler resistor circuit.

-- JonathanKarpick - 27 Apr 2006

Sensor board / main board interaction acting goofy.

Symptoms:

Reading the value from the 2nd sensor on the sensor board usually works fine
Reading the value from the 1st sensor on the sensor board returns semi-random numbers.
- Scope shows randomly appearing 900mV humps in the I2C stream being transmitted by the sensor board. Implies that the signal is getting corrupted somewhere.
- It's coming out of the sensor board PIC okay (echoed commands to the LED pin, and that looks fine.
- If I add a 200ms delay between transmitting the desired address and receiving the data, the humps don't occur and the signal is clean. (That's a HUGE delay!!).

DOH!!! Stray chip left on test circuit... much better now.

Sensor to Controller looks stable up to 75kbps I2C. At 100kbps, it looks like the sensor board is self-resetting, leading to occasionally bad readings. A more robust confirmation of readings (using ACK and NACK) would prevent extraneous readings from propogating to the controller, or just run the comms at a lower rate...

Thinking about why it's resetting
- At 100 kHz, sensor board has 10us per period, or about 5us per 1/2-period.
- Running the sensor board at 8MHz (max internal clock)gives:
  - Tosc = 0.125us (oscillator cycle time)
  - Tcy = 0.5us (instruction cycle time)
- This allows for approx 10 instructions per 1/2 period.

- At 75 kHz, sensor board has 13us per period, or 6.7us per 1/2-period
- This allows for 13 instructions per 1/2 period.

Implication is that I'm in between 10 and 13 instructions per 1/2-period...
This was done w/o running A/D on sensor board - which can only make things (a little bit) worse.
Yup, doing a quick count of instruction cycles yields approx 25 between receiving the last bit of the address and sending out an ACK.
- Can delay the clrwdt2 command until after the ACK is sent (saves 3 cycles) - DONE
- Can send an ack automatically when SDA is set to out (saves 1 cycle) - DONE
- Can have ByteOut use the W reg instead of buffer (saves 1 cycle)
- Can change ByteOut macro to take the sensor value register as an argument and then operate directly on that (saves 2 cycles).
- Remove debugging LED toggles for last bit received (saves 3 cycles) - DONE
Moved SendAck out of ByteOut and retained the use of the buffer
17 instruction cycles now.
- How many cycles is the A/D interrupt routine? (It's definitely more than 3...)

100kHz now works. Might need to think about WDT for the main board.

-- JonathanKarpick - 02 Feb 2006

Attached is a PDF with pseudo-schematics for the 12F4520 and 12F510/675/683: SchemeServoDriverV3.1.1.pdf

Main thing added to the 12F4520 board is a header for in circuit serial programming (ICSP) to be done via the ICD2. Easiest choice is a RJ-12 jack (phone jack), but that could be a little bulky. Alternative is to use a smaller header and fabricate a custom cable to connect the ICD2 to the board. This will likely have to be done for the 12F510 board anyway. (Probably should use the same header for the 4520 as the 510).

-- JonathanKarpick - 19 Jan 2006

Okay, after looking at power and weight, both of whose effects I'm calling negligible (once the decision is made to add sensors...), I'm recommending using distributed PICs on a single I2C? bus as the Analog/Digital converters.

This allows for A/D conversion as close to the sensor as possible, which will hopefully reduce signal noise. It also allows fairly broad freedom for adding or removing sensors. (Although you still get to modify PIC code when you do that...)

Here are the things that have to be done to accomplish this:

Free up pins 14 and 15 on the 18F252 PIC for use as the I2C? bus. - Sanjay?
- Change communications with RF receiver from current parallel configuration to use the I2C? bus?
- Remove LEDs?
- Drop "key" inputs? (What do these do?)
Configure I2C? on 18F252 PIC
- Modify controller code to poll the I2C? bus as required for the gait inputs, keys, and sensor data. - Jonathan
- Modify controller code to use sensor data as required. - Jonathan & Sangbae
Configure "Sensor" PIC - Jonathan
- Implement I2C? in software
- Configure A/D
- Figure out how to do in-circuit programming of PIC
- Sensor circuit board - Jonathan, Sangbae, & Sanjay + others?
Connectors? - Sangbae, Jonathan, Sanjay...

-- JonathanKarpick - 19 Jan 2006

Pretty negligible I think. The servos are probably pulling a total in the 100s of milli-Amps or more (any better estimates out there?). The addition of a couple of milli-Amps therefore doesn't make much difference. A battery is typically rated for 1000mAh or more, so the motors are the major drivers of battery life.

If the controller was the proverbial straw on the camel's back, then some savings can be gained if the chips are run at slower clock rates, with obvious ramifications on control system performance (although not necessarily on movement performance...).

Additionally, the power regulator for the controller on Virgilio's board can handle up to 1A, so we'll be far away from that limit.

-- MattSpenko? - 19 Jan 2006

What does the increased power consumption mean for battery life?

-- JonathanKarpick - 18 Jan 2006

Looked into the A/D convertors. MicroChip's and most other simple ADCs with serial interfaces (I2C / SMBus) from TI, Phillips, Analog Devices etc., typically have a hard coded address - which means you can only have one on a single bus, kind of defeating the purpose. Ideal chip would include one A/D pin, and an I2C interface, and that's it. Microchip doesn't seem to have anything like this. Alternative is to look for a chip with one A/D and do the I2C in software (requires two digital I/O pins).

Power and Weight Budgets:

Baseline: 18F252 PIC - < 1.6 mA at 5V, 4MHz, 28pins
Assume N sensors
I'm giving mostly incremental changes from the baseline - kind of assuming that power and ground to each sensor is a given, so I'm not including that...

Option 1: Bigger PIC:
- 40 pins: 2.5mA typical at 5V, 4MHz: N<=10 unless some pins freed up, then N<=13
- 64 pins: 2.1mA typical at 5V, 4MHz: N<=12
- N wires into the PIC
- Space/weight for bigger PIC and 2*N header pins
Option 2: Additional PIC:
- Using 18F4520: additional 2.5mA typical at 5V, 4MHz: N<=13
- N wires going to 2nd PIC
- Space/weight for 2nd PIC and 2*N header pins
Option 3: PIC @ sensor, I2C comms with main PIC
- N x ?? mA typical at 5V (depends on device...) - MicroChip MCP3021 draws 5nA in standby and 175uA in conversion. The TI chips draw on the order of 0.5 mW - comparable.
- 2*N wires to each device, but common bus - so can be daisy-chained (probably some capacitance limit there)
- Space/weight for chips: 2*(N+1) headers
Option 4: ADC @ sensor w/ RF transmitter
- N x ?? mA typical at 5V (depends on ADC)
- N x ?? mA typical at 5V (RF transmitter) <- NOT NEGLIGIBLE!!!
- Space/weight for chips at sensor locations - probably negligible

ADCs:

MicroChip
- MCP3021 Website - Fixed Address
- TC1320 Website - Fixed Address - 350 uA in operation.
MicroChip PICs Website Comparison Table
- PIC10F220 - Future Product: 6 pins, 2 A/D, 4 I/O - Software I2C?
- PIC12F675 - 8 pins, 4 A/D, 6 I/O, 0.6mA @ 5V, 4MHz typical - Software I2C: Software I2C App Note
TI Comparison Table
- DAC5571 - 8 bits, low power, two choices of addresses, 6 pins
- DAC6571 - 10 bits, two choices of addresses
- DAC7571 - 12 bits, two choices of addresses
- DAC8571 - 16 bits, two choices of addresses
- DAC8581 - 16 bits, looks like it's SPI only, not I2C (liars!)
Phillips PCF8591 Datasheet
- 4 A/Ds, 16 pins, 8 possible addresses, 125 uA typical
Analog AD7992 Website
- 2 A/Ds, 10 pins, I2C, up to 5 on a single bus, 1.4 mA typical

Could also think about SPI interfaces with a multiplexer to do the chip selection. This means signal wires from main PIC to each sensor board.

Can we add some estimated power and weight budgets for these options? Thanks, MarkCutkosky %ENDCOMMENT%

-- JonathanKarpick - 17 Jan 2006

I did some quick looking into options for sensor feedback into Virgilio's servo controller.

I'd like to get your thoughts on the options I've cooked up (or any others you have!)

At the core, I think this problem comes down to the number of pins available on the PIC, and the number of Analog to Digital converters available on the PIC (if we're feeding back voltage signals...)

The current configuration is pretty parallel - one pin, one signal into/out of the PIC. Switching some of the inputs to serial communications would reduce the number of pins required, at the expense of some coding complexity (though that shouldn't be too bad).

So, here are some options:

Everything on one PIC
- replace current 18F252 with something bigger
  - at least a 44 pin (18F4520), possibly a 64 pin PIC (18F6520)
- would need a bunch more header pins
- minimal coding changes
Add a second PIC to collect all of the signals and transmit them to the servo controller PIC.
- need to free up some pins on the current PIC (specifically, pins 14, 15, and maybe 16).
- need space for another PIC somewhere - probably the 44 pin one again (which has 13 A/D channels)
- new code for the new PIC, and code changes on the servo PIC
- again, a bunch of header pins
Use a dedicated (tiny) PIC with each sensor to to A/D and connect to serial interface on main servo controller PIC
- need to free up some pins on the current PIC (14, 15, and maybe 16)
- some more headers on the main servo controller board, but possibly only three - assuming it's possible to daisy chain the sensors together (they share the same three lines).
- each sensor would require 3 signal wires + power & ground instead of possibly just 1 wire + power & ground
  - however, this would drastically reduce sensor noise since the A/D is being done at the source.
- 3 pins for SPI, 2 pins for I2C?
- Does SPI need a select pin for each sensor? This would severely limit the usefulness. I2C? does not require a dedicated line per sensor, and only needs two shared lines for the bus.
Use a dedicated (tiny) PIC and dedicated RF module with each sensor to talk to the servo controller over RF!
- don't know if current RF module can handle this.
- unnecessarily complex addition of RF...

Personally, I like option #3 the best. We may be able to free up the extra pins if the RF module can work in a serial mode (or we can replace it with one that does) - I'll look into it.

Copyright &© by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback