First a comment, I can't get to the controls, and thus cannot play, anything beyond the 'essential' video because the window size is fixed and doesn't allow access to the controls. May be a screen size issue where I am now and will retry at home.
-=-=-=-=-
Essentials NXT Introduction At 0:25 we see alphaRex, and the US sensor there is wide and the mounting pins are set slightly back (2-3 studs back)
Then at 3:30 into the video we see a computer graphic of an US sensor where the mountpoint is flush with the sensor. Maybe it's a shading/scanning/perspective issue.
If it's not, then the one pictured in the video at 3:30 is different than the photograph on peeron.
The narrator then says that the US sensor can go 'up to about 3 or 4 feet', which is a lot less than the old hiTechnic model that could measure up to 100 inches (about 8 feet). I also thought that the US sensor was based on the hiTechnic design and could read up to 100".
So -- brings into question one I asked a while ago which is:
What is the range (min/max), fidelity (1/2", 1", 2", foot") and frequency (how much time between updates) of the US sensor.
I think when I asked it last Brian indicated that the US sensor was going through some changes so he couldn't (yet) comment.
The one pictured at 3:30 is not representative of the US sensor (the light sensor here has subtle differences as well). The actual sensor does have the pin holes set back from the front, and the spacing between the "eyes" is about twice the diameter of the "eyes" themselves.
I still don't have an updated US sensor, so I still can't speak to the details (I fully expect that the first sets will ship before we on the MDP get our hardware upgraded), but the US sensors I've tested have a range of about 120 cm, with a resolution of 1 cm, and the accuracy varying from better than +/- 1 cm to perhaps +/- 4 cm at long range. The "maximum range" is highly dependant on the target and things like battery level. Note that if the US sensor is returning one byte of digital data, the maximum range reportable is 255 cm, regardless of the physical range. Since the sensor appears to handle cm-scale resolution, this one factor alone would limit it to less than 8' range.
Honest, more coming when I have a final production-based US sensor :-)
-- Brian Davis
Anonymous said…
Great to see the tutorial. As an FLL coach, I am anxious to see if I can learn the new software in time to teach it to the team in time to compete in the state tournament on Dec. 2.
Can you tell me if there is a visual indication of programming errors? In Robolab, the download arrow is "broken" if you have a problem with the construction of the program.
For me, I do a LOT of my troubleshooting with a bot still attached to my laptop via the USB cable. You will have a visual indication if you attempt to connect a wire output to the wrong input (for example, trying to send a text value into a plug waiting for an integer).
When it comes to blocks, you can drop and drop - there do not appear to be any visual clues if a logical error is made. For example, if you don't have the Ultrasonic sensor attached, but you place a US block in your program, the bot will run just fine, but when it comes time to check the U-Sensor for input, the bot will react depending on the logic of your program, with no error message. This also happens if a cable comes loose from a sensor and you're not aware of it. No error message saying "Check Light Sensor" or anything like that...
The main "error" indicators you run into are "broken wires": if a wire is not connected at both ends, or connected between the wrong plugs, it shows as "grey". Or if a block or series of blocks is not attached to a sequence beam, they appear "shadowed". In some cases, the editor simply will not let you create an invalid structure (like wiring an output plug to an input plug on the same block - a big no-no that the editor prevents). And in some cases, the editor displays things as "broken" if something is missing (example: your program used a MyBlock that you have since deleted, so the editor shows the missing MyBlock as literally "broken" to let you know).
But no, there is no "broken download arrow" in NXT-G. Most of the "error" stuff is shown as-you-go.
As to learning it in time to help your students... I think you can. It's not too hard, and I astrongly suspect at least some of us will be being educated by our students (which, ideally, is the way I'd like it to be anyway ;-).
As to the "broken wires" thing, it might be useful to know that (as to my experience) this is indeed one of the major hazards of the present NXT-G IDE: sometimes (more often in earlier versions) you get "broken wires" messages without seeing the allegedly broken wire at all. In mature modelling environments on the market, there commonly is a tree-like display of all elements contained in your program model, and amonst other things erroneous elements are marked there (and may be deleted that way). But that's not the case with the NXT-G IDE, so often the only strategy when this happens is returning to the version most recently saved (for the "Undo" utility has room for improvement still).
This is a good strategy with the IDE anyway: save often (but only after a successful download, for the IDE messages errors only when compiling/downloading - which is another irritating behavior).
Keep in mind, though, that it's version 1.0 (for which the IDE is pretty good already)- we are likely to see such enhancements in the future.
Matthias
Anonymous said…
if u say ''spend some time here'' then it's not time spending, its learning, and now i can make a easy wall follower of my own when i get my set.
Comments
One comment. The Ultrasonic sensor looks... different. Has that undergone a redesign?
Jim
-=-=-=-=-
Essentials
NXT Introduction
At 0:25 we see alphaRex, and the US sensor there is wide and the mounting pins are set slightly back (2-3 studs back)
Then at 3:30 into the video we see a computer graphic of an US sensor where the mountpoint is flush with the sensor. Maybe it's a shading/scanning/perspective issue.
If it's not, then the one pictured in the video at 3:30 is different than the photograph on peeron.
The narrator then says that the US sensor can go 'up to about 3 or 4 feet', which is a lot less than the old hiTechnic model that could measure up to 100 inches (about 8 feet). I also thought that the US sensor was based on the hiTechnic design and could read up to 100".
So -- brings into question one I asked a while ago which is:
What is the range (min/max), fidelity (1/2", 1", 2", foot") and frequency (how much time between updates) of the US sensor.
I think when I asked it last Brian indicated that the US sensor was going through some changes so he couldn't (yet) comment.
I still don't have an updated US sensor, so I still can't speak to the details (I fully expect that the first sets will ship before we on the MDP get our hardware upgraded), but the US sensors I've tested have a range of about 120 cm, with a resolution of 1 cm, and the accuracy varying from better than +/- 1 cm to perhaps +/- 4 cm at long range. The "maximum range" is highly dependant on the target and things like battery level. Note that if the US sensor is returning one byte of digital data, the maximum range reportable is 255 cm, regardless of the physical range. Since the sensor appears to handle cm-scale resolution, this one factor alone would limit it to less than 8' range.
Honest, more coming when I have a final production-based US sensor :-)
--
Brian Davis
Can you tell me if there is a visual indication of programming errors? In Robolab, the download arrow is "broken" if you have a problem with the construction of the program.
For me, I do a LOT of my troubleshooting with a bot still attached to my laptop via the USB cable. You will have a visual indication if you attempt to connect a wire output to the wrong input (for example, trying to send a text value into a plug waiting for an integer).
When it comes to blocks, you can drop and drop - there do not appear to be any visual clues if a logical error is made. For example, if you don't have the Ultrasonic sensor attached, but you place a US block in your program, the bot will run just fine, but when it comes time to check the U-Sensor for input, the bot will react depending on the logic of your program, with no error message. This also happens if a cable comes loose from a sensor and you're not aware of it. No error message saying "Check Light Sensor" or anything like that...
Jim
But no, there is no "broken download arrow" in NXT-G. Most of the "error" stuff is shown as-you-go.
As to learning it in time to help your students... I think you can. It's not too hard, and I astrongly suspect at least some of us will be being educated by our students (which, ideally, is the way I'd like it to be anyway ;-).
--
Brian Davis
This is a good strategy with the IDE anyway: save often (but only after a successful download, for the IDE messages errors only when compiling/downloading - which is another irritating behavior).
Keep in mind, though, that it's version 1.0 (for which the IDE is pretty good already)- we are likely to see such enhancements in the future.
Matthias