./ROV:circuit
From UAFCS
Contents |
James' ROV Controller Board
- One PIC 16F887 controller
- Two 7404 inverters
- Eight ST micro motor controllers (see below)
- One DG408 video multiplexer
- Six video ports
- One tether port
- One sensor port
Devin's High-end ROV Controller Circuit Design
Here is the controller board schematic v1.0. It has the following features:
- x8 H-bridges with 4 independent velocity controls.
- x6 servo headers
- x2 auxiliary connectors
- Battery voltage monitor
- Thermocouple interface
- x3 paired video/video power switches
- RS-232 level shifter
- Hydrophone amplifier
- Accelerometer for measuring roll/pitch/yaw
- 2A charging circuit onboard
- 9V, 5V, 3.3V regulators
- Separate +9/-9V isolated DC supplies
I have received my FreeDFM results, they can be found at 4pcb's FreeDFM site. I'm not sure if the bottom layers are orientated correctly at the moment, but I believe that the board is otherwise sufficient. I hope to have the board ordered and a bill of materials drafted this week, so comments or criticisms should happen soon if they are to be integrated into v1.0.
Tether Pin Layout
The umbilical contains the following pins:
- Serial up
- Serial down
- Vin (for charging circuit)
- Ground
- 2x video up
- audio up
Individual component discussion
H-Bridge
Just for reference, our Atwood 1250's pull 10A at 12V with our custom props while turning normally; the stall current would be even higher! Thus at 120W our thrusters generate about 2lb of force. This is only a bit worse than these commercial thrusters, which generate 12N/3lb of force at 100W.
Dr. Lawlor likes the look of the ST Micro VNH3SP30TR chip, which is a $7.50 30-amp (!) dedicated H-bridge. It is surface-mount, which may be a pain, but the amp rating is sure crazy. He's ordered a couple of these to test out.
2008-02-28 test! Dr. Lawlor built a tiny one-slot Gootee board, and carefully soldered on the surface-mount VNH3SP30 chip. He then hooked up (fairly tiny) 18-guage leads to the 12V rail of a computer power supply, and the motor leads to an Atwood 1250 motor with our year2007 prop attached. It works! Running in air (at approx 3A), the motor controller drops about 30mV on both the 12V and ground lines, and doesn't even get perceptibly warm (expected power dissipation: 90mW).
Running the motor in a bucket of water (so pulling approx 10A), the motor controller drops 0.23V on the +12V rail and 0.15V on the ground line (expected power dissipation: about 4W). The chip quickly heats up: 78F ambient, 164F after 30sec, 168F after 1min, 172F after 1.5min. This is uncomfortably hot but still touchable: wax melts, but water does not boil. With no real PCB heatsink "wings" (under the chip's "heat slugs"), thin 1oz copper traces (with heavy globs of solder, though), and full-bore 100% power, this is clearly worst-case. With a top heatsink, or smallish PCB heatsink "wings", the VNH motor drivers should do fine!
Other options:
- For small motors something like the dual-channel 3A L298 (also from ST Micro) is plenty.
- Quad-FET driver with discrete FETs (such as the Si9978) might be easier to heatsink.
- Prepackaged PWM-to-amps motor controllers, like the Sabertooth or Victor work well, but they're pricey per-channel.
Video Switch
We learned last year that sending multiple video signals up one cat5 cable leads to annoying crosstalk. So we should probably switch between the various video cameras down underwater.
Possible switching components:
- DG408 8-way analog mux. Bought two of 'em. They pass bipolar signals from a single-ended power supply, which is nice. Bandwidth starts dropping off around 20Mhz, which is fine for video.
- Tested one of these on a breadboard 2008-02-29. It works well! (V+ 5V, V- -12V). I can't see any blurring; or any visible difference between running video through the mux or not running it through. You can actually switch video inputs in the middle of a frame, and you only lose about a dozen lines of video!
- Quick question on your test: you claim the DG408 will pass bipolar signals with a single-ended power supply. The datasheet does not seem to support this as it claims that the analog input is clipped to V+/V-. Looking at the output video on my oscope however, the ntsc output signal from the minicam seems to be somewhere in the range of 0-2V (this means the signal may not actually be bipolar anyways). I'm curious if you get a decent video signal with V+ 5V and V- 0V. If you have a supply that can provide it, I would be also be curious about V+ 3.3V (or 3V) and V- 0V as well.
- Mux breadboard test 2, 2008-03-06. The video mux passes video quite nicely at V+=12v and V-=0v. The video looks passable, but whites are a little oversaturated/clipped running at V+=5v and V-=0v. However, the chip doesn't seem to turn on at all at V+=3.3v V-=0v. Going to the trouble of running V- at -12v doesn't seem to affect the video quality. Sending the logic inputs in at 3.3v level also doesn't seem to affect anything. I do notice a *tiny* amount of blurring going through the mux compared to a hard wire, but it's just at the threshold of perceptibility; the video is blurred a lot more going through the cat5 cable. Overall, running the mux at V+=12v, V-=0v, and sending in convenient logic-level inputs should work fine.
- Devin settled on the DG409, which is a similar chip but a "4:2" mux; it will output two channels from four inputs each. Devin's using these for stereo vision on the main robot.
- Tested one of these on a breadboard 2008-02-29. It works well! (V+ 5V, V- -12V). I can't see any blurring; or any visible difference between running video through the mux or not running it through. You can actually switch video inputs in the middle of a frame, and you only lose about a dozen lines of video!
- NTE4067 Maybe a better MUX: same used on LISA. 16-way, 10+MHz bandwidth. Runs flatter and wider bandwidth at 12V supply frequency. However, this guy says the 4066 has more noise than the DG408 above.
- CD4051 Maybe better yet: 4051 series. 8-way, 40+MHz bandwidth. Run on 12V supply.
- MAX454 $12 4-way dedicated-to-video mux with amp.
Datasheet for MAX board says you can reduce crosstalk by adding ground traces between each video trace. Good idea!
The cameras we're using have 9V battery connectors for power (although they'll run on 9-12vdc), and yellow RCA female phono plugs for video (the idea is you'll use a male patch cable). It'd be nice to make some tiny camera interface boards connecting these (dry) lines to wet RJ-45 female jacks, so we can just plug the cameras in with ethernet patch cables. While we're at it, running at least two servo 5V-gnd-PWM lines (for camera pan-tilt) down the same cat5 cable would be nice as well.
Hydrophone
One or two hydrophones would help the driver feel more like they're really down underwater. Commercial hydrophones made for recording whale-songs are are $130 each, but you can apparently do OK with a condenser microphone in an oil-filled plastic jar. We're not listening to whales here, just the whirr of motors and clunks as we make/break contact, so hi-fi is not needed.
Devin points out that the PIC's A/D converter could easily sample analog audio to digital, but shipping 12-bit samples at 40KHz takes half a megabit of bandwidth--more than our serial link has!
Power Source
The current plan is onboard batteries, which definitely will give us the amps we need. Dr. Lawlor is a bit worried about battery capacity and longevity--it'd stink to have 'em crap out halfway through a mission--but beefy lead-acid batteries should work.
For topside-supplied power, running off wall current is ideal, but the contest rules limit us to 48V and 40A. In 2007 we used a computer power supply to drive the 12V line. This worked, but when pulling 20amps the 12V line sagged to under 10V, which freaked out the cameras. This guy suggests a resistor across the 5V lines, which supposedly kicks the power supply into high gear, allowing it to drive more 12V juice too. You can also combine several power supplies in series (for higher voltage) or parallel (for higher amps), although you need to cut the DC-side connection to AC ground, according to these folks.
Devin pointed out that you could actually run DC power down the "ground" half of each of your cat5 signal pairs--as long as the draw is constant, the exact voltage doesn't matter for RF shielding purposes. According to this page, you can dump 3 *amps* per conductor of 24 gauge copper, so with 4 "ground" wires you could dump 6 net amps. Over 50 feet of cable, you'd lose 8 volts doing this, but topside power is cheap! For example, you could start at 36V topside (3 computer power supplies in series) and still have a reliable 6A 28VDC onboard feed to charge the batteries.
Dr. Lawlor's MUDbot
The new 2008 MUDbot controller board is 6" wide by 3" high. It's got the tether interface, the PIC, the DG408 video mux (I don't have stereo video though), a 7404 inverter and four of our surface-mount ST H-bridges.
I can *just* fit everything I think I need onto one Microchip 16F690 PIC, which isn't a bad little chip--hardware serial is *nice*! And I managed to cram all 8 motor control lines onto the PORTC output of the PIC *without* using any jumpers. This should make software PWM not quite so horrible.
As far as PIC software, I'm thinking about a 4KHz PWM frequency. That's high enough to keep the motors' pulses smooth, and that way I can just poll for serial data rather than using interrupts. (At 57.6kbps, you get 5KB/s of data, so during one 250us window you might receive up to 2 bytes, which is exactly the USART's RCREG FIFO size.) The PIC's hardware PWM only has one channel, so I'll probably just do all four motors in software rather than have one motor different from the rest.
250us isn't a very long time; even at an 8MHz clock, I only get 500 instructions during this window. There are a couple of ways to do multichannel software PWM:
- I could sort (by ascending time) the PORTC changes, then step through the list making the changes, with busywaits in between.
- Same thing, but loop on a hardware timer. This would make you less sensitive to interrupt noise, but then, you can probably turn interrupts off!
- Same thing, but do the changes from timer interrupts. This might give better granularity than a loop (I think simple PIC loops take four clocks), but interrupts are tricky, and back-to-back changes might be really tricky.
- Build a big table (indexed by time) of the future values of PORTC, and then copy them into PORTC. This uses up (quite scarce!) RAM, and increases the cost of PWM changes (because you've got to regenerate the table). But it makes simultaneous changes trivial, could provide very high resolution (up to one PWM change per 0.5us instruction cycle: PORTC=pwm_data[0]; PORTC=pwm_data[1]; ...). It could even provide nonlinear PWM resolution (e.g., one clock/PWM change early on for low-power mode, many clocks/change later on).
The short-time table can only be 80 or so entries at most, due to the BANK0 size limit. But you could split the long-time table entries off to another bank, and then the bank switching will eat up yet more time. Here's a possible division of entries:
- 8 entries at 0.5us/entry (to 4us, very low-power modes)
- 8 entries at 1.0us/entry (to 12us, low-power)
- 16 entries at 2.0us/entry (to 44us, medium)
- 24 entries at 4.0us/entry (to 140us, high power)
- 16 entries at 8.0us/entry (to 268us, overdrive)
Here's the PORTC motor control port pinout: C0: Qpwm C1: Rpwm C2: Spwm C3: Qdir C4: Ppwm C5: Pdir C6: Rdir C7: Sdir
Here's what the code might look like to fill the pwm_data table with PORTC values:
dir_mask = (P_dir?(1<<4):0) | (Q_dir?(1<<3):0) | (R_dir?(1<<6)) | (S_dir?(1<<7):0);
for (int t=0;t<64;t++) {
pwm_data[t]=(P_pwm>t?(1<<4):0) | (Q_pwm>t?(1<<0):0) | (R_pwm>t?(1<<1):0) | (S_pwm>t?(1<<2):0);
}
And then the code to read out the PWM values:
PORTC=pwm_data[0]; /* 0.5us per update */
...
PORTC=pwm_data[7];
PORTC=pwm_data[8+0]; NOP(); /* 1.0us per update */
...
PORTC=pwm_data[8+7]; NOP();
int n=8+8, n2=16, n4=24, n8=16;
for (t=n;t<n+n2;t++) /* 2.0us per update */
{PORTC=pwm_data[t];} /* loop itself acts as delay */
for (t=n+n2;t<n+n2+n4;t++) /* 4.0us per update */
{PORTC=pwm_data[t]; delay_2us();}
for (t=n+n2+n4;t<n+n2+n4+n8;t++) /* 8.0us per update */
PORTC=pwm_data[t];
MUDbot pinouts
2008 MUDbot tether pins:
- Pin 1 is audio
- Pin 2 is +5V
- Pin 3 is +10V (camera power)
- Pin 4 is Tx
- Pin 5 is +12V (motor power)
- Pin 6 is Rx
- Pin 7 is video
- Pin 8 is ground
The above design is mostly compatible with our 2007 boards (we've got *lots* of these still sitting around), at least in the odd-numbered (colored) pins, which are the only common pins in the 2007 designs. Sadly, it's NOT compatible with Devin's tether...
(Updated) 2008 video camera pinout. Note this updated version is compatible with the 2007 tether--you can hook the 2007 tether directly to a video camera, and view the video.
- Pin 1 is unused
- Pin 2 is +5V servo power
- Pin 3 is unused
- Pin 4 is PWM signal B (pan) for camera servo
- Pin 5 is 10-12v camera power
- Pin 6 is PWM signal A (tilt) for camera servo
- Pin 7 is video signal
- Pin 8 is shared ground (for servos and camera)
The ONE TRUE RJ45 COLOR STANDARD is [T568B]
MUDbot Microcontroller Pins
PORTA is the camera control:
- A0: muxA0
- A1: camera pwm
- A2: camera pwm
- A3: (unused, input-only)
- A4: muxA2
- A5: muxA1
PORTB has the hardware serial lines, and a few others:
- B4: camera pwm
- B6: status LED
PORTC is the motor control lines. I've named the motors P,Q,R, and S because there are way too many 1's, A's, etc floating around!
- C0: Qpwm
- C1: Rpwm
- C2: Spwm
- C3: Qdir
- C4: Ppwm
- C5: Pdir
- C6: Rdir
- C7: Sdir
MUDbot Video Mux Pins
PORTA Pin Routed to 0x00 Input 0: not connected 0x01 Input 1: not connected 0x20 Input 2: video5 0x21 Input 3: video6 0x10 Input 4: video1 0x11 Input 5: video2 0x30 Input 6: video3 0x31 Input 7: video4
MUDbot mainboard prototype
So after installing basically every chip on the board upside down (d'oh!), I've finally gotten the mainboard basically working. I finally figured out that the PIC's hardware serial requires the special inversion flag "SCKP=1" to even send RS-232 compatible outputs, and can't natively receive RS-232 at all without an external inverter (or even an official line receiver/comparator). RS-232 voltages:
- '1' == mark == negative volts
- '0' == space == positive volts
Data line idles in mark ('1', -V) state. Start bit is space ('0', +V) state. Zero seems close enough to "negative volts" to work in both send and receive mode, although you MUST add a little resistor (maybe 1Kohm) to keep the pin protection diodes from pulling too much current in negative state.
I ended up using a spare 7404 inverter circuit to flip the RS-232 around so the PIC hardware receiver works. I got pretty close to just giving up and doing software serial again, like 2007. One annoyance with my PIC 16F690: the builtin oscillator calibration doesn't seem to be accurate enough that I can use the same hardware baud rate divisor for every physical chip--of the two chips I tried, one required a divisor of 30, the other a divisor of 33, to talk at 57.6Kbps. You can figure out if your baud rate is off by disabling parity and sending a known bit pattern from the PIC; I like 0x00, 0x11, 0x22, ... 0xff. If 0x00 is received as 0x80 (the stop bit is shifting in), the PIC is sending too fast. If 0x11 is received as 0x21 (the high bits are coming in late), the PIC is sending too slow.
Now that hardware serial is working, I defined a silly temporary motor protocol:
- 'f': full speed left
- 'p': full stop
- 'z': full speed right
Each letter should count for 10% additional power.
You can fire this up from a Linux command line with:
- stty raw clocal 57600 cs8 parenb parodd cstopb -echo < /dev/ttyUSB0
- cat < /dev/ttyUSB0 &
- echo -n "r" > /dev/ttyUSB0
At 12.3v motor voltage (unloaded 2007 black PSU), 5.32v logic voltage, 75F ambient temperature, with my rev1 board's "P" bridge driving the broken-blade 2007 prop in air:
- At 0% "p" speed, motor is totally stationary. H-bridge sits at 85F.
- At +10% "q" speed, motor makes high-pitched whine and barely spins CCW (viewed from outside, brown wire in outside plug). H-bridge reaches 140F in a minute or so.
- At +20% "r" speed, motor turns at a decent clip in air. H-bridge reaches 110F.
- At +30% "s" speed, motor creates noticeable draft. Sound is barely audible (and annoying!). H-bridge stays at 110F (or below) pretty consistently. Supply voltage is 12.25v. PIC is at 76F. 7404 chip hits 78F.
- At +50% "u" speed, motor starts to vibrate. H-bridge sticks around 100F. Supply voltage is 12.08v.
- At +100% "z" speed, motor is crankin', quickly vibrating itself free of my mounts! H-bridge is at like 84F. Supply hits 11.84v.
- At -10% "o" speed, motor barely spins CW. It will sometimes stick stopped. H-bridge gets hot pretty quickly, to 130F in a minute or so; 140F after two minutes.
- At -20% "n" speed, motor spins freely. H-bridge sticks around 120F.
- At -30% "m" speed, H-bridge hits 89F (after 5 minutes). Supply hits 12.24v.
- At -100% "f" speed, motor spins like crazy. There's a noticeable step between each power level up to here. H-bridge is at like 85F (cool!). Supply hits 11.84v.
The power supply voltage drop is about what I expected. I'm kinda surprised that the H-bridge gets *hotter* when running the motor *slower*, but the temperatures are quite reasonable in any case. I'm interested to see what will happen with the motor running in water.
Encouraged, I soldered down all four h-bridges, and the board still works. WOOT!
MUDbot 2008-04-11: PWM Tuning
I built a little "packet serial" receiver program for the PIC, which actually worked fine once I sent the right data down from the main computer!
That working, I implemented the table-driven software PWM approach above. The main loop is beautiful:
while(1) /* This loop goes around about every 10us */
{
if (RCIF) { receive_data(); }
PORTC=pwm_portc[phase];
phase++;
if (phase>=N_PWM) {
phase=0;
... rare housekeeping work goes here ...
}
}
This actually seems to reliably receive serial commands, and provides an excellent place to put long-period housekeeping work (e.g., check if we've lost contact with topside) without using interrupts.
N_PWM is a parameter--it determines the size of the pwm_portc table, which indirectly determines the PWM pulse rate.
- 16-step PWM: goes about 10KHz. No sound--nice! First step just barely rotates motor--16 steps is actually plenty of resolution. But H-bridge hits 135F!
- 32-step PWM: goes about 4KHz (260us/cycle). Sound is barely audible. H-bridge hits 110F.
- 64-step PWM: goes about 2KHz (512us/cycle). Sound is annoying. H-bridge hits 100F.
- 32-step PWM plus "sandbag", taking about 16ms/cycle (a 60Hz PWM!). Motors sound about like a (quieter) chainsaw. Surprisingly, the motors still actually work OK, and spin at all strengths fine! H-bridge never exceeds 90F.
I'm going with N_PWM==32, which provides plenty of resolution while keeping the H-bridges cool. The above are all measured in air, where the thrusters only pull 3A or so; the 10A they pull in water might cause hotter H-bridges, but probably not dangerously hot.
Before I forget, here's my one-LED command cheatsheet:
- LED blinks 4 times fast: startup.
- LED blinks once per second: receiving commands, working properly.
- LED lit continuously: working, but not receiving commands from topside.
- LED off continuously: no power, or locked up.
To do: topside breakout board, and video!
