Introducing Zaethira - One word: Robots

So I've finally gotten around to one of my dream projects. I'm making a robot.

I'm relinquishment a little bit on my must-do-everything-myself approach I've taken to many of my projects, and I'm using some kits and some pre-fabricated circuit boards. After my experience on my Bench Power Supply, I wanted to boost my odds of getting results and focus on the fun stuff. I really think for this project, despite being something very physical, the software is going to be the most fun part, I am a software guy at heart, after all.



For the core chassis, I'm using a DFRobot 4WD Mobile Platform. It came with a chassis and motors, which saves me a tons of time, especially since I really don't have a lot of good tools (or skills) that it would take to make something better. I think the next robot I make, I'll try to design and build the chassis myself.

For tracking the robot's position, I'm going to use these optical encoders. I debated long about getting the encoders, they're "binary" encoders, as opposed to quadrature. Binary encoders can tell you how fast you're going, but they cannot tell you what direction the wheel is turning. I have enough spare parts that I probably could have built optical quadrature encoders with almost no purchases required, but in the end, I compromised. Experimenting on the encoder circuit and construction isn't where I wanted to focus. Also, 99.9% of the time I will know what direction the motor is turning, it will be the direction I told it to turn, the motors are geared, so there is not much coasting.

The robot is divided into so two "modules" (for better lack of a term). There is a "low level" module that is controlled by a Parallax Propeller chip. For the high level module, that will be responsible for the more complex logic, AI, and command and control, I've decided I'm going to use an STM32F4 Discovery board that I scored last year (Or was it two years ago? Time flies and blurs). Hardware wise, it's a brute of a chip/board when compared to something like the Arduino, and at $20 is comparable in price. (I snagged mine when ST was giving them away for free). 1 Meg of flash and 192kB of ram leave a lot of room to do some fancy things. The Raspberry Pi probably has both of these beat in Value for the money, but I already have the ST board.

I've already got one 'lesson learned', I built my own 'sonar' module, and it mostly worked, but I've decided to scrap it and use an off the shelf variety, since the performance and more importantly the weight will be much better than what I could easily achieve.  I'll save the details for another post. The sonar will sit atop an itty bitty servo that I'll use to collect landscape data, and together with a compass chip, and optical encoders, I think I'll be able to do some pretty fancy situational awareness logic and route planning/navigation.

One dilemma I have is what tech to use on the ST Arm board. I'm a super huge fan of .Net, and I've got an (incomplete) port to some Olimex Sam7 dev boards, and some fine souls have ported the 4.2 version to run on the discovery board. I got their build up and running on my board, and I must say, it gave me goosebumps, but enough gushing. One problems is that the Framework takes an enormous tax on the board's resources, at least 1/2 of the flash is dedicated to the framework, and I'm not sure how much ram, but I imaging it is substantial. The Olimex boards I ported the Framework to have external RAM and flash on board, so there is more than enough to spare. Would I be able to create a very elaborate application with so much of the board tied up in overhead? I'm not sure. The two other downsides are a substantial speed penalty, since you're interpreting CIL bytecode (For those of you familiar with the desktop variety of .Net, the micro framework does not JIT). Also, if the pre-compiled binary does not expose hardware features I wanted to use, I'd have to modify and re-compile the framework, not something I want to do on this project.

So I'm leaning toward going with gcc/C++, I feel C# is a far superior language and libraries for creating elegant architecture, and not having to re-invent the wheel (Almost every single dedicated C++ house I've worked for has had their own home grown string and collections.). But C++ can still get the job done, and I can do both in my sleep, and C++ makes it easier to get as close 'to the metal' as you want. On desktop applications the answer is easy, use C++ only in places where you need to be close to the metal, and do everything else in C#, but the micro framework makes it a little awkward to call native code.

Anyways, I have a few other parts for the robot in the queue, I have a Sparkfun Color LCD breakout, and a ZigBee I'm going to connect to the main board. I've also got some IR proximity sensors for the sides/rear, and I'm debating adding an IR receiver to allow for "remote control" (suggested by my son).


--P

PS. You can download the .Net MF, version 4.2 QFE2 for STM32F4 Discovery board here. I had a tough time getting the "MfDeploy" application to recognize my board on my Windows Vista machine using the "WinUSB" drivers listed for the QFE2 release, I had to use the QFE1 driver found here. I haven't tried the latest drive on my Win 7 machine, but I strongly suspect the QFE2 driver does not properly have support for Windows Vista, in looking at the "inf" file. What I did to accept the older driver was to open the "MountaineerUSB.inf" file in the QFE1 driver and change all the "A08A" text to "A08F", which is the USB PID used in the QFE2 firmware.