AVC Parts have Arrived!
I got a box from Adafruit and a box from Hobbyking over the past couple of days, which should be all the parts I need to start developing my autonomous vehicle.
First the Hobbyking stuff. Despite several horror stories that I've read, the box that I received was a sturdy box in undamaged condition. I opened the box to find the contents were equally well packed and contents were all in good shape.
Clockwise from the top, I have a model car, two battery chargers, a transmitter and receiver, and three batteries:
As I said, everything was well packed. Upon closer inspection however, the right front wheel appeared to have an extreme amount of camber. While examining the suspension system to try to figure out how to adjust this, I discovered that the wheel was rubbing against the suspension arm. It turns out that the front "C" bracket is broken. Man, there's nothing more frustrating than to get a new toy only to discover it's broken.
I sent a support email to HobbyKing and am waiting on their response. Unfortunately, Hobbyking appears to be an eastern hemisphere low-cost leader and their support reflects that. I've been waiting over four days for a response to my support ticket.
The broken part is a fifty cent replacement part, but I found that it's only stocked in Hobbyking's international warehouse, which means it could take weeks before I receive it. I went ahead and ordered a replacement, along with a bunch of other replacement parts, because I have no faith in Hobbyking's support.
However, that won't stop me from starting to develop my code. My first task is to get some kind of logging going on. I'm planning on grafting FatFs to the SDIO example in the Standard Peripheral Library, which seems to be very well documented in the comments. I have a SD card slot that I ordered from eBay. I hope to find time to wire it up and test it before the weekend is out.
I also finished code last night to get the microcontroller's TIM2 PWM outputs to generate servo signals on channels 1 and 2. I spent a LOT of time wondering why the timings that my Saleae logic analyzer was showing me weren't consistent with my calculations. I finally discovered that the HSE_VALUE in stm32f4xx_conf.h, which defines the crystal frequency, is set to 25MHz when the STM32F4DISCOVERY board is fitted with an 8MHz crystal. Changing the constant in that header file fixed the problem and ended several hours of banging my head against the wall. My code now outputs a 1ms to 2ms pulse every 20ms and does so using the features of the hardware timer, so once the value is set no code is required to maintain a constant signal.
I'm debating between using the STM32F4DISCOVERY board on my final vehicle, or laying out a custom board with the same processor on it and making something a lot smaller and tailored to the task. I'm leaning toward a custom board but I'm a little leery of soldering some small SMT parts on there. I can do SMT passives no problem, and leaded chip packages are manageable, but one of the parts I'm looking at using is a 4mm by 4mm LGA 24 package. That's some pretty tight pin spacing with no access to the pads once the part is on the board. If I go this route I plan on using the Sparkfun Reflow Skillet method.