-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Steps to configure rTDoA on Drones? #1
Comments
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). This code is only for the tags, I don't have the code available for the anchors. |
So, how can you transmit blink messages to the tag if you don't have any Anchor code? |
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. |
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. 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. |
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. |
If you have any knowledge about the packet details, please let me know. It would be a great help! |
I do remember something about that. It could be the transmission timestamp as perceived by the anchor, or something similar. |
@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. |
@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? |
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. |
The matrix singularity is for sure related to the received timestamps and anchors position. In particular, cases which pop up in my minds are:
Also, take into consideration that small errors in the timestamps, even due to bad synchronization of the anchors, explode due to the multiplication with 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 👍 |
@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. |
@MatteoAlbi, where do you get |
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. |
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? |
@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. |
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 |
@MatteoAlbi, Anchor synchronization is taking too much time. I am trying to synchronize Anchors using TDMA. |
@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) |
About this, I can't help you. I have no idea about the anchors code |
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.
The text was updated successfully, but these errors were encountered: