Week 6: NXT Sensor Data Spec

As I'm still waiting on the NXT, I went ahead and did some reading into how Lego currently communicates with their digital sensors. As we can directly control the I2C link we can implement the communications protocol however we want, but it's probably good to learn how it's performed as it is now.

Briefly summarizing what I learned, the Lego spec adheres to the master-slave rule that I2C normally operates with. The slaves will sit idly on the bus lines, happily processing whatever input they deal with. They will continue to do this until the NXT polls them for data, at which point they reply over I2C with a packet containing the relevant data. They then continue on without much pause. Now the interesting twist to this routine is that the digital sensors are capable of storing and receiving multiple data values.

To clarify, each sensor is responsible for maintaining a local bank of I2C accessible registers. These registers are updated with whatever data is relevant to the process that a particular sensor is performing. For example in a compass sensor, the sensor itself keeps a particular register updated with the current heading. When the NXT polls the compass, it will specify that register in its data request packet, at which point the sensor retrieves the register value and transmits it back to the NXT.

Fig 1. Simple visualization of the register bank concept.

This is interesting because it opens the possibility for multiple data values to be processed by a particular sensor, while still keeping them accessible from the NXT. Particularly in our case, we could fold multiple sensor functions into our Arduino, and still only require one I2C line to return all of them. This also opens the possibility of bidirectional communication, allowing the NXT to send messages to the sensor to be processed. These could be configuration values, or they could be commands. For example the NXT could signal a particular color to be turned on in an LED strip, or the SSID to search for in a WiFi module.

A quick aside: just to make sure the ChipKit is working I uploaded some basic Arduino example programs to the ChipKit, everything seems to be fully compatible.

Idea: Wireless sensor capacity is possible, by linking an Arduino to the output of an I2C line as we're doing now. However instead of the sensor being locally attached, the Arduino can wirelessly interface through an XBee or WiFly controller, or even a Spark Core.

Week 5: Doldrums

I'm still waiting NXT hardware, and so there isn't too much to report on this week. I'll keep it short: while I have the interconnect between the NXT and ChipKit laid out, I ran into the issue of not being sure how I'm actually going to physically connect the two together. It is possible to simply take a sensor cable and cannibalize it to expose the necessary outputs, and in all likelihood what I'll do for my purposes, however making a bunch of these connectors for classroom use is probably going to be a hassle and less reliable than a more...manufactured approach. Ideally I feel an RJ12 breakout would be the most suitable option, especially given that the class will implement any custom sensors on a breadboard.

To be completely honest I spent a good deal of time experimenting with EAGLE-CAD fashioning a connector to attach directly to the ChipKit. However for the sake of usable results here is a link to an open-sourced NXT connector breakout kit, with assembly available for an extra cost.

https://store.wayneandlayne.com/products/bricktronics-breakout-board.html

Week 4: Software-side of the I2C communication

I haven't received the NXT for experimentation yet, and I apologize the next few entries may be somewhat short. In the meantime I've been covering some ground on how the software will implement I2C communication between the NXT and ChipKit.

Looking into the ChipKit, it appears that when they say "Arduino Compatible", they really mean Arduino-022 compatible. I'm not going to be sure if this is an issue until I test on hardware, but I just want to note that Arduino-022 and the related libraries are very much out of date. As of late 2011, the Arduino Foundation has released the much newer Arduino v1.0, and all library development has migrated to support that codebase. As many of the v1.0 core libraries are not backwards compatible with Arduino-022, I'm going to have to rely upon the older libraries. I'm not entirely sure what this spells for documentation purposes.

In particular, the library needed will be the Arduino Wire library. This is the Arduino library responsible for managing any hardware I2C function, and while it is possible to bitbang the communication in software, I'd rather stick with what is established. The Arduino Wire library is very straightforward, requiring the device to be initialized with an I2C bus address and communication interrupt handlers during the init() function. I'll explore this part later when I begin coding the ChipKit side.

On the NXT side, the RobotC API exposes two functions for handling I2C access. They are 'sendI2CMsg' and 'readI2CReply' respectively. The I2C send is fairly self explanatory, it will send a message packet on a particular sensor line (remember there are 4) to a particular I2C address. The readI2CReply will send a data request packet across the bus to a specified address, then proceed to receive a user-program specified number of bytes as a response. I will explore this in further detail once I begin NXT coding.

As an aside, I want to make note of an irregularity with the way the NXT handles I2C addressing. The Arduino must be initialized with a particular bus address, it can be anything but I2C only provides 7-bits of addressing so keep to that range. The NXT must be initialized with the same address so it knows where to address the packets it sends on the sensor data line. Even though the NXT and Arduino are directly connected, they are still operating with I2C and thus use address-based communication. However... the address provided to the NXT in RobotC must first be bitshifted left by 1 bit!!!! For example this makes an Arduino I2C address of 0x0A into 0x14, and so on the NXT side all packets will be addressed to 0x14, while the Wire library on the Arduino must be provided with 0x0A. I'm not sure why this irregularity exists, but I'm rolling with it.

Another aside: It should be possible to daisy chain multiple sensor devices off a single port due to I2C being a bus. I'm not going to explore this, but it's an interesting idea.

Also below is the link to the RobotC NXT API, which contains documentation for all NXT-related functions provided by RobotC.

RobotC NXT API:

http://www.robotc.net/support/nxt/MindstormsWebHelp/index.htm#page=nxt_functions/Sensors_Digital/Sensor%20Digital.htm

Week 3: Examining the I2C Option

Now that I know I'm going to be communicating with I2C, I feel that a quick refresher is in order...more for my benefit if anything.

To briefly sum everything up, I2C (Inter Integrated Circuit) is a bus protocol that facilitates communication between embedded electronic components. The hardware side specifies a two-wire system, consisting of an SDA line (Serial Data) and an SCL line (Serial Clock), both pulled up to whatever logic level is used. All devices on the bus are connected to these two lines, and all communication occurs when a designated 'master' device initiates comms. As the protocol (and our implementation) has it, the master is the only device that can initiate communications, the slaves are entirely reactive.

Fig 1. Example I2C configuration from Wikipedia.

In our system the NXT is the obvious choice to be the bus master. The way I envision the system working has the Arduino independently operating separate from the NXT as an I2C slave, to be polled for info when it is needed. The systems will obviously need to be connected, and thus I researched the pinouts for the NXT's sensor jacks. The lines very neatly expose the SDA/SCL lines in addition to Vdd and an AREF signal (GND). Given that the Arduino operates on a 5V logic level, the lines need to be pulled up with specific resistor values. Going off the suggestion of a site I found (link below), I am proceeding with 82K resistors. After all is said and done, we are left with the connection detailed below.

Fig 2. Basic I2C connection between NXT and Arduino.

One possible issue which may be apparent in the above schematic is that the NXT provides 4.3 volts in its sensor lines. This may be an issue if the Arduino is picky about its logic level voltages, however I am of the opinion that the I2C facilities (and the Wire library) of the Arduino are capable of operating with such voltages.

It bears mentioning that I do not have the full suite of hardware yet, and am thus still in the planning stages. Until I receive all the necessary equipment, the next few posts may be somewhat sparse. In the meantime though I have a pretty monumental decision to make regarding the dev environment for the NXT. The main contenders are LabView for Mindstorms which operates using the graphical language NXT-G, or RobotC which utilizes traditional C. Having taken ECE 1882 I know how painful it is to use LabView on the NXT, and that I despise it with all my soul. Thus my completely unbiased and scientifically formulated conclusion is that RobotC be used at all costs.


Resource website with NXT-Arduino info, a good deal of my work is derived from here:
http://www.dexterindustries.com/howto/connect-the-arduino-and-the-lego-mindstorms-together/

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.