Robotics is in the news lately with the latest instantiation of the DARPA Grand Challenge, as pictured on C/Net. This is a 150-mile race that will take place somewhere in the southwest US – the course will be announced two hours before the race begins – and that consists entirely of autonomous robotic vehicles. Last year was something of a bust, given that no car managed to finish the grueling cross-country course, but the whole idea of this is to give the technology a chance to improve. Maybe this year someone will actually make it to the finish line.

Meanwhile, on the other side of the world they are doing their own versions of robotic races. It seems the sport of camel racing was suffering under the newly-enforced child labor laws in the United Arab Emirates. The best jockeys for these camels are children that weigh under 60 pounds or so, and “recruitment� of these jockeys sometimes consisted of kidnapping them from poorer areas of Asia.

The solution (as reported by the BBC) was the creation of a robotic remote-controlled jockey that fits the weight requirements, doesn’t spook the camels, and can work in the heat. It’s an interesting application, but this is one of those stories that really makes you wonder whether some people just simply have too much money.

Larry Mittag

One of the real weaknesses of some embedded processors is handling of floating-point calculations. This is particularly problematic in any application that requires trigonometric calculations, which can bog down embedded CPUs like XScale and PowerPC significantly. One choice has been to move to CPUs like Intel’s x86, which include much better floating-point support, but perhaps there is another way to go. A recent article in EE Times described a mathematical approach to trigonometric calculations that avoids many of the trig functions themselves.

Notice that the need for non-integer calculations is not completely removed. The calculations described use ratios of whole numbers which still require fractional calculations. The win is that these ratios should be much more amenable to fixed-point arithmetic rather than full floating point. This could significantly improve the throughput on a number of applications that calculate phase angles, potentially even allowing these calculations to be implemented in hardware rather than software.

These are the kinds of advances that can make significant differences to many embedded systems, even though they are often largely ignored by desktop programmers. I look forward to learning more about it.

Larry Mittag

Performance is a key driver in most DSP applications, but it can be very difficult to get numbers as to exactly what performance can be expected with a given CPU architecture. Specifically, if you are anticipating running DSP algorithms on a GPP architecture like PowerPC it can be very difficult to determine the effects of L1 and L2 cache on the processor throughput. Traditional benchmarks must be looked upon with a great deal of skepticism, since the compiler and library vendors often cook these numbers.

Given that, it is nice to see a realistic analysis using real DSP applications such as a report from Sky Computers that was posted on DSP-FPGA.com. It gives an analysis of several PPC-based chips running a number of algorithms that are of particular interest to DSP heads abd can provide the basis for supporting or refuting a decision to use PPC chips for DSP work.

This is an important question these days. Old-school DSP programmers can be very suspicious of GPP architectures, but those suspicions may be due to a simple lack of understanding. Do the numbers in this report help in these decisions?