search

ddworken / nxt-python

Automatically exported from code.google.com/p/nxt-python
GNU General Public License v3.0
0 stars 0 forks source link

find_one_brick() and find_bricks() discovers not necessarily NXT devices #16

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
1. Enable several bluetooth devices near the computer
2. try locator.find_bricks() - it will return all of them
3. try locator.find_one_brick() - it will try to get a random device and will 
raise an exception if connection fails (i.e. that random device is not paired).

A simple, but not clean though way to eliminate the problem is to ensure that 
device's name is "NXT". At least the module wouldn't try to connect to 
stranger's laptops.

Original issue reported on code.google.com by m%fulc...@gtempaccount.com on 9 Nov 2010 at 2:25

GoogleCodeExporter commented 9 years ago 
This shouldn't be a problem...I believe it checks the vendor strings for the 
right values, but I will check this. Were you using v2.x or v1.x? What OS are 
you on?

Original comment by marcus@wanners.net on 9 Nov 2010 at 3:17

GoogleCodeExporter commented 9 years ago 
I use the latest version of nxt-python (checkouted it from here few hours ago), 
Ubuntu 10.10. bluetooth module is pybluez.

find_bricks() returned devices contained macbooks and phones, i.e. my Nexus One.

Original comment by m%fulc...@gtempaccount.com on 9 Nov 2010 at 5:43

GoogleCodeExporter commented 9 years ago 
I took a look at the code and am going to look at including this as a feature 
in the next release. As a workaround, you can specify the name of your brick 
when calling find_one_brick().

Glad to hear you're running the same system as me, should make testing a tad 
easier.

Original comment by marcus@wanners.net on 9 Nov 2010 at 6:39

GoogleCodeExporter commented 9 years ago 
Yeah I've found this workaround, just reporting about the problem.

Btw sorry for offtopic but if I need precise motor movements is it true that I 
should use USB connection? For example, if I need to turn it by 90 degrees.

Original comment by m%fulc...@gtempaccount.com on 9 Nov 2010 at 8:51

GoogleCodeExporter commented 9 years ago 
No problem. USB has less latency and so will be more repeatable (and presumably 
more accurate, if I have calibrated it correctly) when it comes to motor 
braking. If you really need precise motor movements, I would recommend 
simultaneously running an NXC or NXT-G type program on the brick (you can start 
and stop it from nxt-python) which you would use the mailbox system to send 
commands to. And there is also the multithreading feature in the current svn 
which will come in handy.

Original comment by marcus@wanners.net on 9 Nov 2010 at 11:04

GoogleCodeExporter commented 9 years ago 
I name my NXTs for easier identification, and nxt-python even has an API to do 
this, so there would have to be another method to verify that the device is an 
NXT. Surely running a firmware check would confirm the device's identity, or 
else throw an error.

Original comment by Zonedab...@gmail.com on 11 Nov 2010 at 3:00

GoogleCodeExporter commented 9 years ago 
I'm going to have to look at the bluetooth API and see how this goes. The bad 
part is that I will probably not be able to test on Mac (though I may be able 
to get lightblue working on linux). This is a major thing and will take some 
time and thinking.

Original comment by marcus@wanners.net on 11 Nov 2010 at 3:06

GoogleCodeExporter commented 9 years ago 
I've talked to rhn about it and come up with the conclusion that there is no 
reliable way to identify a BT device as an NXT. What I recommend is that you 
specify the mac address ('host') or brick name ('name') when calling 
find_one_brick(), for example:
b = nxt.locator.find_one_brick(name='mybrick')

Original comment by marcus@wanners.net on 26 Nov 2010 at 4:23

GoogleCodeExporter commented 9 years ago 
Yes, there is a way to identify NXT devices, at least way better than returning 
all devices.

See official LEGO Bluetooth Developer Kit (BDK) from here:
http://mindstorms.lego.com/en-us/support/files/default.aspx#Advanced
See File "Appendix 1", then page 23.

It'll tell you which CoD (class of device) is set for the NXT devices. Major 
class is "Toy", minor class is "Robot". So at least you can limit your device 
enumeration to "robot toys".

I'm not sure if the CoD is encoded as part of the MAC, but I've also noticed 
that most MACs of NXT devices look very similar. I'll post some of our NXT's 
MAC numbers, and you can compare to your MACs to see if you can make out a 
common prefix.
The MAC can be read out from the NXT's on-screen menu via "Settings, NXT 
Version, ID".

Some of our MACs are (last digits left out intentionally):
00:16:53:04:xx:xx
00:16:53:04:xx:xx
00:16:53:01:xx:xx
00:16:53:0E:xx:xx

Just to compare, my Bluetooth dongle's MAC begins with:
00:04:0E:.....

So this should give you two methods (maybe it's just one if the CoD is indeed 
part of the MAC) to limit your brick-search to a very narrow target group of 
devices...

Best regards as usual :-)
   Linus Atorf

Original comment by linus.at...@gmx.de on 1 Dec 2010 at 3:28

GoogleCodeExporter commented 9 years ago 
The nxt.locator code has been revamped with new logic and this should no longer 
be a problem.

Original comment by marcus@wanners.net on 30 Jun 2011 at 12:59