We plan to use PIC24HJ128GP202 because it has a low pin count, but it has reprogrammable pins for peripheral, DMA support and a lot a features. It also includes 2 UARTS and 2 SPI making communication easier.
The initial choice for accelerometer is MMA7260Q which is one of the first 3-axis accelerometers. It's also a 3.3v part.
The connection for wireless will be a low-cost Bluetooth UART Roving Networks Bluetooth UART. This module provides just the UART (nothing else) for Bluetooth, which has a major advantage because many new laptops (especially MacBooks) have Bluetooth radios. This means in the field, all we need is the robot and a laptop.
The main board has a microSD slot and a 1 GB microSD card to log data at real-time. Read and writing to the card is implemented using the ELM - FAT file system library. At current, the library has been tested and can read from the card, but it hasn't been determined how much CPU time is used during normal operation. The driver might need to be augmented to use DMA transfers. Furthermore, it has only been tested at data speeds of 400 kbits-ps, but we expect to be able to go as high as 20-25 Mbits-ps. The files take timestamps, so it would be best if the main board had a clock, a 3.3V with battery backup low pin count is DS1340, with battery and holder.
We plan to have a small PCB near each motor, which will handle A2D? from analog position encoders and produce the drive PWM for a H-bridge. Since we will have a lot of these boards, we will attempt to reduce their weight by compacting the design as much as possible.
The current chip under consideration is PIC24F04KA200, chosen because it's one of the few low pin count chips with all the features we require: SPI, PWM and A2D? .
The TSSOP package is 5mm x 4.4mm body, 5mm x 6.4 mm footprint
I'm considering the Si9986 from Vishay Siliconix because it can handle 3.3v input, handle 1A continuous and 1.5A peak (which is sized just about right for each motor.) and it comes in a small 8-pin surface mount package.
The H-bridge has two inputs, which will drive the motor if the inputs are different, brake if the inputs are both low and coast if the inputs are both high. For this reason, the PWM line must be connected to both pins, but we only have one PWM output. Therefore, I suggest connecting the PWM to both inputs through a two 3.3K ohm resistors (one for each input) and then connecting two additional tri-state I/O pins to each input line using 100 ohm resistors, to force the pins one way or the other.
We are using a 3.3v Hall effect sensor (this sensor has a thinner profile than those on SB1 and SB2)
Asahi
Instructions on how to mount the sensors can be found here: SB3HallEffectMounting
We are using half-duplex SPI over RS-485. RS-485 is handled using these drivers:
The communication uses a fixed time division multiplexing. An idle clock line is used to indicate framing. The communication uses Pearson Hashing to provide error detection. Error correction is not attempted, but rather packets are dropped (since the packet contain real-time motor commands and sensor data, dropped packets are treated as disturbances.)
The RS-485 wires can be reversed, or one can be mistaken plugged into a power/ground on a breadboard, which can inverted the clock signal's logic. The symptoms are the servo board reports no error while the main board data is shifted by one bit and the
We are going with the Molex PicoBlade? connectors. (These are the same used by the Paparazzi Autopilot project)
We are using the 53261 series of Molex
These connectors are designed to snap into place and require a relatively large force to disconnect. This is good for the robot during normal operation, but this causes problems for certain connectors such as the programmer connection, or the prototyping power. To modify the plugs for temporary connections, take the plug and shave off the small nub(s) on the bottom of the plug (on the side that would face the PCB). I've also had some success with tapering the fins on the sides (not too much) but it makes insertion and removal a lot easier. This modification should only be done for bench-top prototyping plugs. All plugs on the robot should remain unmodified.
-- SalomonTrujillo - 24 Jun 2009