Week 2: Functional Requirements for the Communications Interface

Last week I investigated the NXT hardware, expanded upon some communications possibilities, and gave a very light preliminary assessment which leaned in favor of the RJ12 sensor ports currently used for COTS NXT sensors.

But before delving into further detail regarding comms, I'm going to take an aside and mention that  Professor Anderson has provided me with the board I'll be interfacing with the NXT. While I've previously been under the assumption that the "Arduino" I'd be using was a reference Arduino Uno, I've been provided with a ChipKit Uno32.

Fig 1. ChipKit Uno32

Upon some reading from ChipKit's website this particular device appears to be a clone Arduino, which claims to be fully "Arduino-Compatible". At first glance it seems far beefier than a reference Arduino Uno, and touts more I/O pins, a more robust microcontroller IC (80 Mhz PIC controller vs the reference Uno's 16 MHz AtMega328 AVR controller), and also a variety of jumpers to configure various board functionality (power regulator/hardware SPI/etc.). I've never worked directly with a ChipKit board before, however I'm banking on the "Arduino-Compatible" part for ease of use.

Back on the comms side as I've previous mentioned, I have opted to go down the RJ12 route. The primary reason for this is that it is likely to be the most documented interface for the NXT, and there is no additional significant hardware required unlike the other approaches I've mentioned. To marginally hash out the factors involved in making this decision:

• I need something workable fast, while I'd love to explore other communications options I'm limited in time and budget
• The likely scenario for this interface is during a class lab or other hands-on segment. Complexity would make achieving the overall goal, basic communications, needlessly difficult.
• The protocols in play are likely either SPI or I2C, and while I'm not an expert, I have experience working with both of these protocols.

Additionally I wanted to throw around some functional requirements of the interface:

• Needs to be capable of both synchronous and asynchronous communications
• Capable of scaling from simple sensor concepts to more involved (possibly DSP-heavy) sensors
• Not likely to be used for "high-speed" comms, here defining "high-speed" to be in excess of the capabilities afforded by I2C or SPI. However, should be capable of continuously passing data at a rate commensurate to the NXT's maximum sensor poll rate.

Given that the on-board comms (UART/USART/PCB-based SPI) are not directly exposed by the hardware, the requirement for simplicity rules out these options. Bluetooth is a contender up to the point where additional hardware in the form of an Arduino-based radio is required; I'm all for this research but budget constraints limit my frivolity with component selection.

Research into current NXT sensors and their interfaces indicated that while the sensor ports are reconfigurable to a degree, the digital COTS sensors default to I2C based communication. And thus I2C it is.

Week 1: System Overview - aka: It Begins

Professor Anderson advised that I begin my research with some investigation of what I'll be working with. I agree that 9 out of 10 times it is in your interests to know what's going on. And so I began with a systems overview, and basic requirements analysis.

Now the overall goal can be stated pretty simply: Make the Arduino talk with the NXT.

Fig 1. Eventually, the Arduino will be used to interface with custom sensor implementations, presumably breadboarded or developed as part of the new class.

Since whatever I decide to work with will revolve around what the NXT has to offer, I'll begin with some basic analysis of the NXT's hardware. Some cursory investigation yielded that the NXT is equipped with an ARM7 AT91SAM75256 embedded processor. The use of an ARM7 processor indicates that the NXT platform is deceptively robust, and among other things has native hardware support for communication options such as UART, USART, and SPI. The NXT itself is connected to a computer a la USB 2.0 cable, and the newer revisions (with which I am presumably working) appear to have bluetooth, though further investigation seems to indicate this is for remote programming and control of the NXT instead of for general use by the user program.

As far as embedded platforms go, the Arduino is fairly versatile. Any of the above communication options (UART/USART/SPI/BT) are viable to implement with the proper time and, in bluetooth's case, hardware. However all of these are relatively complex for what we need, and thus by the KISS principle I'm going to turn to the obvious low-hanging fruit: The RJ12 jacks already used by the NXT for sensor communication.

Fig 2. The four RJ12 sensor ports in all their glory.

What is all of this?

Well, to put it briefly this work is part of a semester long undergrad research effort under Professor David Anderson (ECE Dept. at GT), as part of a larger effort to expand the Special Topics course ECE 1882 into a more developed survey course. As it stands this course is currently a 2-hour freshman offering which serves as an intro to computing systems, robotics, and to an extent, embedded platforms. The main feature of ECE 1882 is the design project, in which students utilize a Lego NXT controller to implement a robot capable of performing certain tasks whilst navigating an obstacle course.

That brings us to me, and my research project.

As great as the NXT is for an introductory robotics platform, it is limited in its COTS sensor capabilities. My goal is to take an Arduino-type microcontroller, so chosen for its comparative ease of use, and find a way to interface it with the NXT, the overarching goal being to develop custom sensors utilizing the Arduino.

This blog is a rehash of my research notes, jotted down during the project. What follows is a record of my work, put into blog form. Each entry will summarize my trials and tribulations for that week, along with any info deemed of importance. Think of this blog as a collection of musings as I progress through the project, I will have a separate page which clearly summarizes my results.