Apr 1, 2008

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

8 comments:

Jim Kelly said...

Can you imagine being a kid in that household?!

"Look here, son - this spike clearly shows me that you flushed twice - a complete waste of water."

"Honey, I thought we'd agreed to set the room temp to 70? This chart clearly shows that between the hours of 8pm and 9pm someone was running the heater."

;)

Jim

Joshua Heinzl said...

Good post Brian.

Josh

Brian Davis said...

Jim- the impressive thing is my wife walkinh into the bathroom, taking a shower, getting ready for work... and only afterwards asking why there was some wired piece of LEGO hanging over her head. Talke about trust :).

Josh- Thanks. It will be interesting to see what v2.0 adds on or changes, and I'd love some data from you or others on similar tests with Robolab, RobotC, etc. You were the one asking the tough questions, so you deserve a good bit of thinks for this post as well - you made me think, and check the numbers. And in the process, have stil more fun datalogging :).

Anonymous said...

Brian,
I LOVE IT!!!! OK gotta do the refrigerator experiment. I had already planned to do it w/ the temp sensors but hadn't thought of the light sensor!

Thanks for the write up.

I agree that the interface will make things simple for teachers and students. My son recently looked at hot water cooling down to room temp and cold water warming to room temp. I then had to show him how to use Excel. No too hard, but he's 7yrs old and it was only 2 days before the science fair! Ha Ha Ha. It would have been nice to have real time data analysis and graphing built into NXT-G.

LEGOmom

Anonymous said...

Wow, that is very helpful. Thanks a lot, Mr. Davis. One question, though. How would you graph a text file in Excel?

ballebensin said...

Hi Brian
I'm looking for a simple answer for the following related item:

1) How should I make a program in NXC (or NXT-G) that can read 1-3 sensors and continusly send them to a file on my pc (the reasion for not uploading from the NXT is that the memory is too small for my planned project)
br,
legoballe

ballebensin said...

Hi Brian
I'm looking for a simple answer for the following related item:

1) How should I make a program in NXC (or NXT-G) that can read 1-3 sensors and continusly send them to a file on my pc (the reasion for not uploading from the NXT is that the memory is too small for my planned project)
br,
legoballe

Brian Davis said...

I'm not sure how you would get the NXT to "remote" the data back to the PC. The best suggestion I can think of would be to make a text file on the NXT using something like NXC or NXT-G, and then have the computer occasionally grab the file off the NXT brick. That will have it's own problems, however (closing files, keeping things synchronized, etc.).

Related Posts Plugin for WordPress, Blogger...