New library DW1000Ranging about arduino-dw1000 HOT 10 CLOSED

Hi Léopold,

thanks for sharing your ideas: Could you maybe explain your intentions behind "msgSent()" and the "available()/read()" duo?

My 2 cents regarding such a lib: I usually would go the way along simplicity/usability over configurability - at least for an Arduino lib.

In general one could

• encapsulate and hide the entire ranging protocol; just an initialization, ranging kick-off and results feedback parts (via handler functions) are visible to programmers (as far as I can see from the sketch you want this too :-)).
• In the end there are 3 node types - I think: Tag, anchor and a collector node (could be one of the anchors as well; receives all ranging reports for post-processing - typically trilateration procedure and communication with a PC or the like)
• The collector node (obviously) and optionally also the tags receive range reports (configurable).
• In an overall system bootstrap period, devices could communicate to each other their own node type (and address), so MAC filtering can be automatically setup and knowledge about the infrastructure is gained.
• Ranging can be initiated by the collector or by the tag (in cases it needs its range/position reported back).
• Ranging can be triggered manually (at certain points in code) or periodically (configurable).
• ... and there might be more features to think of, but that's all I can do after midnight ;-)

What do you think?
Thanks,
Thomas

from arduino-dw1000.

Hi thomas,
My intentions was to keep the same common architecture as radio/communication arduino libraries (virtualWire, Serial, Ethernet, etc.).
But i think you are right: as we start to simply, we need to do it at its maximum !

here the new basic sketch: (i commit the examples and source files)

void setup() {
  Serial.begin(115200);
  delay(1000);
  //init the configuration
  DW1000Ranging.init(9, 10); //Reset and CS pin
  DW1000Ranging.configureNetwork(1, 10); //device Address and network ID 
  DW1000Ranging.configureMode(DW1000.MODE_LONGDATA_RANGE_ACCURACY);
  //define the sketch as anchor. It will be great to dynamically change the type of module
  DW1000Ranging.attachNewRange(newRange);
  DW1000Ranging.startAsAnchor();
}

void loop() { 
  DW1000Ranging.loop();  
}

void newRange(){
  Serial.print("Range: "); Serial.print(DW1000Ranging.getRange()); Serial.print(" m"); 
  Serial.print("\t RX power: "); Serial.print(DW1000Ranging.getFPPower()); Serial.println(" dBm");
}

For tag, it's exactly the same with "DW1000Ranging.startAsTag();"

For now i just implement the Anchor type && tag type keeping the global architecture of the examples.
I think it's a good idea to add the collector node type (or maybe as an "option". In this case, both tag node or anchor node would be able to become a "collector"). the collector option can just correspond to a node address where we will redirect all the ranges from anchor whereas sending it to tag (as it's currently the case).

Cheers,
Léopold

from arduino-dw1000.

This is all brilliant. Thanks to both of you. I am wondering if you can tell me whether I can actually "step" through this code while it is running on the arduino, or in device code like this that sort of thing is only accomplished through logging statements (I am new to writing device code)? If there is a way to live debug a moving tag and the collector being interrupted on a callback and running its ranging code, how does one do that? And what trilateration algo are you guys using to turn the distances between anchors and tag in to x, y, z coordinates of the tag?
Thanks

from arduino-dw1000.

One design idea (so we can use the ranging later for trilaterion): it would be useful if (on request by a TAG) an ANCHOR can make an one-time ranging to all other ANCHORS. That will allow us to determine the distances between the ANCHORS. This would be required to compute the relative ANCHOR positions for trilaterion. Once the ANCHOR positions are known, later trilaterion can compute TAG position by ranging to ANCHORS and knowing their positions.

from arduino-dw1000.

Hi !
The DW1000Ranging class allow the device to change from TAG to ANCHOR or ANCHOR to TAG dynamically. But we need to implement the communication which will trigger this change.
For instance, let have TAG1, ANCHOR1, ANCHOR2.
If we want to have the distance between ANCHOR 1 and ANCHOR2, we need to send a message from TAG to ANCHOR1 in order to change ANCHOR1 in a TAG11. Then, TAG11 will compute distance with ANCHOR2.
An other things we need to add is the possibility to send the message which contain the distance, directly to an other device. This will allow ANCHOR2 to send back its distance with TAG11 directly to TAG1 for instance... (thanks to mac filtering)
I don't know if you understand what i mean ^^ ?

from arduino-dw1000.

Yes. All discovered distances (device-to-device) could be transmitted within the RANGE REPORT. For simplicity, I would allow the ANCHOR to run only a certain duration as TAG (e.g. 10 seconds), then switch back to ANCHOR mode. I assume we don't want the ANCHORS becoming TAG forever, starting communication without being asked, especially in situations where the TAG lost it's power...

from arduino-dw1000.

PS: this is my STM32F1-based infrastructure ;) (TAG should name ANCHOR)

from arduino-dw1000.

@Rotzbua
I need a help why u close!?

from arduino-dw1000.

@Maxai2 Stop spamming. This is an issue tracker not an help forum. There is a wiki and a lot of "how to connect". Also there are informations in some issues which are not moved to the wiki yet. They are tagged by "move to wiki".

from arduino-dw1000.

@Rotzbua
What u talking about? May be there is found man, which help us! "Move to wiki", if wiki was help me, I dont wrote there! U dont know ok, so show me the way how can I fix my problem, and dont U spam!

from arduino-dw1000.