Skip to content
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

Clarification about the hardware precision #1

Open
offchan42 opened this issue Feb 21, 2019 · 1 comment
Open

Clarification about the hardware precision #1

offchan42 opened this issue Feb 21, 2019 · 1 comment

Comments

@offchan42
Copy link

offchan42 commented Feb 21, 2019

Hi @fughilli , your project is very interesting and we want to reproduce your work!

First, I want to know how precise the hardware needs to be giving.
Please correct any point that I said wrongly.

  1. The hardware should provide the time difference in microseconds for both sweeps in the 60+ FPS.
  2. So it will give numbers between 0 to 8333, for each diode sensor.
  3. If the sensor is put in a fixed place, the time difference should not be more wrong than 10 microseconds.
  4. If the sensor is put in a fixed place, the angle cannot be wrong more than a degree, or even a half of degree because the ray requires the angle to be very precise on both vertical sweep and horizontal sweep.
  5. We can compute the ray on non-filtered angles and the error would not be large enough to cause bigger than a centimeter error on the position prediction.

And also, here are some questions:

  1. What is the (rough) error of your time difference when a sensor is on a fixed place?
  2. What is the (rough) error of your angle when a sensor is on a fixed place?
  3. When you say you got around 1mm error, is this before or after filtering?
  4. If it's after filtering, what is your error without filtering? (I want to know it so that I can know whether or not my implementation is close to correct)
  5. What is the minimum and maximum time and angle? (I've checked the case when the time is 8333, the angle will be 90 degrees, if time is 0, the angle will be 0 degrees. But I'm not sure how do I get to -90 degrees then?)

If you have any suggestions or concerns, please let me know!

@fughilli
Copy link
Owner

So there's a few points to be made here:

  1. The FPGA implementation counts the time difference between the phase locked loop pulse and the center of the sweep pulse. This is measured in clock ticks for the counter blocks. The clock as implemented is 50MHz (I'm not using the hardware PLL to upscale). Therefore, the counts should be in units of 1/50MHz = 20ns. The sweep pulses come at 60Hz per channel, and there are two channels (vertical/horizontal), so each sweep window ranges from 0s to (1/120)s, or 0 to ~416666 clock ticks. The values read out over SPI should fall in that range.

  2. see 1)

  3. That seems arbitrary? The tolerance of the timing has to do with a lot of factors, including the angle of incidence (the photodiodes have an angular-dependent response) and the phase error of the control loop in the lighthouse itself. The intuition here is that the total information you have from all of the sensors helps you to squash some of the error (there's more measurements than you have degrees of freedom, nominally). Plus, you have a kinematic model at play, which allows you to combine measurements over time to improve the estimate of the system state. If you are interested in compensating directly for the phase error in the lighthouse, have a look at related work decoding the OOTX (out-of-band transmitter) bits that are modulated onto the sync pulse. The data there includes phase error information measured at the lighthouse.

  4. Again, this depends. There are a lot of factors at play; I was able to achieve sub-millimeter precision with only optical input (granted, only within a couple of meters of the lighthouse), but including an IMU would allow you to do better.

Questions:

1,2) These should be proportional? I don't remember what the deviation was off the top of my head, so I'll have to rebuild the system and get back to you on that.

3,4) There's no real filtering happening, other than dropping frames when they don't match the expectations. The solver does act as a filter of sorts, since its initial estimate is the last system state and it runs for a bounded number of iterations before producing a result. The standard deviation I give in the paper is measured directly from the output of the solver, no other filtering performed.

  1. The minimum and maximum time are given above; the minimum and maximum angle are -60 degrees and +60 degrees, measured from the surface normal of the face of the lighthouse (the FoV is 120 degrees for the laser guns). If you are measuring a time delta of 0, then you are at -60 degrees. Likewise, if you measure a time delta of 1/120s, then you are at +60 degrees.

Hope that helps! Glad to hear that someone is making use of the work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants