Mar 26, 2008

NXT-G 2.0 : Datalogging

I was very lucky to attend one of the recent LEGO engineering conferences in Brisbane, organised by LEGO Education and presented by Melissa Pickering from Tufts University (home of RoboLab)

One of the highlights was a quick demonstration of NXT-G 2.0, which will include a specific datalogging section. No screenshots are available as the graphical interface is still under development, but they are looking at a January 2009 release date.

It looks great and has two levels to it that I could make out. The first level requires no blocks whatsoever, rather it opens a dialog box asking what sensors you have connected to each port and for how long you wish to sample. This suits a handheld logging experiment as you cannot move motors or perform other actions while logging. The second level introduces a 'datalogging' block which does the same thing, and include it with all your regular blocks in your program so you could drive a robot around, collect some data, move to another spot and collect some more data etc.

If you are connected to your computer when taking data (bluetooth or USB)
NXT-G 2.0 will show a realtime graph of the data being collected. One of the nifty features they showed was the 'predict' mode, whereby teachers could pose a question about what shape a data set would look like, students could then 'predict' what the data would look like by using a pencil tool to draw it out, and then run the experiment over the predicted data to see how closely they matched. All data will be exportable in text file format for analysis with other programs (excel etc)

The other big change that was presented was 'exportable' myblocks. This means that if you are using myblocks, you just save your file as normal, email it to whoever you want, and the program will run without needing to send the individual myblocks as well.

NXT-G 2.0 is being released by LEGO Education, not LEGO Retail, so it may be a little more difficult to find. They will be including 4 projects with the software, the most impressive being a probe dipper that can raise/lower a probe into a beaker and also rotate between beakers.

Overall it looks great and I can't wait to get my hands on it.

--
Damien Kee
www.domabotics.com

18 comments:

Andy said...

Hey, it isn't April 1st yet :P
But is there any other "major upgrades" than the datalogging function? Ofcourse their maybe fixing some bugs and other small things like they did from NXT-G 1.0to 1.1. But to be honest, if there won't be any other major upgrades in it I most likely won't buy it. But I'm sure alot of schools would appreciate the function though :)

-Andy

Brian Davis said...

To be honest, Andy, we're not all in on this "next step" for NXT-G - it's being done largely through LEGO Education, while the original MUP/MDP/MCP is associated with LEGO Retail. But knowing the requests from the education community, and the fact that it's being branded "2.0", I suspect there will be a few more additions to the product.

--
Brian Davis

Anonymous said...

Ah I was wondering how long it would take to incorporate this. My LEGO Ed representative has been giving me the hard sell for ROBOLab solely based on it's ability to do data logging and graphing within the program. Since I'm more interested in the scientific applications and making it easy for elementary age kids to do data logging, I look forward to this upgrade.

LEGOmom

AlexD said...

I think a clarification is needed. One can of course data log under NXT-G even now - there are files, timers, etc. What is difficult is to a) sample quickly and b) sample uniformly. But even Robolab's specialized dataloging structure cannot sample faster than about 300Hz, so it's not just a software issue. A benefit is that Robolab has a built-in workdesk where many analyses may be run. Apart from that - save to a file on the NXT, download the file to your desktop and do whatever you like with it, nobody is stopping you.

Damien Kee said...

Andy, like Brian says, not everyone will be interested in this, and the decision for it only to be offered by LEGO Ed shows that this is where they see the market for it.

Brian and I have both done some fun datalogging without the upgrade, do a search on datalogging in the posts.

It certainly does now bring it up to par with RoboLab. Now all they need is pre-emptive multitasking :)

damo

Chris Bracken said...

I was in Sydney for the same LEGO Engineering Education conference with Melissa Pickering - a very enjoyable day of all things NXT. A highlight was the presentation of NXT-G 2.0. I have been a big fan of Robolab over the years but have always baulked at the opportunity to use the datalogging with my Science/Physics classes. This was mainly due the excellent hardware and software that PASCO produce (and the schools I have been at have invested in). I can see this now changing. What struck me was how easy it will be to sample (for teachers and students)the how easy the software is to use. The exciting thing will be that it will give students much better access to datalogging which by and large has been in the teacher demonstration domain. Very exciting. I will be interested to see more details on things like sampling rates, it also had a nice linear fit function - I mean't to ask if it had polynomial fit curves as well. Having said that exporting to Excel was very easy which opens up a raft of analysis anyway.
Cheers
Chris

Joshua Heinzl said...

The main problem: maximum sampling rate will be 10Hz. RoboLab is still the way to go.

I don't recall there being any other improvements, but I could pull out my notes and check.

Josh

Anonymous said...

Josh

What is the RoboLab sampling rate?



Why is 10Hz a problem?



Please do check your notes.

Andy said...

Damian and Brian, thats true, after I read the post once more I started to think, maybe this is something for me afterall because of the "datalogging block" mentioned. And what would have made me certain on buying it is if they made a block that displays a graph (maybe even several kinds of graphs) from the values in a txt file, or real time. That would have been awsome, but unlikely I think.. But it should be possible to make..

-Andy with his crazy ideas :P

Brian Davis said...

As to the sampling rate, Robolab is going to be faster than NXT-G... but keep in mind on the NXT, sampling rates faster than about 300 Hz doesn't gain you anything, because the sensors can't change their values (or report those changes) faster than that. If NXT-G 2.0 can "only" reach 10 Hz, that's plenty for a lot of things, and Robolab only gets you about a factor of ten over that (& for some sensors, it's far worse - the US sensor will not update that fast, for instance). Under NXT-G v1.1 I regularly log data at 100 Hz, so it's again fairly close to Robolab in that regard... if v2.0 is limited to 10 Hz (does anyone truly know?), it may be that it can be set to generate either an average, or a max/min, or something similar... in other words, the NXT-G v2.0 10 Hz limit may be on "massaged" data, because the block is doing some time-averaging or other binning of data. Yep, I far prefer original raw data as well... but clearly that's not the goal of v2.0, because v1.1 already does that, and does it well. I suspect what v2.0 addresses is the ease of logging and displaying that data... and for that, a custom block with a lower sampling rate but a higher amount of "in line" processing might be exactly what you want.

As to why high sampling rates are desired, think about measuring the accelerations on something as it hits the ground during a fall. If you only record the acceleration every 1 second (a 1 Hz rate), the imapct accelerations may very well occur during a time when the program is not "watching" or recording the sensor - so it's not a very good representation of the event. On the other hand, high sampling rates often are much "noisier" than low samples (properly done), and require more post-processing & interpretation.

Andy, as far as a "graphing block", sure, that's doable - even adding the ability to scroll the graph back and forth and rescale it should be possible under v1.1. But I'm not sure I see the need, when I generally have a perfectly good computer sitting a short distance away. Right tools for the right job sort of thing.

--
Brian "still long winded" Davis

Joshua Heinzl said...

Yes, Brian - it's 10Hz. I talked with Toren at the RoboLab symposium - it's confirmed. I can't comment on the difference in speeds between 1.1 and 2.0 because I don't know much about NXT-G, but I did talk with the LEGO rep straight from Denmark.

Brian said just about everything - for things like acceleration you need much better than 10Hz. Toren and I agree, NXT-G is still no match for RoboLab in terms of processing power and datalogging speed.

Josh

Damien Kee said...

Joshua,

When I was speaking to Flemming, he wouldn't give me a definite on sampling rate. He said it would definitely by at least 10Hz but *most likely* be around 100Hz. He wouldn't commit to a number as he said the firmware guys were still working on it.

--
damo

Chris Bracken said...

Great posts guys - very interesting stuff. I totally agree with acceleration, but there are other experiments/demonstrations in class I have done where sampling rate was important (eg. diffraction of light, impulse/momentum etc and you guys can probably think of many more!)
PASCO now uses datalogging that samples at 250,000 Hz (which is much more than I can image you would never need). They do point out that "When sampling at rates less than 100 samples per second, circuit noise can be visible on a data graph. The 750 Interface, however, provides 8X oversampling to reduce noise and provide smoother data curves.". If Flemming is right in what he said to Damien (ie. they are considering 100Hz), then I hope the firmware guys are logging our discussion!

Brian Davis said...

Josh - I'm not sure you understood my points. First, you can reach 100 Hz sampling under NXT-G, but you may not be able to do it in a special "add in" - let's face it, if you want speed, you want a low-level implementation, not something that's hiding or adding things for "ease of use". Second, you may be able to look like you are reading a sensor ever 1 ms, or better... but if the sensor only updates every 3 ms (like all the RCX-class sensors) or every 10+ ms (such as the US sensor), reading it faster has absolutely no purpose (I may be a speed reader, but if I can only turn the page once every hour reading the book is going to be limited by that, not how fast I can read).

Yes, Robolab is faster - but that doesn't always give you what you need. And if you want raw speed, skip it and jump to something like RobotC. There are different solutions out there for different folks & different applications.

Yes, PASCO has loggers that sample much higher than the NXT... so does Vernier, National Instrument, and lots of other datalogging companies. Just repeat to yourself something a wise man once told me about the NXT... it's a toy. Remember that. An amazing, powerful, flexible, educational, and imaginative toy... put it's a *toy*. If you need datalogging at 1000 Hz, this is not the platform. But if you want rough, low-frequency datalogging with some amazingly simple, yet useful sensors... then this is a very, VERY useful toy. Under NXT-G, Robolab, NXC, Java, pbLua or RobotC (the last two, to my knowledge, much faster than the previous offerings, if what you really need is speed).

--
Brian Davis

Joshua Heinzl said...

Brian,

I understand what you mean about implementing datalogging at a lower level. Point is you could already do that, so the new datalogging implementation isn't as important, especially with the reduced speed.

Can NXT-G log at 100Hz without using LabView Toolkit? (because almost anything in labview toolkit can be done directly in robolab, with labview)

We should test how fast RoboLab and NXT-G (and possibly other languages) can sample compared to how fast the sensor actually updates.

Josh

Joshua Heinzl said...

Damien,

Were you at the LEGO Engineering Symposium in January? If anyone recalls, I asked the question about frequency of datalogging directly.

Josh

Brian Davis said...

Joshua-

My point was that while the 10 Hz rate might seem slow, that's not a limitation of NXT-G - only of the "wrapper" imposed by a nice front end for kids by a custom datalogging environment. If you want faster, it's there. And a great place to take kids to "NeXT".

> Can NXT-G log at 100 Hz without the Toolkit?

Well, I just tested it. The program took me 20 seconds to write, and about that long to download. It can log the light sensor, timestamped, every 10 ms. That's 100 Hz. The program is just four blocks in a Loop, and a 10-year-old can easily program it (in fact, my 11-year-old just did this, for a science fair project, on his own). It's not hard. In fact, slowing it down "correctly" (so you don't have the problem of undersampling data) is a more signigficant problem... perhaps exactly why the NXT-G v2.0 Educational release has a custom system, so kids don't *have* to deal with that.

As far as wanting truly fast datalogging, both pbLua and RobotC end up smashing everything else I've seen... but they are still, in the end, limited by the sensor update rates and FLASH writing rates (although the second you can get around by not using FLASH, or using it in very efficient and specific ways).

--
Brian Davis

Damien Kee said...

Joshua,

Sorry I couldn't make it to the Symposium (long flight from Oz) but I did ask the same question at the Australian conference last week. perhaps they have improved the code since then and are more confident with the higher sample rate.

Brian is right with the whole 'wrapper' issue, essentially they are prettying up the GUI so that you don't have to think about the individual blocks. I think benefits a lot of teachers as so many I talk to struggle with learning a new piece of technology.

Yes I know it is easy for those of us experienced to put together blocks, but I think LEGO Ed is aiming towards those teachers who don't have the support and are not sure where to look for it.

Teachers todays are already loaded down with way too many things to teach, combined with their ever increasing administrative workload, that they find it difficult to find the time to 'play' with these new concepts.

--
damo

Related Posts Plugin for WordPress, Blogger...