The model will be controlled by two forward/reverse control sticks, one for each track and water jet. The trick is that depending whether the model is in the water or on land, the model must take different actions for a control stick input. A forward stick position simply requires forward throttle control to the appropriate (track and/jet) motor. When the stick is in reverse, the track motor is just given reverse throttle. But if the model is in the water and the stick is in reverse, the water jet motor must still be run in the forward direction, but with the jet diverter for that jet moved to the closed position.
The onboard computer system simplifies this control scheme, since the computer can monitor the signals from both control sticks and the signal from a mode (land/water/transition) servo signal, and can then take the appropriate actions. The computer can also precisely monitor track speeds and take corrective action, so the model should be able to track more smoothly while on land. If one track encounters resistance, like sand, that track motor will receive additional throttle as required to deliver the requested track speed.
So far, the backplane with CPU has been assembled and tested, and printed circuits for the daughter boards have been designed. While I have done a great deal of unit testing for the key ideas here, there is no guarantee the assembled system will actually work till I actually get all the boards hooked together with the radio, servos and motors. A clickable schematic of the computer system and drive controls is below. Once the stuff below is working, I'll add an interface for a RAM sound module and maybe some other gimmicks.
The model will have only one battery pack, a 24 volt by 12 amp-hour nicad pack. The drive motors run from that pack directly. The computer and radio receiver run through a PowerTrends DC-DC converter that provides a very stable 5 volt output at up to 3 amps.
The main board holds the CPU, a PIC 16C74A, the 5 volt power supply and the communications bus with connectors for up to 5 daughter boards. The main board also has connectors for keypad and 4-line LCD, inverter for the EL backlight of the LCD, and connectors for up to 7 remote digital thermometers (Dallas DS1620's) for monitoring motor and/or battery pack temps.
The 10-pin bus is assigned as follows:
The protocol for seizing control of the bus is first-come-first-served with some protection for collisions. It works as follows:
The critical point in this scheme is that every PIC must use a different, predetermined confirmation time in step 3 to ensure that all collisions are averted.
The image below shows activity on the BusRequest pin, with the main CPU and two daughter cards speaking on the bus. In the grid, the y-axis is in volts, and the x-axis is 5mSecs. BusRequest is low when a PIC is talking on the bus:
|Shared FRAM Memory Board|
The shared memory is used to avoid the need for synchronous communication between PIC chips. This allows each PIC to tackle a very time intensive task, so long as it can beak free every few milliseconds to write data to the memory and/or read instructions from the memory. There is a fairly simple protocol whereby any individual PIC can read or write to an address in the shared memory. The main CPU reads radio signals and writes instructions to the servo output and motor driver boards.
The shared memory is on a daughter board because I changed the communication scheme after etching the backplane board. If I ever re-do the backplane, the memory will be on the backplane.
The selected memory type is serial FRAM, which works like EEPROM except it is much faster. The downside is that it has a finite life of around 10E10 read or write operations per memory row. That means that I will need to replace the chip after a few thousand hours of continuous use (not ever). If I ever add a daughter board with a UART on it, I conceivably could add the ability to connect to a laptop computer and change operating characteristics by updating configuration data in the FRAM, though for the time being all configuration info is compiled in when I program the main CPU.
The servo input board has a PIC 16C73A, connectors for up to 8 servo inputs, and 8 LEDs. Each servo can be read with 1:512 precision. The LEDs are mostly for debugging, to indicate whether an input has a valid servo signal and whether it is in the center "dead band". To save power, the LEDs can all be disabled by removing a single jumper.
This board is almost identical to the servo input board, except that it sources power to the servo connectors since it is driving servos rather than just monitoring the servo signal wires. The logic on the PIC 16C73A will allow the main CPU to specify a maximum movement rate for each servo, to improve the realism of parts driven directly by servos.
|Dual Motor Control Board|
This board has a PIC 16C74A, and uses one of that chip's onboard PWMs for each motor. This board also monitors the shaft speed of each motor, and implements closed-loop logic to adjust motor throttle to compensate for driving resistance. Motor speeds are read via quadrature encoder signals. Rather than attempt to read two quadrature encoders in software, I will use a pair of HCTL-2000 quadrature decoders. The decoders perform glitch filtering and provide 12-bit counts upon demand, using a fairly simple 8-bit parallel interface.
The quadrature encoders are E5M series encoders from USDigital. They are bolt on parts and are wired directly to the decoders on the motor control board.
|H-Bridge MOSFET Driver Board|
Because the track motors are reversible, run on 24 volts, and consume up to 20 amps each, I either need custom speed controls or very expensive commercial units such as Vantec. I opted to build my own, each using eight IRL3705N FETs and two Micrel MIC5022 half-bridge FET drivers. The Micrel drivers have internal logic protection to prevent shorting the power rails and contain charge pumps to generate the 30+ volts needed to drive the gates on the upper FETs. The board is shown below, but without a few heavy gauge wire jumpers, and with only half of the FET's soldered in. I won't solder in the remaining FETs till I know it actually works. The large vertical traces on either side of the H-bridge are for current sensing, using the built in overload protection in the Micrel drivers.
After reading a recent posting on freewheeling diodes, I think the puny diodes here may be too small. The motors will run at up to 20 amps continuous. Only a fraction of that 20 amps will come back through the diodes, right when motor power is turned off, but the dioes may still be too small. The diodes are good for 40 amps peak (rated for 8.3mS), but only 1 amp continuous.
|Astroflight 207D Controllers|
The waterjet motors are driven by Astroflight 207D speed controllers, using signals from the servo output board. I was able to use these off-the-rack controllers for the jet motors because the jets require forward-only throttle. The 207D's are also more compact than any speed controller I am able to construct from scratch.
This page was last updated on April 29, 2006.