Author: rkudtar1

This week I worked on tuning the Kalman filter and the final presentation.

The filter performed better than the liner and non-linear localization.  The RMSE for one of the runs was 15.223 m for linear, 1.065 m for non-linear, and 0.631 m for the filter.

Next week I will be working on updating the Kalman filter to work with the data sets that Udit will include in the simulation.  I will probably attempt to have the predict step use the velocity of the tag, instead of using the current position.

This week I got the extended Kalman filter working.  We decided to use the filterpy library for the filter to save time in writing the filter, and focus on getting it to work.  When I was starting, I ran into some issues with making sure I had the right dimensions for all the matrices.  At first I was trying to do linear Kalman filter, but did it incorrectly, and realized that I used a measurement model wasn’t a constant.  Since the measurement was nonlinear, I decided to work on the extended Kalman filter instead.  The first time I tried to test the Kalman filter the positions it was estimating were very wrong, and realized that the equations I was using for the measurement model were incorrect.  Once I fixed the equations, I ran into a few other issues where I was using the wrong variable names for certain things.  After I fixed those last few bugs, we had a working extended Kalman filter.

Our current simulation doesn’t have any noise, so with perfect data the extended Kalman filter and nonlinear localization perform about the same.

Next week, Udit and I plan to discus the data the Shiva gathered, and I will work to incorporate that into the filter.  Udit will be also adding noise to our simulation soon, and once he does that I’ll work on tuning the filter.

This week I worked on better understanding Kalman filters and implementing the filter in Python.  I decided that since we have both a linear and and non-linear localization algorithm I was going to start by implementing linear Kalman filter, and get that working first and then move on to the extended Kalman filter.  I have an implementation of Kalman filter that needs that models and covariances inputted as parameters.

While discussing Kalman filters, we decided that it may be best to use a python library instead of writing it from scratch, especially for the extended Kalman filter.  Using a python library still requires us to determine what models to use and what the covariances are, so it lets us jump right to fine tuning these values and getting the best results as possible.

In the coming week I will be working on determining the best values for the state transition model, observation model, covariance of process noise, and covariance of observation noise.  I hope to have the Kalman filter and then the extended Kalman filter working with our simulation by the end of the week.

At the end of last week Udit suggested another paper for us to use as reference for our multilateration software.  So I started working on understanding the paper, but while going through the math I noticed that the hardware set up was different than what we have.  Instead of having a transmitting tag, and multiple receiving beacons, it had multiple transmitting beacons and receiving tag which does all the math.  We decided that moving forward with this paper would not be productive, but it helped us decide to use a Kalman filter.   We then took a look at a different paper which had a similar hardware set up to our system and used a Kalman filter.

After looking at the other paper we decided that our approach should be to use Gauss-Newton to estimate the position and then use a Kalman filter to improve the accuracy.  So I then did research on Kalman filters, to understand generally how it works, and how we might apply it to our system.

Next week I will work on implementing the Kalman filter to improve accuracy of the location we predict.

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.

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.

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.

Since Shiva made a lot of progress on the tag communication I didn’t have to work on the anchor.  Instead I started on getting data from the anchors to the Raspberry Pis.  I’ve been going through some more of the documentation for the DWM 1001s and how to do SPI communications.

Early next week I plan on getting the backhaul to work completely.  And then I plan on getting the Raspberry Pi to timestamp the data that it receives.

I’ve been incredibly sick this whole week so all my energy has gone towards recovery, and I have been unable to work on the project much.  Due to this, I am behind on my progress.

During lab on Monday, I verified that we can flash an already compiled hex file onto the chips.  I also started working on the code to transfer data from the chips to the Raspberry Pis.

We’ve decided to redistribute my portion since it’s behind and are focusing on getting tag-anchor communication working.  So next week I will be focusing on configuring the chip as an anchor, have it receive a UWB message from a tag, and send a time stamped UWB message back to the tag.