Hello,
I’m planning to use your DWUSB device for RTLS purpose. I have few constraints regarding my application and it would be better if you can clarify and provide solutions for it.
In my system I’m using only one tag but the issue is the indoor space is pretty big. Its like a 100x50m space and I’m skeptical whether the DWUSB system can work in that. It would be great if you could specify the range of these individual devices.
Line of Sight is not a big issue in our case but it would be better if you could tell us the error range if there is lack of line of sight.
What is the update rate of the position when using one tag and also how would the update rate change when the no. of tags are increased.?
Regarding the setup, is it simple to setup the system e.g if I’m using 10 anchors and one tag is it enough if I just run the demo firmware in all the anchors, tag and master node or should I do some kind of data parsing.?
As of version 0.5.0.1, our DWUSBs have demonstrated full TWR functionality at distances up to 98m with clear line of sight. However, our limit for running an RTLS network is somewhere around a 50x50m space. This is partially due to the directional nature of the antennas provided in the DWUSB kits. If you were to use superior antennas, you would be able to extend the effective range of the devices, but obviously, the exact gains in range would be dependent upon the quality of the replacement antennas used.
When running an RTLS network, lack of line of sight can sometimes result in an error in calculated position. The exact error is highly dependent on the environment. The more susceptible the environment is to multipath situations, the greater the potential impact is upon losing line of sight. However, if you are in an environment that is particularly vulnerable to complications arising due to loss of line of sight, increasing the number of anchors used in your RTLS network will improve the overall performance of the network.
In the version 0.5.0.1 release, the update rate of the tags is locked at 20 Hz regardless of the number of tags used. Adding more flexibility in this regard is already on the list of enhancements to be included in future releases.
System setup solely requires use of the included DWUSB GUI software. In order to setup a network, you have to connect one DWUSB to the host PC via USB and plug in all other DWUSBs to the provided battery packs. Then, you run the DWUSB GUI software on your host PC. On first use, this software will boot into the network configuration window, from which you can configure the role and parameters of all the DWUSBs to be used in your network. Once you have finished setting up your configurations, simply hit “Apply” and then switch over to the RTLS window. That’s a basic description of the network setup process, but if you want more detailed instructions, please refer to section 3 of our DWUSB Kit Instruction Manual, which is located at: http://www.ciholas.com/downloads/dwusb/DwusbKit-Instructions.pdf
Thanks for the reply !! It is really helpful… Regarding the range, eventhough if my indoor space is huge compared to the range of the DWUSB, can I have many anchors which are placed in working range and track tags even if it is more than 50m away from the host??? I’m assuming that the tags communicate to the host through the anchors inbetween and not directly …
I also wanted to know whether is it possible to retrieve the output of the host anchor in Serial format for Data analysis??
As of release 0.5.0.1, every device on the network has to be in range of the master node, which is the DWUSB that is connected to the host PC. This requirement is in place to ensure that every DWUSB on the network can properly synchronize their timing. Without that, DWUSBs would eventually accrue enough clock drift that they would start transmitting during other devices’ transmission windows, which would lead to corrupted data. We are in the process of developing a more flexible alternative to this approach that would extend the total range of the system by removing the restriction that everything has to be within range of the single master connected to the PC, but currently, that restriction is still in place.
As of release 0.5.0.1, we have no way for the user to retrieve the raw output from the master DWUSB connected to the host PC. However, we do have methodology in place for capturing logs of the data and for replaying those logs (see section 7 of the DWUSB Kit Intruction Manual for more details: http://www.ciholas.com/downloads/dwusb/DwusbKit-Instructions.pdf), which should help greatly with analysis of the data.
So isnt there any other means to retrieve the xyz position of the object real time??? other than the GUI. I need just the real time positions of the object so that I could use that in another application. It seems like we can get it, as per the documentation. It would be great if you could confirm on that.
Yes, you can retrieve the xyz position of the object in real time without running the GUI. First, you need to configure your network using the DWUSB GUI as described above, and then you need to save that configuration as the default configuration by clicking the “Save As Default” button on the configuration window of the DWUSB GUI. Then, you can close out of the DWUSB GUI, and in a terminal window, go to the directory where you put the DWUSB GUI executable and enter “./dwusb_gui --host-only”. This will run the DWUSB GUI application in a “GUI-less” mode where all it will do is calculate the positions from the raw data coming over the USB connection with the master DWUSB and then publish those positions via a UDP stream. For more information on the host-only mode of DWUSB GUI operation, please refer to section 1.6 of the DWUSB Kit Instruction Manual: http://www.ciholas.com/downloads/dwusb/DwusbKit-Instructions.pdf.
After starting up the DWUSB GUI in host-only mode, you can then subscribe to the UDP multicast stream over which the DWUSB GUI publishes the position data. As of version 0.5.0.1, the multicast IP address is locked at 239.255.76.67, but you can configure the port to be used by this data stream via the option labelled “LCM port” in the configuration window on the DWUSB GUI. At this point, you just need to create software to parse the data coming over this UDP stream. For more information on actually parsing the data, please refer to the following forum post: How to parse position data emitted by DWUSB GUI?.
Thanks for your quick responses. I have one last doubt. Can we increase the range of the system by adding 2 master node ??? and shifting the coordinate space when the tags go beyond the boundary of one master node ???
As of release 0.5.0.1, the system only supports running with a single master node, so we cannot currently increase the range of the system by adding a second master node. However, implementing support for multiple master nodes is one of the approaches that we are considering for extending the overall range of the system.
So u cant couple a single anchor to 2 masters running in different machines ??? If it is so can you help me in finding antennas which could actually increase the range. It would be helpful if you could suggest available antennas adaptable to dwusb and also with a good range.
Unfortunately, you cannot couple a single anchor to 2 masters running on different machines. The master’s function is to keep track of the timing of the entire system. If you have 2 masters working completely independently of each other, they will try to compete for control of the timing of the network, which would ultimately result in preventing proper functioning of the network.
Also, there are not many antennas available in the market right now that are compatible with the DWUSB since it is such a new product. Unfortunately, your best option would be to look for a custom antenna manufacturer that could develop a new antenna meeting your specifications.
Do know that increasing the range of the system is high on our priority list, but developing a good method for improving our range will take time.
Can we use your GUI in ubuntu 12 04 ??? I’m not able to download libqtserialport5 it needs libc6 version of 2.17 or more. but 12 04 suports only version 2.15…
We have not tested with Ubuntu 12.04, and we do not expect it to work by default in 12.04. There are almost definitely ways you could go about compiling the libraries you need in a Ubuntu 12.04 environment, but as we have not looked into setting up our GUI on any Ubuntu system other than 14.04, we do not have much information to offer on the process of setting it up in Ubuntu 12.04 at this time.
Hello. can I have the data types of the other channels like the ANCHR, TAG, TOA.? It would be great if you could provide them …
Here is a brief description of each of the other data channels. We’ve redacted a lot of these from the uwbtalk libraries provided online to make things less complicated for end users who just want position reports from the system, as all the data in these reports is encapsulated in the position reports and the TWR reports.
ANCHR - These reports come from the anchors and contained timestamps for every packet they receive over the UWB network. It is these timestamps that are fed into our location engine and ultimately generate a position for where a given
transmission originated.
ANCMT - These are announcement reports. They are used for discovering devices within the network, assigning network ids, timing, etc.
TAG - These are infrequent packets that announce information about the tag. They are currently not used in the system.
TOA - Time of Arrival packets. These packets are generated by the host software for internal use. They contain time difference of arrival information between anchors. They are used in a TOA algorithm that exists in the code in order to generate positions.
Thank you for the info !!! I need to know the attributes of these channels. Can I get a class file for all of the above channels? I think I can work with it even if its complicated. It’l be useful to rectify the errors in my values.
Can u suggest the best anchor positions in order to reduce errors and instability in XYZ values. I’m tryin diff anchor positions and I feel that it makes a huge diff. And also can you suggest where to place the master node. Should it be in the same plane as in the case of the anchors or should it be in a diff plane ???
The LCM compatible messages that have been left undocumented are intended solely for internal use, and as a result, they do not have much practical application for general use. All of the useful information that can be gleaned from those internal messages is already included in the channels that have been documented, so it is our belief that including the internal messages in our documentation will only lead to unnecessary confusion. Instead of taking that approach, it would likely be more beneficial to specify what errors you are seeing so we can address the problem directly.
Without knowing any details about the environment you are working in, its hard to give too much specific device. However, the following are a few useful general tips for proper anchor and master placement:
The anchors, being at a level where they are obstructed by metal objects and people, will produce bad data. The UWB signal simply doesn’t penetrate metal objects or people. Thus the first path is so attenuated that all you get are multipath signals, and the first multipath signal is what gets timed. A future version of the demo code will attempt to detect when this occurs from signal properties and then deweight the anchor data in the results. Elevate the anchors to the ceiling level if you can. Higher is better as that avoids obstructions.
Master node needs to have good radio visibility to all nodes for configuration. It also needs to be in a surveyed and stable location or the results will be off. Plugging it into a laptop directly is usually not adequate, and typically orients the antenna flat. A USB extender cable to where the master is located in a more fixed location would help. Much like with anchors, having the master up high where there is less opportunity for obstructions to interfere with line-of-sight communications is better, but as the master has to be in range of all the anchors and all the tags, it is usually better to keep it a little lower than the anchors to ensure that there are no blind spots on the ground where the tags will be unable to communicate with the master.
Having only four anchors is marginal. If any one is compromised, it affects the results badly. Having more will be good.
Also, if your survey is off, then your accuracy suffers but it also causes jitter in displayed positions when a particular anchor varies. A bad survey means the solution is “fighting” between the data from the anchors to locate the best position and when an anchor leaves the fight, the position jostles a lot.
With anchors all on ceiling, make use of the bounding for the tags. If you bound the tags to be below the ceiling (say ceiling is 3 meters Z, bound tags to be 2.5 meters or less), then you will get reasonable Z axis data.
So, in short:
-
Fix master node higher, on cable, and with its antenna upward (not lying flat). Must be in surveyed location, must see all anchors as directly as possible, must see all possible tag positions.
-
Elevate anchors onto the ceiling.
-
Get more anchors.
-
Have an accurate survey.
-
Bound tags below ceiling.