Posted by Marc-Andre Bazergui (bazmarc) March 08, 2019 ROBOT REMIX #6 Share Get link Facebook Twitter Pinterest Email Other Apps Post a Comment
One comment. The Ultrasonic sensor looks... different. Has that undergone a redesign?
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 :-)
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...
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 ;-).
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.