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

Celebrating MINDSTORMS with a Remix - Part 3

The ROBOTMAK3RS continued their celebration of the 25th Anniversary of MINDSTORMS through these Fall and Winter remix projects. Each ROBOTMAK3R was tasked with selecting one LEGO set of their choice and combining it with a MINDSTORMS set. Below are the five amazing models they came up with. Braill3 by Jerry Nicholls Braill3 is an EV3-based LEGO Braille bricks reader. This robot uses its fingertip, made from three touch switches, to read messages written using the LEGO Braille bricks and will speak out what it detected. If it sees a simple maths problem it will attempt to solve it and give the answer as well. To learn more about the process of creating this machine, read Jerry's blog . Braill3 can be viewed here . Set Review: The Braille Bricks set is well thought out. The ratios of the letters is suitable for general use and the addition of some punctuation and arithmetic operators is excellent. There is a card showing what bricks there are and their quantities, but no form of sort

Celebrating MINDSTORMS with a Remix - Part 2

The ROBOTMAK3RS continued their celebration of the 25th Anniversary of MINDSTORMS through these summer and fall remix projects. Each ROBOTMAK3R was tasked with selecting one LEGO set of their choice and combining it with a MINDSTORMS set. Below are the five amazing models they came up with. Remote controlled material handle r by Jozua van Ravenhorst (aka Mr Jo) This remix combines the LEGO Technic Material Handler (42144) with MINDSTORMS EV3 (31313) It uses the power of pneumatic cylinders to move objects around. By using a bluetooth remote control, very precise movements can be made with this model. Touch sensors in the base chassis prevent the turret twisting the cables that go through the turntable to much. The program has several protections to prevent over pressurizing the system for each of the 3 individual pumps and valves that control the 2 booms and claws. The real version of this machine is mostly used in waste material sites to bring the material to machines that sort and

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