Posted on

Team Status Report 3/29

This week we re-organized our rest of semester plan once again. Due to our advisers insisting we stick to executing our hardware plan.

Due to working from remote, we needed to find solderless headers which we had shipped from the UK. We are still awaiting our shipment of RPi4s.

Shiva was able to debug and fix the overflow issue he was having. He will take over figuring out the MCU–RPi interface portions from Rhea and run some tests to ensure consistency in measurements between anchor and tag.

Udit finished writing an ideal hardware timestamp simulator in Python.

Rhea and Udit spent the week reading 5+ papers on TDoA. The approaches that were considered were Iterative Hyperbolic Least Squares, Maximum Likelihood Estimator, Pseudo-Ranging, Weighted Delta-Range, Gauss-Newton Position Estimation, and Kalman Filter Smoothening.

We will be finalizing our research based on these approaches and picking a final approach to take by Monday.  We will implement these algorithms and test them using the hardware simulator (we will add in artificial hardware sampling and radio error) to get a clear idea of what accuracy we can achieve with different hardware errors. These will be used alongside the real measurements Shiva collects for Radio Delay to tell us how accurate our time-sync error must be.

Here is the updated Gantt Chart:

Gantt Chart V4 – Sheet1

Posted on

Udit’s Status Report for 3/28/20

This week I built our MVP for the hardware simulator. It visualizes one tag you can move with your arrow keys. It is paramaterized with ability to choose where anchors are placed and how often to send pulse the tags.

You can see a vague demo here:
https://1drv.ms/v/s!Aq6sdyvl6aqAn_EzuCtRUauMuckqig?e=53zhJC

As Rhea and I move into the main algorithm next week. Here is a TDoA overview of the general approach.

Rhea and I also read 3 papers for probabilistic approaches to TDoA that we are going to debate and refer as our primary approach tomorrow. Those papers methods are HLS and MLE, pseudo-ranging and weighted delta-range, and the most complex: kalman filter .

We are going to discuss and share our findings tomorrow. We will pick/combine approaches for our final implementation.

 

Posted on

Rhea’s Status Update 3/28/20

For the first half of this week I read papers on multilateration so we could pick a paper to reference when we start writing the algorithm for our system.  I narrowed it down to two possibilities, and we will choose which one to use as a group.

Towards the end of the week I received the solderless headers, so today I tried putting one of the headers on the chip.

The headers we got were a bit too big, so they needed snapped down to the correct size.

Once the header was snapped down to the correct size (it was one smaller than it should have been, but we’re not using the pins on the end) there was the issue of the chip not sitting flat on the acrylic, since it wasn’t long enough to have both bolts go through the holes.

So I decided to put the board on first, and then put the nut on, so the board would be a little more stable while I was hammering.  It still wasn’t entirely stable since there wasn’t anything on the left side, so trying to hammer in the left side was a bit difficult.

 

After trying to hammer it for about an hour in various different ways on various surfaces for increased stability, the top piece of acrylic slipped.  This somehow caused one of the rows of pins to be pushed further through the black thing, but not at all into the board.  Once this happened I decided to reconsider how to do this and try again tomorrow.

Next week I will get a header onto a board, and get the SPI communication working.  I will also work with Udit to plan how the multilateration software will be structured and start working on a portion of it.

Posted on

Shiva’s Status Update for 03/28

At the beginning of the week, I worked on implementing an ideal multilateration algorithm in Python, based on https://en.wikipedia.org/wiki/Multilateration#Cartesian_solution_with_limited_computational_resources.

Planning diagram I created for multilateration code

After Wednesday, based on Tamal’s concerns with our hardware implementation, I switched gears. I passed the multilateration software over to Udit for him to finish implementing and returned to the Decawave hardware to identify key metrics and details of how it tracks time.

From Wednesday through Saturday, I verified the conversion rate of Decawave time units to real-time seconds (1 DTU ~= 15.65 ps); identified the issue of timer rollover (the Decawave chip timer rolls over every 17.2 seconds), fixed the TDOA software so that the anchor now correctly reads the timestamp of pulse reception; implemented time conversion so that the software can display and log the timestamp in seconds, microseconds, and nanoseconds; and wrote a Python script to graph a single anchor’s measurements of when it receives pulses from a single tag.

Portion of output from timestamp logs for a tag and anchor at a fixed distance of 30 cm. Timestamps are displayed in hexadecimal DTUs, decimal seconds, and decimal nanoseconds.
Graph of pulse reception vs timestamp of reception for the full timestamp logs. Note the timestamp rollover, at pulse 60, from ~17 seconds back to 0 seconds.

Progress is still on schedule, though we’ve had to change some responsibilities around due to the COVID-19 crisis. In particular, Rhea and Udit are now working on the multilateration software. For next week, I will verify the accuracy of the Decawave chip timestamps, then collect sample timestamp measurements using the Decawave chips at various distances to plug into Udit’s simulator.

This was a bit of a hectic week and our Gantt chart will need some re-adjustments. In particular, I’m working with anchors now instead of Rhea.
Posted on

Udit’s Status Report for 3/21/20

Pre-spring break I had been doing a lot of work into helping program the TDoA anchor code with shiva but that work became put on the backburner with the changes to our project due to COVID

I spent this week, thinking about the software for my simulation. I will work on converting it into a block diagram soon. But here is the jist of it.

  • Build a grid-based approximation of a basketball court. Hardcode placement of anchor objects on the edges of the court. Have tags in the grid on the court moving around semi-randomly as well as user controlled.
  • Use the distances between tags and anchors to calculate a time to travel between them. Use that plus a single centralized time-stamp (i.e. assuming perfect time sync) to generate a perfectly accurate time stamp for each anchor per tag pulse.
  • Use sockets to forward these timestamps to the localization software.
  • Log actual locations for comparison with the calculated locations by multilat software.

There a bunch of reach features that would be useful to have after the MVP described above. This includes a GUI for the bball court virtualization and adding in simulated hardware error. There would be a separate errors for radio transmission delay, anchor time-sync error, and LoS blockage delays.

Posted on

Team Status Update for 03/21

We spent most of our time this week trying to get reoriented after the major changes to our lives due to COVID19. Our project also went through some major changes.

  • We spent a lot of time trying to figure out how we could get the remaining hardware we needed. We needed our cables we ordered to ECE, and new solderless headers. Our only option for the latter seems to be importing from the UK
  • We redesigned the project to remove reliance on hardware by having Udit build a hardware timestamp simulator. Shiva will work on localization and Rhea will work on localization with error-correction.
  • Our refocused SOW is attached.

Refocus SOW

Posted on

Rhea’s Status Update 3/21/20

The progress on SPI has been held up by waiting for hardware.  We finally found and purchased solderless headers.  Once those arrive I should be able to finish setting up the connection between the chip and the Raspberry Pi.

This week I read papers on the multilateration algorithm.

Next week I will be working on the multilateration algorithm.  And depending on when the solderless headers arrive I might be able to finish getting the communication between the chip and the Raspberry Pi working.

Posted on

Shiva’s Status Update for 03/21

This week, I successfully completed the deliverables E2E Blink Delta Proof of Concept and Scaled E2E Blink Delta Proof of Concept.

Technically, I’m still one week behind per the details of the current Gantt chart because Rhea was supposed to work on Scaled E2E Blink Delta Proof of Concept, but COVID-19 has forced us to rescope and we will be modifying the Gantt chart to reflect this.

Personally, I still plan to complete the E2E TDOA deliverable. I want to implement a functional multilateration algorithm  in Python by the second week of April.

Gantt chart:

Posted on

Rhea’s Status Update 3/15/20

I was working on the SPI connection between Decawave chip and the Raspberry Pi.  I wrote the code to send messages over SPI for the chip and flashed the code onto a chip.  Also started on the wiring for the SPI connection, but didn’t have the necessary parts.  I also started on the Raspberry Pi side of the SPI communication.

My plan was to get the SPI connection working and Raspberry Pi to timestamp the data during spring break.  I was going to do it during the second half of the week when, I got back to Pittsburgh, but since classes got moved online and it was undecided how the project would move forward, I decided to wait.  So if we continue on with our current schedule I will be a little behind.  But the focus for the beginning of this week is testing the E2E Blink Delta Proof of Concept, so I can hopefully get the SPI working and we can test this part by midweek.

I’m not sure what my actual deliverables for next week will be since our project is very likely to change due to the remote instruction.  Assuming our project stays the same, next week I will get the Raspberry Pi and chip communicating using SPI, the Raspberry Pi will timestamp the data.

Posted on

Shiva’s Status Update for 03/15

In the week before spring break, I started working on the TDOA code for the E2E Blink Delta Proof of Concept milestone in our Gantt chart. I spent the first half of the previous week reading, documenting, and understanding the existing Decawave API, and then the second half of that week writing my own TDOA solution. Unfortunately, my TDOA code was buggy for one reason — I completely did not think about the fact that TDOA does not use timestamps in the same way that Two-Way Ranging does, and tried to write my code using TWR’s mechanism as a baseline.

As a result, I am currently a week behind schedule. I will be using my slack time this week to remedy that and rewrite the TDOA code accordingly. Whereas previously I was trying to send the tag’s timestamp and only test on a single anchor, now I am going to rewrite the tag code to only send its ID and rewrite the anchor code to only log the time when it receives the ID pulse. I will then run this code with two anchors to check that they can both correctly receive the tag’s ID.

Luckily, the need to work with multiple anchors also dovetails into my next deliverable: Scale E2E Blink Delta Proof of Concept. This deliverable requires multiple anchors to identify the tag, which is inherently required for a functional TDOA system. As a result, I aim to accomplish both E2E Blink Delta Proof of Concept  and Scale E2E Blink Delta Proof of Concept over the next week.

Gantt Chart: