Does this work in tracking mode?

[te316]

It seems the TREK 1000 eval system comes with 4 boards to facilitate tracking mode. 3 of them are stationary and 1 is the moving "tag" I guess.

Would I be able to emulate the same TREK 1000 system if I put 4 of these together? And then be able to receive 3D location data on one of the stationary boards?

If yes, I wouldn't have to buy the TREK 1000 eval system then, right?

Sorry about the newbie question - I am just a hobbyist and want to be able to track something like a robot...

[thotro]

Hi there,

yes, right, for proper trilateration of a tag's position in 3D 4 (or more) stationary anchor nodes are required to track a number of moving tags.

TREK delivers the boards, drivers and the required ranging software to do location sensing.

This repo only delivers the driver and some reference examples (including one for ranging) for Arduino. But you can easily implement location sensing (as you said) by using 4 modules with the driver. Though, the location sensing code is something you have to develop on your own, as I couldn't find time yet to do it. ;-)

Hope it helps! If you need any support or further pointers in case you decide to do it by yourself, please just let me know.

Best, Thomas

[te316]

Thomas,

like I said I am a newbie to dw1000 and arduino, so please excuse my questions. Does your code provide some the functionality to measure the distance between two tags at regular intervals? Like a callback that gets called every x milliseconds that provides the distance between two tags? I am asking this to visualize the amount of work that would need to be done to do the trilateration.

I guess it's more of a question as to how the dw1000 works. It seems you would put a stationary tag, S1 at 0,y - another one, S2, at 0,0 and a third one, S3, at x,0.

Then as the moving tag M1, moves, some kind of callback (with distance info) is happening on which ones?

If you knew the distance between S1 and M1, S3 and M2, you could pretty much calcuate the coordinates of M1 with some simple trig calcs, right? Then distance between S2 and M1 adds even more precision to this.

Is that generally how the system would work?

And if so, given that it seems TREK1000 has a master stationary tag that consolidates all the info which then over USB is transferred to the PC app (for visualization), how does the distance info of the other tags get to the master tag?

Or is it the moving tag, M1, that has distance reporting callbacks for every stationary tag (S1, S2, S3) and in return it reports all of this info over the air to the master tag?

Sorry if I have this confused...

On Tue, Jul 21, 2015 at 2:03 PM, Thomas Trojer notifications@github.com wrote:

Hi there,

yes, right, for proper trilateration of a tag's position in 3D 4 (or more) stationary anchor nodes are required to track a number of moving tags.

TREK delivers the boards, drivers and the required ranging software to do location sensing.

This repo only delivers the driver and some reference examples (including one for ranging) for Arduino. But you can easily implement location sensing (as you said) by using 4 modules with the driver. Though, the location sensing code is something you have to develop on your own, as I couldn't find time yet to do it. ;-)

Hope it helps! If you need any support or further pointers in case you decide to do it by yourself, please just let me know.

Best, Thomas

— Reply to this email directly or view it on GitHub https://github.com/thotro/arduino-dw1000/issues/13#issuecomment-123417215 .

[thotro]

No worries and no need to excuse for your questions! :-)

Basically, the Arduino library gives you the ability to communicate with the DW1000 modules. These modules require quite some configuration and the intention of the library is to simply and minimize configuration efforts. That is pretty much all it does, meaning there is no actual ranging/location sensing functionality that is part of the driver library. A host application (i.e. your Arduino sketches/programs) would use the DW1000 driver to implement location sensing protocols/algorithms if this is your application use case.

The driver library assists you in two essential ways to accomplish ranging/location sensing:

• Plain communication of messages between DW1000 modules
• Exact timestamps to track how long it took to send/receive a message

Furthermore you find reference examples in this repo that show the usage of the library, including one where an anchor node computes the distance to a tag node (have a look at the examples folder, this could be a starting point for you).

This reference example implements an asymmetric two-way ranging approach (see DW1000 user manual, section 12.3.2) in which a few messages are exchanged, times of flight are captured and an average flight time is computed; multiplied by speed of light/radio waves gives the distance between the nodes. Note that there are many different approaches to compute range, all involving different infrastructure setups and protocols.

You can easily expand the ranging example to 4 anchors instead of 1, hence each anchor's computed range can be fed into an equation to get the single solution that reflects the position of the tag in question.

Regarding the communication of results to a master node: First and foremost the DW1000 is a radio transceiver, meaning it is built to communicate data (!) over the air; so gathering ranging results is easy. Only if you have huge amounts of tags, density of radio signals might be an issue and you would need to consider wiring your anchors together instead.

Hope I could clarify things a little more, Cheers, Thomas

[te316]

Thomas,

Thanks for that - it's a lot clearer now. I had thought that there was some ranging stuff already built in to the chip and that the trek1000 board basically had firmware to utilize this to create a coordinate system etc.

I love the idea of doing this with an arduino as opposed to buying a trek1000 but it seems part of the trek1000 kit and the source code is actually the calculations for tracking

So I am a little intimidated with the idea of reinventing the wheel on the tracking calculations.

They claim about a 10cm precision I think. Do you think if I take your example and extend it to 3 anchor tags I would be able to get close to that kind of precision? I know I should just try it but before I decide to do that I just need to convince myself getting close to the results of trek1000 is possible.

Thank you

On Jul 21, 2015, at 7:33 PM, Thomas Trojer notifications@github.com wrote:

No worries and no need to excuse for your questions! :-)

Basically, the Arduino library gives you the ability to communicate with the DW1000 modules. These modules require quite some configuration and the intention of the library is to simply and minimize configuration efforts. That is pretty much all it does, meaning there is no actual ranging/location sensing functionality that is part of the driver library. A host application (i.e. your Arduino sketches/programs) would use the DW1000 driver to implement location sensing protocols/algorithms if this is your application use case.

The driver library assists you in two essential ways to accomplish ranging/location sensing:

Plain communication of messages between DW1000 modules Exact timestamps to track how long it took to send/receive a message Furthermore you find reference examples in this repo that show the usage of the library, including one where an anchor node computes the distance to a tag node (have a look at the examples folder, this could be a starting point for you).

This reference example implements an asymmetric two-way ranging approach (see DW1000 user manual, section 12.3.2) in which a few messages are exchanged, times of flight are captured and an average flight time is computed; multiplied by speed of light/radio waves gives the distance between the nodes. Note that there are many different approaches to compute range, all involving different infrastructure setups and protocols.

You can easily expand the ranging example to 4 anchors instead of 1, hence each anchor's computed range can be fed into an equation to get the single solution that reflects the position of the tag in question.

Regarding the communication of results to a master node: First and foremost the DW1000 is a radio transceiver, meaning it is built to communicate data (!) over the air; so gathering ranging results is easy. Only if you have huge amounts of tags, density of radio signals might be an issue and you would need to consider wiring your anchors together instead.

Hope I could clarify things a little more, Cheers, Thomas

— Reply to this email directly or view it on GitHub.

[thotro]

I'm sure TREK is a good starting point if you simply evaluate tracking capabilities and don't want to prototype, solder, program etc. right from the beginning. Although, in my experience it is pretty easy to get the Arduino working with the chips too. I'm also not aware of how easy it is to extend the TREK source code in case you have specific demands regarding post-processing of the data.

I wouldn't call implementing a trilateration algorithm and a certain message exchange protocol "reinventing the wheel", as it is mostly the plain, simple math you would just use on another platform (i.e. Arduino).

Here I'm still in optimization phase: I would say I can get as close as +-15cm at the moment, but no averaging, no sophisticated filters and no 4 anchors are yet involved to further smoothen the results.

Hence, I'm hopeful that in the end it will be the +-10cm. :-)

Cheers!

[te316]

I am going to give it a try :) I'll let you know how it goes.

On Jul 22, 2015, at 6:30 AM, Thomas Trojer notifications@github.com wrote:

I'm sure TREK is a good starting point if you simply evaluate tracking capabilities and don't want to prototype, solder, program etc. right from the beginning. Although, in my experience it is pretty easy to get the Arduino working with the chips too. I'm also not aware of how easy it is to extend the TREK source code in case you have specific demands regarding post-processing of the data.

I wouldn't call implementing a trilateration algorithm and a certain message exchange protocol "reinventing the wheel", as it is mostly the plain, simple math you would just use on another platform (i.e. Arduino).

Here I'm still in optimization phase: I would say I can get as close as +-15cm at the moment, but no averaging, no sophisticated filters and no 4 anchors are yet involved to further smoothen the results.

Hence, I'm hopeful that in the end it will be the +-10cm. :-)

Cheers!

— Reply to this email directly or view it on GitHub.

[greymfm]

I'm using the Arduino DW1000 library now for 2 days, and it's great (much cleaner than the Decawave code). My aim is to develop a particle filter C++ class for it (my javascript implementation+simulation here: http://grauonline.de/alexwww/ardumower/particlefilter/particle_filter.html), so in the end we can have some 2D-position estimation solution with this. Will let you know when there's something to see.

[leosayous21]

Are-you going to use odometry in you robot implementation or just the range from the beacons ?

[greymfm]

Input for the particle filter is: distance/power from all 'beacons' and optional: any estimations about the robot steering (distance/angle). Actually, it will work without those estimations, but it is more precise. In general, for a particle filter, the more estimations you have, the more quickly it will find the position 'solution'.
But before, I have to learn more about some definitions ... e.g. 'tag', and 'anchor': what is the exact definition for it. I could not find an exact definition yet. TAG is moving, the ANCHOR is always fixed - Or something else? Thx, Alexander

UPDATE: Maybe we can add something like this to the README page: Includes: ranging feature with TAGS and ANCHORS TAG: wants to compute range to any surrounding ANCHORS ANCHOR: helps the TAG to compute ranges message flow:

1. TAG periodically broadcasts (blinks) to ANCHOR
2. ANCHOR acknowleges the blink (ranging init)
3. TAG responds
4. ANCHOR computes range and transmits range report to TAG I don't know all details yet ...

[hiatheeq]

Just now i started working on TREK 1000 .. I am facing STM32 virtual com port error.. I a using Windows 10 .. pl help me