Skip to main content

Datalogging the Roadrunner

One of the things that has come up recently with regards to NXT-G v2.0 and datalogging is the speed that information can be logged. It seems the custom logging option under NXT-G v2.0 may be “slow”, in that it only logs somewhere between 10 and 100 readings every second (reports vary wildly, and until I test it myself I’m in no position to speak on this). Readers have pointed out, quite correctly, that NXT-G is not the fastest option for this. Robolab, for instance, is faster, and other offerings such as RobotC and pbLua are blazingly fast. But before everyone complains about this “new feature”, consider two other important points.

First is ease of use. It seems that with NXT-G v2.0, LEGO Education will be releasing a version that has a lot of the datalogging handled for the student (or the teacher), making it easier to get and process data. That may require a slightly slower acquisition rate, but it may be more than worth it to some folks, especially if it provdes built-in smoothing, filtering, or averaging, as well as unit conversions etc. If you think this isn’t so, feel free to program in raw assembly language – the interface, the language, and the ease of use or familiarity of the environment makes a big difference on productivity, for people of any age. So “wrapping” datalogging in a nicer package, even if it’s slower, might be a very positive thing to many users. A very simple example (that could be greatly improved upon) is the "Easylog" program shown here.

Second is how fast you actually need to be. I had some people skeptical that NXT-G could log at 100 samples a second, to which I replied it could, and it wasn’t hard. In fact it can do better than that. The first image is the graph of an incandescent lightbulb turning on and switching off, as seen by the light sensor of the NXT. My NXT-G program grabbed a sample every 4 milliseconds, or 250 samples each second, more than fast enough to resolve this phenomenon (even the very rapid cool-down when the light shuts off). But if I try this same trick using the Hitechnic acceleration sensor to measure the acceleration experienced while dropping the NXT on a party balloon, it doesn’t do as well – the datalog shows only about 1 sample every 20 ms, or just 50 samples each second, much poorer performance than for the previous example. Why? Is this due to the “slowness” of the NXT-G block, & should I switch to another language?

Well, no. In fact the “problem”, if you can call it that, is primarily I2C communications with the sensor – that’s the major slow-down. But even for simple analog sensors like the light or sound sensor, the NXT can only read them out every 3 ms or so, so that is the default rate in the firmware for those. You may try to “read” the sensor much faster, but if the underlying firmware and hardware isn’t able to respond any faster, you don’t get anything new. And in at least some cases, the issue is in the hardware itself: The old RCX sensors are supposed to get 3 ms of power before a read operation – they shouldn’t be polled faster than that. And the new NXT US sensor is subject to so many delays (not bad engineering, but limited to the “slowish” speed of sound), that while NXT-G lets you “read” this sensor in just 3.6 ms, the actual value only updates every 12 ms or slower (in some cases much slower). I2C communication, which is the negotiated exchange of bytes between the NXT & the sensors, is also slow – almost always slower than what the sensor is doing (if you are playing chess by mail, worrying about how long it takes to move a piece isn’t fruitful). So while you can complain that the NXT can’t read the acceleration sensor fast enough to integrate a position curve, I’m not sure it’s a valid complaint, given the cost of the system and the large number of other things it’s being asked to do (BT, PWM motors, drive and LCD and sound system, and do it all under complete control of a general-purpose user program, not something written especially for capturing data). And it’s doing it cheap, compared with a lot of other “datalogging” products out there.

Upshot: If the hardware can only produce a sensor reading every 3 to 4 ms, then being able to log them faster than that is very rarely an advantage... just a waste of memory.

I’ll finish up with one more fun example of the slow end of datalogging. With some sensors, there’s no reason to worry about datalogging speed at all – the old temperature sensor (& likely the new one) is a very good example of this. Even when plunged from a hot to a cold environment, the sensor takes a significant amount of time to come into equilibrium with the new environment, so sampling it even 10 times a second is almost always much faster than needed. That’s not a fault of the NXT, NXT-G, or the sensor, but the physics of it (a mass takes time to change temperature, period). You can still have a lot of fun with this. For instance, I charted the temperature, sound, and light in my kitchen for more than 24 hours, at a time resolution of one minute, averaging the sound level during that interval & taking a “spot sample” of the light & temperature at the end of it. That was interesting enough I wanted to log two temperatures (above a heater vent, & near the ceiling where the humid air from the shower goes) and the light & sound in my bathroom, but I wanted it to have a time resolution of 10 seconds… and I couldn’t let it run all night at that resolution (too much data). It took me about 1 minute to add some code that allows an arbitrary start time, and ta-da, the system started up right at 5 AM, capturing everything going on in our bathroom during that morning. Including the fact that I take a longer hotter shower than my wife, and that she got home at 5:30 AM after delivering a baby at the local hospital, and still had to get up and off to work about two hours later.

More datalogging examples have been tossed into my Brickshelf folder on the subject... but I'd love to hear from other users with other examples!

PS- It's also fun to try the old standby of monitoring your refridgerator temperature along with the light. Not only can you see that the light really does go out when you close the door, but you can see how often your refridgerator temperature various and by how much... not to mention how much the temperature goes up when the kids are standing there with the door open, trying to decide what to pack for lunch. Hey, you holding open that door! How many times do I have to tell you the temperature goes up almost 0.2 degrees per minute when you do that?!

Brian Davis

Popular posts from this blog


2023 is the 25th Anniversary of the MINDSTORMS brand. For 25 years, MINDSTORMS has educated and inspired a generation of robot builders, both children and adults. Unfortunately, the LEGO Group decided to end the line on December 2022. Many ROBOTMAK3RS have been passionately involved with the development of MINDSTORMS through the MUP and MCP programs. Even with the newest Robot Inventor line, several ROBOTMAK3RS were invited to submit additional bonus models that were included in the official app. Regardless of the retirement of a major LEGO robotics product line, ROBOTMAK3RS continue to MAKE-SHARE-INSPIRE using all LEGO robotics platforms available to us. Here is the official statement from LEGO. Since its launch in September 1998, LEGO MINDSTORMS has been one of the core ‘Build & Code’ experiences in the company’s portfolio, carrying with it significant brand equity and becoming a stand-out experience for the early days of consumer robotics and leading to current Build & Code

Celebrating 25 Years of MINDSTORMS

In celebration of the 25th Anniversary of MINDSTORMS, we take a trip through history. Please also visit ROBOTMAK3RS Community every week as we highlight different projects all through 2023 in celebration of the anniversary. Some of the early history is based on the content shared by  Coder Shah  in our  MINDSTORMS EV3 Community Group . Some of the text and links may have been edited from his original posts for consistency and clarity.  1984 - Kjeld Kirk Kristiansen watched a TV program called "Talking Turtle," where MIT professor Seymour Papert demonstrated how children could control robot "turtles" using LOGO, a programming language he developed. 1988 - The collaboration between MIT and LEGO resulted in LEGO TC Logo in 1988, which allowed students to control LEGO models using computer commands. The video shows Papert demonstrating TC Logo. 1990 - LEGO TC Logo was hampered since the robots you built had to be tethered to a personal computer. LEGO and MIT

Celebrating MINDSTORMS with a Remix Part 1

In honor of the 25th Anniversary of MINDSTORMS, we asked ROBOTMAK3RS to combine a LEGO set of their choice with a MINDSTORMS set. Here is what these five ROBOTMAK3RS came up with.  MINDSTORMS Chess Assistant by Arvind Seshan Overview: When you are new to chess, it can be a challenge to remember which pieces go where. Now, you can use machine learning and LEGO MINDSTORMS Robot Inventor to build a tool to help you learn where all the chess pieces go on the chess board. Sets used: LEGO® Iconic Chess Set (40174) and MINDSTORMS Robot Inventor (51515) Review: I really like how the chess set base can store all the pieces underneath and that the board neatly splits in half for handy storage. The chess pieces themselves are very sturdy and well built. My only criticism is the building of the box itself. It was quite difficult to see what pieces to use and since the entire box is made mostly of thin plates, it took a lot of time and patience. I would have liked the storage area to be sliding dra