Steps to configure rTDoA on Drones?

[amitx64]

If someone has used that project to estimate the position of the drone using rTDoA, please guide me because I found the tag_tdoa_run(uwb_data, &pos_tick[0]) method in the "mainTask" of the project, which seems to be for TDoA topology. However, I couldn't find any code for the anchors. Can I use the basic "ss_twr_init" for the anchor side? I'm confused about this. Please guide me on how to configure this project so that I can use rTDoA topology to estimate the drone's position.

[MatteoAlbi]

Hi @amitx64. Unfortunately, the tag_tdoa_run() function in TDOA.C was already provided, and what it does is to collect the 4 ticks from the six anchors.

At the end of the collection process, first I save the timestamp for fruther computation, e.g. compute velocity using discrete derivative (an alternative would be using instead some sort of average over the anchors' timestamp for a more precise correlation between computed position and corresponding time instant). Then, the function rTDoA is called, which computes the position of the tag and saves it in rtdoa_buf.

This code is only for the tags, I don't have the code available for the anchors. For more info about the algorithm, see reference 3 in the report. I would suggest to look after publications of the listed authors, who also guided me during the project development.

[amitx64]

So, how can you transmit blink messages to the tag if you don't have any Anchor code? Actually, I want to test this on a drone. That's why I am asking. It's truly impressive work that you have done, and I appreciate it. I have read your paper and am still reading it.

[amitx64]

It would be a great help if you could provide information about the transmission of the "broadcast_blink_message1" (Message Packet size: 6) and "broadcast_blink_message2" (Message Packet size: 15) by the anchor.

[MatteoAlbi]

During the project I was provided with anchors already flashed with the code to run the blink messages routine. Let's say that I was provided with this nice setup where I already had available the 24 timestamps. It was kind of a black box to me, I didn't really dived in the details. Thus, I don't have the code available.

That's why I was suggesting to read reference 3, where the rtdoa algorithm is presented. The method explain there should also cover the anchor blinking routine to some extent; it should serve as a good starting point. You may try to contact the authors if you need further explanation.

[amitx64]

Thank you for the information. I will read the referenced paper (reference 3) and work on writing the Anchor side code. Currently, my main focus is understanding the contents of the Anchor Packets, specifically what information is included in them.

[amitx64]

If you have any knowledge about the packet details, please let me know. It would be a great help!

[MatteoAlbi]

I do remember something about that. It could be the transmission timestamp as perceived by the anchor, or something similar.

[amitx64]

@MatteoAlbi, I have written a basic ANCHOR code to transmit three messages to the tag. When I tried to test the tag with a single anchor, I was able to receive all three transmitted messages. However, when I tried with two anchors, the sequence of receiving the three messages from the anchors in the tag was broken. According to the tag's receiving sequence, it first waits to receive six bytes of a message and then waits for two 15-byte messages from the same anchor before incrementing the ANCHOR_INDEX to receive the three messages in the same sequence from the other anchor. I believe anchor synchronization is required. What are your thoughts on this? I have no idea how to achieve it.

[amitx64]

@MatteoAlbi, I am able to retrieve all anchor timestamps, but now I'm encountering a new error: "Singular matrix, can't find its inverse." Do you know why this is happening?

In fact, during testing, I didn't modify any coordinates. That means I didn't position the anchors based on their coordinates. Could this be the reason for obtaining a determinant of the matrix equal to zero? ( I am using 4 ANCHORS instead of 6)

[MatteoAlbi]

@MatteoAlbi, I have written a basic ANCHOR code to transmit three messages to the tag. When I tried to test the tag with a single anchor, I was able to receive all three transmitted messages. However, when I tried with two anchors, the sequence of receiving the three messages from the anchors in the tag was broken. According to the tag's receiving sequence, it first waits to receive six bytes of a message and then waits for two 15-byte messages from the same anchor before incrementing the ANCHOR_INDEX to receive the three messages in the same sequence from the other anchor. I believe anchor synchronization is required. What are your thoughts on this? I have no idea how to achieve it.

Yes, anchor synchronization is necessary. I remember it was achieved exploiting the internet network. The anchors tag were mounted on Raspberry PIs, and probably were triggering synchronization routines periodically over the wifi network. The anchor infrastructure has a master tag, which starts the message broadcasting, thus probably the synchronization routine as well.

[MatteoAlbi]

@MatteoAlbi, I am able to retrieve all anchor timestamps, but now I'm encountering a new error: "Singular matrix, can't find its inverse." Do you know why this is happening?

In fact, during testing, I didn't modify any coordinates. That means I didn't position the anchors based on their coordinates. Could this be the reason for obtaining a determinant of the matrix equal to zero?

The matrix singularity is for sure related to the received timestamps and anchors position. In particular, cases which pop up in my minds are:

• anchor positions and recevied timestamps are not consistent
• the anchors are positioned in such a way the system is ill-conditioned, e.g. aligned with the tag

Also, take into consideration that small errors in the timestamps, even due to bad synchronization of the anchors, explode due to the multiplication with SPEED_OF_LIGHT (and maybe also when deviding by TIME_CONST, but that should serve only as conversion to [ns]), which are fairly big numbers.

Anyway, I would suggest you to add a print of the matrix before it gets inverted (just uncomment the print function in the source code) and have a look how it is formed. Maybe you have full zeros rows/columns because of some errors with the timestamps retrieving procedure.

[amitx64]

@MatteoAlbi, I am able to retrieve all anchor timestamps, but now I'm encountering a new error: "Singular matrix, can't find its inverse." Do you know why this is happening? In fact, during testing, I didn't modify any coordinates. That means I didn't position the anchors based on their coordinates. Could this be the reason for obtaining a determinant of the matrix equal to zero?

The matrix singularity is for sure related to the received timestamps and anchors position. In particular, cases which pop up in my minds are:

• anchor positions and recevied timestamps are not consistent
• the anchors are positioned in such a way the system is ill-conditioned, e.g. aligned with the tag

Also, take into consideration that small errors in the timestamps, even due to bad synchronization of the anchors, explode due to the multiplication with SPEED_OF_LIGHT and the division of TIME_CONST, which are fairly big numbers. Anyway, I would suggest you to add a print of the matrix before it gets inverted (just uncomment the print function in the source code) and have a look how it is formed. Maybe you have full zeros rows/columns because of some errors with the timestamps retrieving procedure.

Ok, I would try this and come back to you 👍

[amitx64]

@MatteoAlbi, does your Tag code support computation for both 6 Anchors and 4 Anchors? I ask because in my particular case, I am using 4 Anchors with 1 Tag.

[amitx64]

@MatteoAlbi, where do you get TIME_CONST value.

[MatteoAlbi]

@MatteoAlbi, does your Tag code support computation for both 6 Anchors and 4 Anchors? I ask because in my particular case, I am using 4 Anchors with 1 Tag.

First point: I'm not sure if the rtdoa can run with less than 6 anchors, the optimization problem might result undefined

Second point: Assuming it can work with only 4 anchors, probably my code will break anyway. It assumes 6 anchors are available, thus the starting matrix will have 2 empty rows. I don't remember which shape the further computed matrices have, but probably you will end up trying to invert matrices with full null columns/rows (inside the pseudoinverse), which will rise an error.

[MatteoAlbi]

@MatteoAlbi, where do you get TIME_CONST value.

I'm sorry for the late replay, I forgot to answer this. It's a constant used to convert from timestamp's ticks to nanoseconds (if I recall correctly), thus it is platform dependent.

[amitx64]

@MatteoAlbi, where do you get TIME_CONST value.

I'm sorry for the late replay, I forgot to answer this. It's a constant used to convert from timestamp's ticks to nanoseconds (if I recall correctly), thus it is platform dependent.

Thank you for the reply, @MatteoAlbi. What do you mean by "platform dependent," and is it suitable for the DW1001C Dev-Kit that you provided in the TAG code?

[amitx64]

@MatteoAlbi Actually, I am trying to understand the matrix calculations that have been performed in the code. It is quite challenging to comprehend them solely based on the research paper. If I can grasp your matrix computation, I will attempt to modify it according to the 4-ANCHORS methodology.

[MatteoAlbi]

@MatteoAlbi, where do you get TIME_CONST value.

I'm sorry for the late replay, I forgot to answer this. It's a constant used to convert from timestamp's ticks to nanoseconds (if I recall correctly), thus it is platform dependent.

Thank you for the reply, @MatteoAlbi. What do you mean by "platform dependent," and is it suitable for the DW1001C Dev-Kit that you provided in the TAG code?

It is related to the clock frequency of the chip. I also used the DWM1001C, thus it shouldn't be necessary to change it, but maybe double check

[amitx64]

@MatteoAlbi, Anchor synchronization is taking too much time. I am trying to synchronize Anchors using TDMA.

[amitx64]

@MatteoAlbi, After reading your TAG code, I realized that TAG is waiting for consecutive timestamped messages. Am I correct?

[MatteoAlbi]

@MatteoAlbi, After reading your TAG code, I realized that TAG is waiting for consecutive timestamped messages. Am I correct?

Yes, you are. It is necessary for the rtdoa algorithm to work. That's because (if I'm not mistaken) it computes delays between timestamps to compensate for the tag desynchronization (this way you don't need to synchronize the tag as well)

[MatteoAlbi]

@MatteoAlbi, After reading your TAG code, I realized that TAG is waiting for consecutive timestamped messages. Am I correct?

About this, I can't help you. I have no idea about the anchors code