Updating yabai causes duplicate permission entries for Accessibility

Hey there.
Every time I upgrade yabai using brew upgrade yabai, it re-requests Accessibility permissions, which is fine in itself, but it also creates a new, separate entry for itself which could become quite a bit much over time, since the previous ones aren't removed. Yes, I can manually remove them, but I still wouldn't consider this to be ideal.

I also keep getting thisa nd I never was able to get yabai logo to show up :/

Sorry for the necro, I still have this issue and it's getting out of hand now

Anyway I can clear the old entries?

This is a duplicate of #1924

Anyway I can clear the old entries?

Highlight the old yabai entries and press -

See this comment https://github.com/koekeishiya/yabai/issues/2086#issuecomment-1939670967

I guess this is happening because macOS stores the absolutepath when saving permissions, because yabai is a single binary application and not an app bundle. When homebrew upgrades yabai it places it in a folder specific to the version, so every brew upgrade causes the binary to be stored at a different path, effectively resetting the permissions.

You can remove permissions directly inside the macOS settings/permissions window. Just remove stale entry when upgrading. I'm not aware of any workaround as long as you install using homebrew, due to the above situation.

I never experience this personally because I of course build from source manually, and the target binary never changes its location -- therefore simply codesigning the new binary with the same certificate as the previous binary is enough for macOS to retain permissions.


Stops at the beggining

Script stops on the beginning
2021-12-15 22:50:04,162 [   INFO] 212 --- util.py:248  : attempt to start Battle.net
2021-12-15 22:50:14,233 [   INFO] 212 --- util.py:218  : find Battle.net.exe exists
2021-12-15 22:50:14,233 [   INFO] 212 --- util.py:254  : Battle.net start success
2021-12-15 22:50:14,240 [   INFO] 212 --- util.py:257  : attempt to start Hearthstone
2021-12-15 22:50:24,277 [   INFO] 212 --- util.py:218  : find Hearthstone.exe exists
2021-12-15 22:50:24,277 [   INFO] 212 --- util.py:262  : Hearthstone start success
2021-12-15 22:50:29,299 [   INFO] 212 --- util.py:265  : done
2021-12-15 22:50:29,304 [   INFO] 212 --- util.py:218  : find Hearthstone.exe exists
2021-12-15 22:54:24,833 [   INFO] 504 --- util.py:218  : find Hearthstone.exe exists
2021-12-15 22:55:07,155 [   INFO] 6904 --- util.py:218  : find Hearthstone.exe exists
2021-12-15 22:55:13,461 [   INFO] 2856 --- util.py:218  : find Hearthstone.exe exists
2021-12-15 22:55:40,990 [   INFO] 5088 --- util.py:218  : find Hearthstone.exe exists
2021-12-15 22:56:10,208 [   INFO] 1308 --- util.py:218  : find Hearthstone.exe exists
2021-12-15 22:56:55,564 [   INFO] 4468 --- util.py:248  : attempt to start Battle.net
2021-12-15 22:57:05,802 [   INFO] 4468 --- util.py:218  : find Battle.net.exe exists
2021-12-15 22:57:05,803 [   INFO] 4468 --- util.py:254  : Battle.net start success
2021-12-15 22:57:05,825 [   INFO] 4468 --- util.py:257  : attempt to start Hearthstone
2021-12-15 22:57:15,911 [   INFO] 4468 --- util.py:218  : find Hearthstone.exe exists
2021-12-15 22:57:15,911 [   INFO] 4468 --- util.py:262  : Hearthstone start success
2021-12-15 22:57:20,921 [   INFO] 4468 --- util.py:265  : done
2021-12-15 22:57:20,925 [   INFO] 4468 --- util.py:218  : find Hearthstone.exe exists

Any solutions?


Error pulling image, Error mounting '/dev/mapper/...' on '/var/lib/docker/devicemapper/mnt/...': invalid argument

After docker install:
$ docker pull debian:jessie
2014/10/27 11:23:30 Error pulling image (jessie) from debian, Error mounting '/dev/mapper/docker-8:3-983283-511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158' on '/var/lib/docker/devicemapper/mnt/511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158': invalid argument

System:
$ uname -a
Linux enterprise 3.17.1-1-ARCH #1 SMP PREEMPT Wed Oct 15 15:04:35 CEST 2014 x86_64 GNU/Linux
$ docker version
Client version: 1.3.0
Client API version: 1.15
Go version (client): go1.3.3
Git commit (client): c78088f
OS/Arch (client): linux/amd64
Server version: 1.3.0
Server API version: 1.15
Go version (server): go1.3.3
Git commit (server): c78088f
$ docker -D info
Containers: 0
Images: 0
Storage Driver: devicemapper
 Pool Name: docker-8:3-983283-pool
 Pool Blocksize: 65.54 kB
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 305.7 MB
 Data Space Total: 107.4 GB
 Metadata Space Used: 733.2 kB
 Metadata Space Total: 2.147 GB
 Library Version: 1.02.90 (2014-09-01)
Execution Driver: native-0.2
Kernel Version: 3.17.1-1-ARCH
Operating System: Arch Linux
Debug mode (server): false
Debug mode (client): true
Fds: 10
Goroutines: 11
EventsListeners: 0
Init SHA1: e244de98e642144b162d1936978b8ac5d024d546
Init Path: /usr/lib/docker/dockerinit
WARNING: No swap limit support

I'm unable to use @VicDeo 's workaround on linux 3.8.4-1 and docker 1:1.4.1-1.
$ umount /var/lib/docker/devicemapper
umount: /var/lib/docker/devicemapper: target is busy
        (In some cases useful info about processes that
         use the device is found by lsof(8) or fuser(1).)
$ fuser /var/lib/docker/devicemapper -v
                     USER        PID ACCESS COMMAND
/var/lib/docker/devicemapper:
                     root     kernel mount /var/lib/docker/devicemapper

hmm sorry ping @vbatts

closing as dupicate of a few issues here https://github.com/docker/docker/issues?q=is%3Aopen+is%3Aissue+label%3A%2Fsystem%2Fdevicemapper

@mindscratch solution has worked for me too


BindRequired vs. Required

While migrating from Swashbuckle, we noticed that [Required] no longer works. According to https://github.com/RicoSuter/NSwag/wiki/AspNetCoreOpenApiDocumentGenerator, [BindRequired] should be used instead. However, starting from ASP.NET Core 3, referencing BindRequiredAttribute requires using Microsoft.NET.Sdk.Web, which can be undesirable in some cases (e.g. when the type is located in a library that is reused in a non-ASP.NET project). Contrary to that, RequiredAttribute lives in System.ComponentModel.DataAnnotations, which is much more lightweight and not ASP.NET-specific.
Is there a reason not to use [Required] for marking required members?

Also, according to https://docs.microsoft.com/en-us/aspnet/core/mvc/models/model-binding?view=aspnetcore-3.1, [BindRequired]

Can only be applied to model properties, not to method parameters

which is misleading, but they don't seem to care

[Required] (or the Required field in the JsonPropertyAttribute) is still used for regular JSON serialized objects (eg POST body or responses). However, aspnet core primitive params or complex [FromQuery] properrties which are required must be marked with [BindRequired] as they are not JSON serialized but handled/modelbound by asp


Add /safes/{address}/balances/rates endpoint

Closes #332

Add balances/rates – this endpoint relies on cached token events associated with a Safe with address {address}
This endpoint avoids querying the node (no balance retrievals)
The ETH/USD rate is always returned (first entry)
Extract new function _get_token_addresses. It reads the token events associated with a specific Safe address and returns a collection with the respective token info. This functions is used by the /balances endpoint (where it was extracted from) and /balances/rates

Payload format
GET /api/v1/safes/{address}/balances/rates

{
  "address": <string>, // optional – null if native currency
  "fiatConversionRate": <decimal-string>,
  "fiatCurrencyCode": <string>,
  "timestamp": <string>
}

Draft until decision is made here: https://github.com/gnosis/safe-client-gateway/issues/588


setClockOffset (when player loading) it looks no effects.

Have you read the FAQ and checked for duplicate open issues?:
yes
What version of Shaka Player are you using?:
latest
Can you reproduce the issue with our latest release version?:
yes
Can you reproduce the issue with the latest code from master?:
yes
Are you using the demo app or your own custom app?:
custom app
If custom app, can you reproduce the issue using our demo app?:
can not try in demo app.
What browser and OS are you using?:
windows10
What are the manifest and license server URIs?:

What did you do?
when playing multiple tile (divide from one large video),  sequential play button delay. I've add first loading stream, add setClockOffset = some value (ms) .
What did you expect to happen?
make sync with each tile.
What actually happened?
offset value to over 1000, it doesn't effects on MPD presentation.
When , What time , Where I call setClockOffset ? it makes effects.
Thanks.

Are you using multiple instances of shaka.Player to play this video?

The only method called setClockOffset is on PresentationTimeline, which shouldn't really be used by the app.  You shouldn't call this method at all, it is called automatically during manifest loading.  This is used to ensure the server and the app have the same clock times.
Are you talking about playing one MPD file that has multiple parts, or loading multiple MPD files?

@chris yes. 16 instances in same time

@chris yes. 16 instances in same time
@themodmaker yes multiple instances same time.
It is can be called in mpd is problem I think.
Is there runtime setting the pts timing ?

We don't really provide a cross-video synchronization mechanism.  You'll probably need to do something in your app.  Assuming the different streams are generated on the same server and have the same availabilityStartTime (i.e. they started at the same time), you could probably just set the video.currentTime for each video to the same time and they should be synchronized.
Alternatively you'll need to provide some offset from each stream to your app.  For example, if you set video1.currentTime to 45, you may need to set video2.currentTime to 50.  You would need to send this info to your app and handle it yourself.  We don't provide a way to synchronize two videos.  Remember that each video is an independent video stream from our perspective.

@TheModMaker  @chrisfillmore @shaka-bot
Move to New issues. on #1756


Is there no way to download code from the cloud to a local server?

Is there no way to download code from the cloud to a local server?

Hi, I have released a new version 2.3.1. Now you can download or compare files.


Initial implementation SF10x driver

This is a basic implementation for the Lightware SF10a laser range finder connected via I2C. Should work with all Sf10x series sensors. The implementation is based on the sonar implementation for SRF02

Tested in flight

Thanks for the contribution, looks very clean!
One thing I'm wondering is why the driver runs at 40 Hz when the device seems to support only 32 Hz according to the datasheet, or is this wrong?

You're right, the data sheet specifies a rate of 32 Hz, but at least my two devices run at 40 Hz without any issues.

Hehe overclocking :) Do you mind adding a comment to the define which specifies this rate then?

I'll do that.

Additional note: This driver should also work with the Lightware SF11/c which has a wider range (0..120m)..

Nice! Will get this in now.

I cherry-picked these. I reverted to the device default rate. I recommend you change as well, because you might run into corner cases and crash your plane when you try to outsmart the manufacturer on absolute maximum ratings. It usually holds up until it doesn't, and then things go terribly wrong.


Unit tests fail on some platforms

On a Windows development platform, ApplicationManager.getApplication() returns null when running unit tests, which causes currently 15 tests to fail (in most cases, the error is raised when PluginSettings class cannot be initialized because of this).

This will be fixed when a PR (to be opened soon) related to #185 gets merged. Issue was that some test classes that didn't inherit PlatformTestCase accessed PluginSettings class. Those accesses are gonna be removed which also solves this issue.

This will be fixed when a PR (to be opened soon) related to #258 gets merged
Sorry, that's not gonna happen in #286

on master now 😛


Cli

cli is written. All you have to do is write the shell script file.

And lets talk about the way you created the directories :)

After receiving the values. Detect the operating system via os.name. Then the desired script file is executed. Windows uses xcopy for copying, which is available in Windows 8.1 and later.
The files are in the template folder for the app or project creation. A folder with the entered name is created, then it copies the files from the template to that folder.

change collect_middlewares to default


Disable the blur

Hey, model works great so far. Is there a way to disable the subtle blue on the edges?

有办法了，能达到remove-bg的效果

这是官网效果：

边缘处理效果：

But how do we do it?


Adds BlueBubbles entry to ADOPTERS.md

Alright, should be fixed now. Thanks for the heads-up!

unfortunately two of your commits were not signed for some reason (the first commit was). the project does require signed commits, enforced by github. Would you mind updating the PR so the commits are all signed?

unfortunately two of your commits were not signed for some reason (the first commit was). the project does require signed commits, enforced by github. Would you mind updating the PR so the commits are all signed?

I did it through GitHub's Codespaces... 🤦 idk why it wouldnt be signed... gimme a sec

I'm going to close this and start a new PR. Had to delete and re-create my codespace and it screwed everything up...


First run mess

Just installed the mac binary,
ls | page gives me:
thread 'main' panicked at 'Cannot open page PTY: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/page.rs:353:48
[Process exited 1]                                  note: run with `RUST_BACKTRACE=1`environment variable to display a backtrace
                                           ❌ exit code: 101
                                                            🔸~/Downloads$

with RUST_BACKTRACE=1:
=]11;?Vim: Error reading input, exiting...

(B
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
(B[No Name]1,0-1          All]112[2 q]112[2 qVim: Finished.
]112[2 q(B>thread 'main' panicked at 'Error sending message: Os { code: 32, kind: BrokenPipe, message: "Broken pipe" }', /Users/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/neovim-lib-0.6.1/src/rpc/client.rs:188:9
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
   1: core::fmt::write
   2: std::io::Write::write_fmt
   3: std::panicking::default_hook::{{closure}}
   4: std::panicking::rust_panic_with_hook
   5: rust_begin_unwind
   6: core::panicking::panic_fmt
   7: core::option::expect_none_failed
   8: neovim_lib::rpc::client::Client<R,W>::send_msg
   9: neovim_lib::session::Session::call
  10: <neovim_lib::neovim::Neovim as neovim_lib::neovim_api::NeovimApi>::subscribe
  11: page::main
  12: std::rt::lang_start::{{closure}}
  13: main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

I'm currently working on next release where this issue should be fixed. As for now you could compile next_release branch to test if it's fixed for you (or just wait for a next release — if everything would be okay should happen on the next month).

Finally it's published.
Version 3.0.0 should work fine. Feel free to reopen this issue if there's something wrong


Android Improvements

We need to improve android support and development:

[x] fixed #250
[x] create workaround #251
[ ] check workaround #251
[ ] use Android Studio (IntelliJ), which introduces gradle for the build tool in android module, see the new branch and give feedback
[ ] update mapsforge to recently released 0.5.x

Would also like to see that the library works with app local data
getFilesDir()
Currently, when copying data to that location, the app produces
java.lang.IllegalStateException: Cannot load properties to fetch EncodingManager configuration at
/data/data//files/Pforzheim-gh/
Not all devices have SDcards, and this would be possible to bundle the data with the app into a self-contained APK

Currently we head towards 0.4 and new bigger features are only likely if they come from the community.


Missing from playlist

Episode 60 is out now, but the last episode on the TGI Kubernetes playlist on youtube is Episode 56. The playlist is a nice convenience, can it be kept up to date?

Just updated it!


CodeCommit event support?

Hi Team,
It'd be really nice to trigger a function based on CodeCommit events, which is already supported by Lambda.  It looks like all that's needed is a new event source type in SAM that implements that call.
Thanks

It seems that AWS has just added CloudTrail support for CodeCommit: https://forums.aws.amazon.com/ann.jspa?annID=4344 With that, it should be possible to define the event as a CloudWatch alarm to a CloudTrail event on CodeCommit. I'm going to check if that it works.

So to solve this problem backwards, one can also define a CodeCommit resource with a trigger that references the function's ARN (in the same template), and keep the function without an Event Source (which is not required).
That being said, it may still be good to add support for CodeCommit Event Source, especially for cases where people have an existing repository (created outside of the context of that template), and then want to link this function to that repo using the well-known and persistent repo URL. Function's ARN may change, but that would not affect this link as long as repo's URL stays the same.

Closing in favor of using SNS event source, which provides link persistence but also enables subscribing multiple repos to the same function


Local installation issue: Error verifying target: Invalid Response with status code: 400

Hi
I followed the instructions for setting up lattice locally. vagrant up worked fine but then I could not set the target and I always got the following error Error verifying target: Invalid Response with status code: 400. I can ping the address and curl requests are also working fine, so I suppose it is not something related with DNS configurations.
I installed it with VirtualBox on a Mac Box with Yosemite.
I could not find a way to get more information about the error (no verbose option?). How can I find out what's the issue?

hey, you can run ltc debug-logs in a separate terminal ..  that's our first recommendation usually
that error message looks like an issue connecting between ltc and your cluster though.  can you run this:
curl -v http://receptor.<IP_ADDRESS>.xip.io/v1/desired_lrps   (assuming your target is <IP_ADDRESS>.xip.io)
@davidwadden

@davidwadden Got the same error as @alainsahli. When I run curl got a 404 error in the response.
After that I tried with lattice v0.4.3 and it worked without issues.

Hi I tried version v0.5.0 and now it works.

Thanks @alainsahli  -- closing this issue.


fix prefix and added Dave's suggestions

"prefix" should be what comes before the actual installation folder

   bash ./install_ambertools.sh --prefix /home/hai
   # create amber16 folder and install everything there

not install mkl (to make the install faster). We don't use mkl anyway.
should exit if getting error
fix missing '/bin': "the export PATH statement in the last line is missing "/bin"
conda clean

merge since Linux test passed (not care much about osx for now).


Update ARCHITECTURE.md

I am still not familiar with the code base, so mostly I quote crate's comments.

bors r+

Sorry I took a mistake.


Mac OS - self update function could be renamed

The self update function is finally working on MacOS! Thanks for your work on that. I noticed the update functionality runs a process/program called “elevate”

Which may not be intuitive to a user. Especially if they are doing a lot of different things in their machine they might come back around to this one and think “wait what wants access to my machine?”
I would suggest just calling it Xenon or XenonUpdater so it’s clear to the users what is going on

The name of the elevate program should now reflect the name of the program requesting it be elevated. In this case it should show as "Xenon" and the text would read "Xenon wants to make changes."


Determine locations of lighthouses.

Using data from the HMD, determine location of lighthouses relative to it.

This is some initial data.  Its columns are:
L, HED, [Actual Time (1/48 millionths of a second)], sensor ID, pulse code, delta from frame start.
initial_hmd_data.txt.zip

Here is some code to visualize the points.
viveStuff.zip

Here's the data from my HMD data poins.

New tracking data - from one of the lighthouses, in mode 'A' pointed directly at the Vive.
newtrackdata.csv.zip

Fixed copy of initial hmd points...
initial_hmd_data.txt.zip

Here's the actual locations of all of the HMD points on the headset, in 3D space.
hmd_points.csv.zip

here is the data with some rudimentary animation so it is easier to see where everything is.

Yeah, those normals don't look right :(

Was the scad script edited and re-uploaded, because I just opened it to see if I could figure out why it looked strange and the swirling seems much less pronounced, and in the reverse direction.
This is a top view with orthogonal projection so it will look a little odd just due to the lack of perspective, but it gives a better sense of actual sensor orientation and they all look very nearly front-facing.  My intuition is that they shouldn't be and they should be more aligned with the curve of the surface, but it does make more sense than a swirl pattern.

Yeah, I've been trying to mess with it to show the normals. They don't look right because I just treated the vector as a rotation which is why the swirls appeared. I'm working on fixing that now.
ErrJordan, That might be because they are being rotated by less than one because of what I said above, thus it isn't noticeable.

Here is the corrected version, much better than last time.
And the corrected code here:
   for(i =[0:31]) {       color("red")translate(points[i]*100) { 	 x = normals[i][0]; 	 y = normals[i][1]; 	 z = normals[i][2]; 	 rotate( [0, 	    1*atan2(sqrt(x*x + y*y),z), 	    1*atan2(y,x)]) { 	       cylinder(h= 1, r1=.25, r2=.1); 	    }       }    }
viveHeadsetVectors.zip

What do the last two numbers on each line represent?
I made a spreadsheet of the data and found the average value for x and y for each sensor in the data-set. I find it interesting that sensor 10 does not have any Y data but does have X.

Here's the Google Spreadsheet if anyone wants to look at all of the data
Here is another animation with each sensor labelled with it's number. The blue vectors represent the sensors with data from the newtrackdata.csv file. Point 10 is green because it had information only for X axis and wanted to see where it was located.

viveStuff.scad.zip

The 0-3 represent the IR dat code, see https://github.com/nairol/LighthouseRedox/blob/master/docs/Light Emissions.md
The last column is the time, in 1/48 millionths of a second (aka ticks) of the time between the last sync pulse and the time that particular laser swept the point.
From what I can tell, 200,000 is dead center, it looks to be about 0.00009 degrees per tick, as I think one revolution is 400,000 ticks.  Someone should check my math on that, though.

OK, thanks, so it looks like I don't need to worry about the IR dat code since you already calculated X and Y from it.
Here is the table I got from subtracting 200,000 from the number to center it and then scaling by .0009 to get degrees (400,000/360 = .0009 so it looks like you had an extra zero in there).

X  (degrees from center)
Y (degrees from center)

-8.416500
-37.606250

-8.602045
-35.786689

-4.584530
-36.499129

-6.250571
-36.077187

-5.348712
-39.878528

-6.385500
-38.191597

-3.933958

-7.979943
-39.510636

-0.641270
-34.350727

-1.718814
-35.612807

1.573604
-34.513354

2.023397
-36.402052

-0.798653
-39.376234

0.434340
-36.078383

0.306598
-38.124265

that totally looks believable, now comes figuring out the harder problem... Now, I'm curious if Alan Yates' twitter comment was in reference to us "Ugh this parametric surface interception is a multivariate transcendental equation, so much for a closed-form solution..."
I had given it some thought to try to linearize and turn into a matrix to solve, but, I don't know how well that would work.  I was planning on doing an iterative approach.  If anyone can find a better one, that would be super swanky.
I think I'm going to record more data, with IMUs, too.

Ben came through with the email to HTC!  They had our config!  Here is the config.
correct_hmd_points.csv.zip

Now, I have more info.  This is with two lighthouses pointed at the HMD on the floor.  I have also included IMU data for the HMD.
two_lighthouses_test.csv.zip

Cool, I'll have ti add the correct points in and compare, see how different they are to the one's we've been using.
Trying to solve the problem of finding the location of the lighthouses, I think I found something that might be useful. Since we know two points and the angle between them I was going to try and graph all possibilities (starting in 2d). I thought I got something wrong because I kept getting circles from the few points I put in. It turns out that it is a property of circles. My thoughts now are to try and come up with equations for 'spheres' for a few sets of points and see where they intersect. (I'll try to work on that tomorrow if I have time.)

vk2zay says we'll "have" to use iterative methods.  They're always my go-to and I was going to try to do one, myself... but now, I wanna try to find some other way just to be weird. :-D

Have you looked at the Perspective-n-Point problem?  If you consider the each lighthouse to be a camera, and the angular positions of each tracked point to be pixel locations of "points of interest" in an image that is generated by that "camera," you can start looking at the whole system as a more traditional computer vision problem.  At least that was a big "ah-ha" moment for me.
I'm probably repeating stuff you already know, but the problem you run into if you try and calculate the position information from a static set of data (i.e. a full x and y sweep) is that a moving tracked object will move to a different location between the time you get the X and Y sweeps.  So, unlike a traditional camera, you never get a simultaneous X and Y position.
I suspect that the way it works is that an initial fix is acquired using one of the Perspective-n-Point problems.  Then, a Kalman filter is used to iteratively integrate sensor and IMU readings to maintain the position.
I remember seeing a video at one point where Yates stated that they could maintain tracking for an already locked-on tracked object with a single sensor and IMU readings, as long as there was sufficient movement of the object.

The principle all along has been to use two different algorithms.  One to solve for camera position, then, during runtime, use camera positions to solve for positions and orientations of the objects.  These are different steps.  Right now, I'm only on the first step.  I strongly feel we should only focus on camera positions now.  I have my own ideas too about the runtime locations, but, that will have to wait until phase 3.
Re: PnP problem, that does look like the "right" way to solve it.  I have never heard of it, but I did once see that Hugin uses RANSAC to get camera positions and it is AMAZING at it.  Only thing is in Hugin's case it doesn't consider depth with its features so maybe this problem won't work out quite as AMAZINGly.

Following on from Mikes PnP comment, you may want to look at:
https://en.m.wikipedia.org/wiki/Epipolar_geometry
In theory, with enough samples, you should be able to reverse the base positions.

I don't know how you would invert that problem...  I would be interested to see if you have any specific ideas.  Re: the PnP route... someone has a C++ EPnP Solver in C++ -- but it is licensed under the FreeBSD license.  Since it's not part of the core algorithm, I might consider giving it a whirl: https://github.com/artivis/epnp

Sorry, the Vive also has a sensor in the base, which will give relative angles between the stations...

I believe that code is from the authors of the EPnP paper.  It requires OpenCV.  The problem I've run into, and haven't had time to get past yet is figuring out the intrinsic and extrinsic parameters of the Lighthouse "camera."  OpenCV has routines to calculate those for you, given a bunch of camera frames using one of two calibration images.  One calibration image is a circle, and the other is a checkerboard.
The math got a little hairy for me, so I was hoping to use the OpenCV routines, at least to start with and get a proof-of-concept.  I think you could simulate a checkerboard pattern by constructing a custom sensor that is a grid of sensors on a flat board.  (Similar to this, but in a planar grid.)  I think that calculating these parameters should be a one person, one time kind of thing.  Then, you should be able to use the EPnP algorithm to compute position.
Also, someone sufficiently knowledgeable in computer vision should be able calculate those parameters more or less "perfectly" without any custom hardware.

The Vive is a "perfect camera" system, without distortions or scaling issues.  You should be able to just implement it without the checkerboard calibration - I'm at work at the min I'll post a paper with a unity camera matrix later from home.
Using the Epipolar technique with the known angles between the stations, a single set of EPnP distances output should give you enough to "Fix" the base positions relative to each other.  You would then need to either use the IMU or "describe" the room like Vive in order to then fix the bases with respect to the ground plane.

@Galastorm: Any idea where that information could come from and/or how?  I didn't see any data coming back from the lighthouses.
@mwturvey: A few people have been worried about parameterizing the "cameras" in the vive system, but part of what makes it so magic is that they really are /perfect/.  It would take a herculean amount of effort to get regular cameras calibrated anywhere near as well as the lighthouses are naturally.  Also, you are correct, it does rely on OpenCV, which is not an acceptable dependency for libsurvive.  I wonder how hard it would be to write that out and keep the FreeBSD license vs. brew our own.

Sorry, no. I've just seen the sensor in a picture of a base teardown. I assumed (I know, ass-u and all that) that the information would be available somewhere in the system.
If you don't have direct access to the base angles, then they'd need to be worked out using simultaneous equations and sets of PnP angle readings.

I've not worked much with computer vision before, and couldn't find any info on what it would consider to be an ideal camera.  It sounds like it does mean that the angular distance between any two adjacent pixels is the same: that's awesome.
I also would really like to have a small standalone library that can do this instead of a dependency on OpenCV.  My goal is to get it to run on a microcontroller-- basically to get high quality tracking in a small package.  There seemed to be a lot of tentacles once you get into the OpenCV code.  But, I think most of those tentacles com more from generic abstractions that OpenCV reasonably makes, but aren't needed in this algorithm.
The approach I've been considering is starting with a small test app that could repeatedly run with each small change to see if anything broke, and surgically removing pieces out of OpenCV to get to a minimal implementation.

@mwturvey  Conveniently, the "where are my lighthouses" problem is something that would probably not be needed on the microcontroller.  Only the localization code.  That said.  Even for the PC.  OpenCV is unacceptable for this project.
I was just gonna take a whack at implementing the OpenCV functions they use, myself tonight.

Here are some amateur's thoughs.
Background understanding (and the TSSP)
Timings are measured in "ticks" and are "since the last sync pulse", so I'll call them Ticks Since Sync Pulse" TSSPs.  I understand "sync pulses" to be wide angle flashes that don't scan, but flood the
room.  Subsequently horiz. and vert. scans are done with rotating lasers (or mirrors) that shine a sheet of light across the room at a known angular speed.  The TSSPs are generated by each photoreceptor on the headset detecting the the H/V scans.  This is the data the headset collects (part of it, at least, the IMU does accelerometer stuff too).
It's NOT a speed-of-light thing
First - this is absolutely NOT a speed of light problem.  In acoustics you can tell with your ears where a source of sound is from the Time Difference Of Arrival (TDOA).  We are NOT in that realm here - speed of light is SO fast, that in a single tick, light has moved more than 6 meters (3e8/(1/48e6)) > 6 meters.  So I think we can totally forget about time-of-flight arguments.
So although we are looking at timings, none of them are to do with "it arrived here later because photons spent longer in flight".
Aim -  we want 5 things:
We want 5 pieces of information: bearing and elevation of the headset from the lighthouse (angles), distance between them (meters), and the orientation of the headset (where would the "wearer" be looking if they were looking straight ahead") (both are angles).  [ so 4 angles and a distance ].
Bearing and elevation of headset relative to lighthouse (infos 1+2)
angular location (ingore orientation) of the headset relative to the lighthouse.  If the headset is "upstream" in the sweep, every sensor registers a "smaller" TSSP, and if the headset is "downstream" in the sweep, all the TSSPs are bigger.  If we average ALL the sensors TSSPs on a given sweep, we'll get a good idea of where the headset is (angle L/R in the horiz scan or angle up/down in the vert scan).  This measurement ignores the orientation of the headset, but is probably a really good approximation of the "angular position" of the headset relative to the lighthouse.  It doesn't give us the distance between them, though (time-of-flight of photons would be useful here, but they
are too fast).
Summary: By averaging the TSSPs in the H (V) scan, we get a reasonable longitude (latitude).  This is from the point of view of the light house (but easily reversed except be careful, we don't know the
orientation of the headset yet, so don't do that).
Orientation of headset, and it's distance from lighthouse (infos 3,4,5)
As a horizontal (or vertical) scan sweeps over the headset, it will trigger the sensors in a "wave" across the face of the device. (I assume the sensors to be on a single plane - perpendicular to the nose
of the wearer - like a face-mirror would be orientated).  This is an oversimplification but stick with it).  Imagine the headset at a random angle, and imagine a thin red light sweeping across it at
constant speed, triggering each sensor as it passes.  This can be thought of as a "wave".  The direction of travel of the wave, within the "plane" of the sensors can be measured from the TSSDs.  The speed of the wave can be calculated too, from the TSSDs.
The direction of this "wave of activations" gives us the 2 angles of orientation of the headset (the arrow points away from the lighthouse).
Finally, the speed of the wave across the sensors will yield the distance of the headset from the lighthouse. (You have to take into account the angle of the headset, but we just calculated that above).
Note - all this needs only one lighthouse.  The estimation of R (distance between lighthouse(s) and headset) is much more stably calculated from the "triangulation" between 2 lighthouses.  I expect
everything improves lots with 2 lighhouses, but I haven't given it any thought.

So the tracking data is missing the length of the pulse, this is needed to recover a first pass estimate of the z coordinate of each sensor relative to the lighthouse, because the time of the pulse is roughly proportional to the inverse of z we can calculate it.
This z value is needed for first to resolve the ambiguity of building a 3d point out of a 2d projection (how do you know which way you are viewing the object from, if you view the object from the front it will appear the same as if it is viewed from the back) and from there it can be used to match it with the config data.

Hmm... I had no idea that was used at all.  You can tell which way you are oriented because of physical limitations, i.e. lighthouses above headset in Z... and because the curvature of the headset will give away any such failures. ALSO Don't forget I can get you the normals, so unexposed photodiodes will not react...
All that said, sounds like I need to expose pulse length!

I will take more data soon, but, something looks wrong with one of timings, I think I'm syncing to the wrong pulse.

Ok, here's a new one with lengths.   Also I corrected some more correlation errors.
third_test_with_time_lengths.csv.zip

One other note... My math just isn't working out if I assume 400,000 ticks is the time of a circle.
float angle = (hmd_point_angles[k] - 200000) / 200000 * 3.1415926535/2;  //XXX XXX WRONG??? OR SOMETHING??? WHY DIV2 MAKE GOOD?

I am just confused.  Anyone else got a chance to look at the data?

From what I've seen, the laser rotors sweep at 60 rotations per second.  Assuming 48mhz clock, that's 800,000 ticks for the time of a full circle.

Splendid, looks like I can go to sleep!  I still have a fair bit of work that needs to be done, like righting things so down is down, but this awful awful method might actually work!  (P.S. Located in 'tools' under 'planetest')

Here is what I have so far. With what I had said above I was able to construct a surface that represents all possible points that an observer can be given two points and the angle (from observer) between them.
This results in a torus shape. I'm not too sure how useful this will be in practice since the points are so close together it is practically a sphere but who knows.
I was originally thinking that you could find the intersection point between a few of the torus' but since they would be so close together, I'm not sure that is feasible. It still might be helpful for other uses though.
torus.scad.zip
module torus(p1,p2,angle) {
   z =dist(p1,p2) /2;
   r= z/sin(angle);
   R= r*cos(angle);
   e=(p2-p1)/dist(p1,p2); //end vector

   translate(p1)
      rotate( [0, 1*atan2(sqrt(e[0]*e[0] + e[1]*e[1]),e[2]), 1*atan2(e[1],e[0])])
      translate([0,0,z])
   for(th = [-180:10:179]) { for(phi = [-180:10:179]) {
	 x= (R +r*cos(th) ) * cos(phi);
	 y= (R +r*cos(th) ) * sin(phi);
	 z= r*sin(th);
	 color("grey",.8)translate([x,y,z]) rotate([0,0,phi])
	    cube(5.2,center=true);
      }}
}

Can you post the full & correct JSON-Config file? I think for a neat solution we will need the model points and the model normals.

Here's mine, I've marked the sections that would need to be customized by someone's with XXX's.
LHR-B4ABXXXX-Charles.zip

Here's the normals in CSV form for anyone who wants it...
hmd_normals.csv.zip

@cnlohr I think I follow what you're doing in the planetest: you're working on a single LH set of figures and checking x/y/z/ positions in a sphere around the cluster points to find the converge on the best sphere position (and thus angles) which fits the data?  But I can't figure out if you're taking the relative 6DoF of the LH emitters in to account?
For example each LH will have a different pitch/roll figure which would alter the XY angle ratios and therefore the XYZ positions worked out from those angles would not be using the same co-ordinate frame.  Imagine worst case of a LH on it's side...
(Please add a few more comments for those of us that need a little hand-holding! :-) )

I willl, I will! So, the way I was doing it was going pitch, roll, yaw, one at a time trying to find the best orientation.  This simply will not work at the macro scale... at least reliably.    It's also way slower, because I have to try a ?thousand? orientations before I figure out where it should be pointed.  I have to do that once for every position I try the lighthouse at.
It does happen to get the right answer most of the time for me, but this is bad.  I am going to try a more analytical solution, to purposefully point the lighthouse at the HMD from every possible position.  I will call this "planetest2"

Basically I was just trying every possible combination of position and pitch yaw roll I could think of.  This is bad.

Just to pitch in my two cents, this would be my starting point as to how I’d approach it…
Do the calibration dynamically rather than off-line, the user will expect to have to spend some time doing it and you can use more CPU intensive approaches within it that don’t have to appear within the standard mode.
Use the HMD or controller (in plain sight of both LH bases) to determine and then eliminate differences in the roll aspects of the LH bases first (standing in sight of both bases and PRY the headset whilst trying to keep the HMD in the same physical location).  Once you know the declarations are plumbed you should, I think, be able to start looking at the X and Y declarations as entities in the same plane.
Then move the controller up/down and forward/back all the time in view of both LH such that there is always at least one sensor that gets readings from both LH bases.  This should give you a whole load of points that you can do a simultaneous equation on to work out the relative pitch and yaw of each of the LH.
Finally move the controller in PRY and forward/back/up/down.  Take readings for pairs of sensors to look at the angular separations vs known maximum physical separations – you should be able to get a very good indication of the actual distance (and, with defined bearings to single sensors - the XYZ positions) by scaling against the defined HMD separation.  Unfortunately perspective will be the downfall of accuracy here because you’re never going to precisely match the bearings and the ratios.
A much better solution for the final step would be the dreaded PnP to get both at once and make it a simultaneous equation…

Interestingly, the VIVE system also has the ability to refine the relative sensor positions from the default drawing positions on an HMD and controller when in use.  This removes the manufacturing tolerances from the devices and makes the overall system much more accurate in depth.

What you've described would be very cool, but, exceedingly difficult.  And, I would worry the absoluteness of the lighthouse system would be compromised.   I guess I don't fully understand what it would be solving, absolutely.  It would be nice to know the lighthouse locations better, and I think you could resolve better over time, but I think it would be a very, very long process, realizing the data consistently pulls one way or another.

I think I've found something that might help, sorry in advance if it doesn't help. I would try to program it but I'm a total noob.
OpenCV have algorithms that can approximate very fast the pose of a model given the 3D points from the model (the position of each sensor relative to any point in particular, say the center of the HMD) and the 2D points from the still image. This returns the translation vector (x,y,z) of the camara from the center of the HMD and the rotation vector (roll, pitch, yaw) from from the center of the HMD.
http://docs.opencv.org/2.4/modules/calib3d/doc/camera_calibration_and_3d_reconstruction.html

@octavio2895 : There is a lot of detail there when using cameras, etc... which thankfully, we don't need.  The lighthouses are all already pretty solid.   The other problem is that it's all so tightly coupled to OpenCV, itself which I would like to avoid inclusion of.
everyone else: I now have a tool able to determine location of the lighthouses pretty? accurately.  I verify the position by pretending to shoot rays out from the lighthouse where I expect the photodiodes on the HMD and see if it lines up.  Currently works for two lighthouses at the same time.  I really need to get issue #1 resolved.  I am sure it can be done better and faster than the way I am doing it.  See it in the tools/planetest2 folder.

Another test file if you guys want to try!  testfour.csv.zip

@cnlohr Would it be possible for you to create a test file with movement along the lines of the routine I outlined above?  I've just had delivery of a 300Mz Cortex M7 board  (double precision FPU and DSP extensions) and I really would like to see if I can't push through a PnP solution on to it.  I've some ideas about optimisations because the lighthouse angles are so accurate wrt to a standard camera.
Also the what are the 6 axis of the IMU?
No major hurry as I'm about to head to Bruges for the christmas markets for a few days!! :)
Thank you!!

So you want me to pick up the controller, move it around left right up down as I try to make sure the same sensor is visible to both lighthouses?
P.S. I can't right now since as soon as I power on the watchmen the data gets totally borked going to the headset.  Not sure why, though :(.

@cnlohr Thank you :) Seriously though, there's no rush whatsoever. I'm going to be in no position to use the data for days, and possibly not until the holidays.
I can't believe that I am going to miss another live stream....

Actually, it's the HMD that you have the position and normals for? Could you do it with the HMD please?
Thanks again!

Are you sure you typed what you meant @LeeCookGHA ?  If so, I don't understand your request.

@cnlohr He's asking for you to dump data when you are moving the HMD instead of the controller since we have more about the HMD than the controller.

oh! Gotcha! I think I will collect a variety of data.  Probably on the livestream tonight.  I'll see if I can get some now.  I do want to try capping data from the watchmen, too.  I will fix my one bug in the disambiguator.

@octavio2895  @LeeCookGHA  Here's the data of the HMD being still and the HMD moving.
hmd_moving.csv.zip
hmd_still.csv.zip

Nairol who did LighthouseRedox was in the chat and linked this but it was missed.
https://github.com/nairol/LighthouseRedox/tree/master/data/calibration data
This will get you controller calibrations.

This is the HMD static in the middle of the room. From the livestream 4.
livestream_test_1_with_hmd_in_center.csv.zip

"computation of the Lighthouse positions"
https://trmm.net/Lighthouse

Reading lighthouse usb data
https://github.com/nairol/LighthouseRedox/blob/master/docs/USB Protocol.md

@MrRedBeard :: The github reference does not show anything about lighthouse receiving light data.

Ah I should have read in more detail.... multitasking

from Sharp Labs  Correction of visible mura distortions in displays by use of flexible system for memory resources and mura characteristics  http://www.freepatentsonline.com/y2009/0096729.html
“Mura” defects are contrast-type defects, where one or more pixels is brighter or darker than surrounding pixels, when they should have uniform luminance... Mura defects may also be referred to as “Alluk” defects or generally non-uniformity distortions.
In general, most mura defects tend to be static in time once a display is constructed. However, some mura defects that are time dependent include pixel defects as well as various types of non-uniform aging, yellowing, and burn in"

don't know if it helps, but the following C code can reconstruct location/orientation of an object relative to a camera, if the object's points self 3d configuration is known, and the location of the points seen by the 2d camera given. This looks exactly as the case here.
http://users.ics.forth.gr/~lourakis/posest/

@shaise would you mind running it with some of the example tools?  You may be able to copy-and-paste the loading function at the bottom of camtest.c and it will give you the points on the HMD and vectors from the R or L lighthouse.

Apologies if this is rambling it's late and I have just got back to to my hotel.
I don't think that you are using the HMD normals to best effect. If you look at the data shhet for the photo diode it has a fairly good relationship between the angle of incident and the power utpout, couple that with the

actual time the laser will sweep over the diode surface and the times the sensors are lit wrt each other should be a reasonably weighted output as to the position of the lighthouse wrt the hmd normals.

I will give that a shot in camfind.c tonight.  I would imagine it should be related to the dot product.  Just wondering which photodiode is being used?  I was planning on using https://www.digikey.com/products/en?keywords=1080-1366-1-ND

bpw34  is the photodiode, and the TS3633 is used for amplification and envelope detection

Hmm, just saw the Upload article on it.  I think it's still worth me poking around on my own even with that, though that opamp is almost an all-in-one.  I wonder why the BPW specifically?  Not SMT, or is there an SMT version?  eeehhh... we need to take this offline, back to trying to use normals to refine estimates.

This suggests that the time between exposure of different sensors (at known distance apart) can determine distance, rather than the time of exposure of one sensor:
https://github.com/ShadowApex/liblighthouse-mocap
https://github.com/ShadowApex/liblighthouse-mocap/blob/master/examples/distance_3.gif
It seems that overlap of multiple normal frustrums could also help localize lighthouse location in a similar fashion.

For what it's worth, the TS3633's prototyping module (TS3633-CM1) comes with a PD70-01C/TR7 photodiode.  It's also worth noting that the TS3633 is the part that filters out signals that aren't modulated between 1-5MHZ.  While I haven't tried to intentionally inject interference, I've not seen any spurious signals from the TS3633-CM1, which has been helpful.   I wonder how much effect different photodiodes will have on measured pulse durations, particularly when hitting it at different angles.

@geekmaster I am including the length of the pulse in the data files, so hopefully that'll be able to help with the normals, too!

Apologies for the drunken spam!
So what I was thinking was to look at the durations of the lit sensors, weight them based on the difference between the min and max (say applying 5% for min 95% for max) by applying a curve which is a of combination the responsiveness of the diode vs angle and the perspective of the diode surface wrt to the lh.
It needs to be a min:max ratio though as the absolute duration will be more a product of the distance than the angle.

Two days and I'll be able try this myself.. Hopefully the summing of the weighted vectors will give a reasonable approximation of the direction of the lh.
Then, it should be possible look at the direction and angular ratio of the two sweeps over three sensors in a triangle. That should give a reasonable and fast approximation of the roll of the lh wrt to the hmd.
I'm hoping that it will be enough of a starting point for some of the pose estimation routines.

@cnlohr ,
I wish I had more time to work on it, its a cool project, but caught me just before going to 50 days vacation...
Anyway, I decided to do at least a quick and dirty test to determine HMD location relative to lighthouse.
I think the results are promising, since I randomly selected 4 sensors to do the math and the result (rotation and translation matrices) where fairly close.
The method to do that is using POSIT algorithm: http://www.cfar.umd.edu/~daniel/daniel_papersfordownload/Pose25Lines.pdf
I had no time to implement it myself, but it should not be that hard. Instead, I used a ready made c# LGPL library, Aforge.NET: http://www.aforgenet.com/articles/posit/
The attached sample c# program (should work on mono as well) takes HMD sensor configuration (no need for normals) and lighthouse data. (zip contains files I used)
After loading config and data file, a list of sensors are shown (for the L lighthouse). if you select any 4 of them you can do the calculation and get a rotation and translation (in mm) of the HMD relative to lighthouse.
Example result for sensors 10, 11, 12, 27:
Rotation Matrix
-0.023	0.392	0.920
0.994	0.108	-0.023
-0.108	0.914	-0.392
Translation vector
-541.042	-280.735	3620.589
Example result for sensors 8, 10, 11, 12:
Rotation Matrix
-0.038	0.428	0.903
0.998	0.068	0.002
-0.060	0.901	-0.430
Translation vector
-535.809	-283.032	3607.187
Just a few mm change and a 3.6 meters distance looks very good.
The estimator works on 4 points, but the original algorithm can work on more, so maybe it can generate better estimation. If you look into AForge sources, it looks rather easy to follow the algorithm.
Here is my source with .net binaries:
https://drive.google.com/open?id=0B3uO2iX6FayBRHlWUEtVVUxRUUk

@shaise : This looks like it's doing something similar to what I'm doing in camfind.c?  Or rather what I tried doing in camfind.c first... Then I found out I could be more intelligent about how I could be with fixing rotations... though this seems to be much better at converging to a position solution.  Also, there are a lot of other steps I hadn't considered that may aid its ability to resolve to an answer.  What data set was the one you ran from?  I think I am going to include some reference data sets in issue #8 - that way we can start using common data.  First I need to fix the disambiguator for the watchman controllers.
I will say your data looks like it's predicting the lighthouse being too far away.
@LeeCookGHA : I wonder if we'll be able to make something like camfind more generalized.

I was using correct_hmd_points.csv and livestream_test_1_with_hmd_in_center.csv L lighthouse. These are included in above zip file. If you have a windows system (or Linux mono) to run the binaries, you can try other data.
I don't know if it is exactly the same as you have done before, but if so, did you project the angle values onto a 2D plane before calculating the pose?
I wish I had the time to convert all code to C and ditch any external library. I can still do it 50 days from now if needed. The nice thing about the POSIT article that they claim its good for realtime 60fps tracking as demonstrated on a 1992 MAC...

I might be able to give it a shot myself.  Conveniently, this process of finding the lighthouse does not need to be realtime.  Once the lighthouse positions are found we can proceed to the next step. I do not mind re-coding things myself too much, either.
"Going on a 50 days vacation" :-p vacations for me are working on projects, so if I was saying something like that, I'd have unlimited time to do this!

Hi,
I'm just having a look at the raw data atm, and trying to determine what can be gleaned from the "step" values alone.
(I've been calling the timing data the "step" values, but I'm not sure what your terminology is atm?)
So, for example, I'm looking at the first 15 data points for the X sweep in "newtrackdata.csv"...
[http://imgur.com/a/ozhrA]
I'm just trying to get my brain around the basics atm, so bear with me. :p
I'm guessing that the current algo for the camfinder is basically doing something similar, but I'm looking to calculate what the difference value would be for when two of the sensors are perpendicular (and equidistant) to the sweep?
So, for the first two values of 190,444 and 190,649, the "step" difference is 205, but what would that value be if both sensors where exactly perpendicular to the laser sweep?
I imagine this is basic trig stuff, but I was never great at that at school. lol
I'm thinking that you might only need to do an interative calc for only each "strip" of sensors at a time (one calc for the X sweep, and one for Y.
Also, I'm assuming that the master clock is always running at 48 MHz for the sweep "step" counters, and that's what gives us the 0.0009 degrees per step?
Plus, the sweep period is essentially only 8.333 ms for ONE of the X / Y sweeps, since it essentially only covers 180 degrees of usable area after the sync pulse.
That also means that there are a maximum of 400,000 counter "steps" for that 180-degree sweep?
(800,000, if we're counting the full 360-deg rotation of each rotor?)
Each rotor spins at 3600 RPM, correct? So 60 "sweeps per second" for the X rotor, and 60 SPS for the Y rotor (but alternating, of course)?
If I could just calc the step values for each pair of sensors being "square on" to the sweep, and then at almost a 90-degree grazing angle, that would be a good start.
Obviously the timing data for the sensors is already sorted in order of the edge detection, but I've also sorted the HMD sensor point data on that spreadsheet, and made it so the "sensor distance" values are always positive.
I've installed OpenSCAD as well, but I can't seem to get it to display properly if I modify the code and then re-render? It only seems to work after I first run the proggy, then open a file?
Anyway, the idea is that once the step value differences (between any two sensors) have been translated into the rough angle of the incoming laser sweep plane, every consecutive pair of sensor values would help to improve the accuracy of the resulting angle.
Then the same would of course be done for the Y and Z "distances" between the sensors, and then everything combined into one vector.
I'm not sure how the sensor normals would work with all of this yet though.
I imagine they are extremely important for both accuracy, and determining if the incoming beam is further forward or further behind each sensor pair, but would just the step difference alone give a fairly good estimate of the LH position?
I think I need to order a few nice IR sensors, and build a rudimentary LH.
I don't have a Vive yet, but I'm definitely interested in getting one eventually.

Actually, maybe i'm wrong, but I think with this algorithm you do not need to find the lighthouses. You can apply the same algorithm to get translation / rotation of the controllers. All done on the fly per dataset. The controllers values will also be relative to the HMD if you diff the matrices. So all that is needed now is to wear the HMD in mid room, face a default direction in the room, and set this translation/ rotation as a calibrated base.
Regarding vacation, I can safely say I have all year round for projects - SW HW and mechanics (as I work only few hours a month), but once in a while need to have some network challenged nature around...

lol
I just skipped into the last live stream vid again, and at 2:12:00, Mr Lohr explains how he's already converting the LH data into radians for each sensor.
Is it not enough to just use those values to narrow down the angle which points TO the LH, then do the same against the Y and Z sensor point values (and the Y sweep), then combine the X,Y,Z angles into a single orthogonal vector?
Once you have a vector pointing towards the LH, and then calc the vector to point towards the other LH, would that not give the point where the two vectors cross, and thus the HMD position?
(I know, that's basically what you're doing already, but again, I'm just wondering if I'm way off-base here?)

I think this was also hinted by @vk2zay's mode 'A' - one lighthouse. There is no actual need for 2 lighthouses as one is enough for positioning, the reason for using 2, is for the cases where you turn around and your body obscures the controllers from lighthouse A.

Yep, and I read an article last night where they said that the positioning jitter (for the HMD at least) is only 0.3mm when two LH are used, and still only 2.1mm with one LH. Pretty damned impressive. :o
I really should buy some sensors to mess with now, as I could at least implement the basics of this on an FPGA, and get very accurate timing data back (using the same 48 MHz clock).
It will be cool just to see how the timing difference changes between a pair of sensors when their angle is changed relative to the sweep.
I'll have to buy some laser line gen lenses etc. I have plenty of spare laser diodes, at least. :p

I'll have to try compiling this code.
I'm amazed I can actually read and understand it.
I didn't even know you could do something so simple to grab the values out of a CSV.
float fa, fb, fc;
int r = fscanf( f, "%g, %g, %g\n", &fa, &fb, &fc );
...Where %g is the format of the number in the CSV (floating point), \n is the newline char, and it just spits out the values to the address pointers of the floats. ;)
I'm guessing that fscanf returns a number for how many requested values it found?

@ElectronAsh Yes, indeed we have the angles from lighthouse center for the points -- though I am thinking we should probably sanitize them with something to throw out outliers.
@shaise Are you referring specifically to using the normals of the incident light on all of the sensors on the HMD?  Or are you referring to just getting the angles from the lighthouses' POV?
@ElectronAsh I don't believe it's possible to get relative angle from one lighthouse to the other.  If there is a way of getting precise timing of when one lighthouse sweeps the other that would be most dapper.  I just haven't seen any references to that.
@shaise I have heard vague murmurings about this being possible without knowing lighthouse location, however, I am most concerned with simplicity of tracking solution.  Calibration can take a while, that's okay.  Tracking cannot.  I believe if we know the locations of the lighthouses, the path to getting position in a global frame can become much, much easier.  I could be wrong in this belief, though.
@ElectronAsh I am seeing INSANELY good tracking of object position based on the lighthouses, but it seems to be much more difficult to determine lighthouse position.  The error I'm getting on some of my "best lighthouse positions" are in the order of 0.6mm per photodiode!  Unless we "know" lighthouse positions, this is not applicable, though.  Your laser line thing sounds like a hackaday publication in the making!
P.S. About the C thing.  I don't use C because I'm as masochist.  C does as much as is sensible in the language to make things as simple and easy as possible.

I like C.
It makes the most sense to me as a coding language (although I'm still learning).
The C++ extensions just confuse the hell out of me.
Like when they changed the whole MAME / MESS source from pure C to C++. So many macro everywhere, and code spread across more files, which makes it far more difficult for me to follow the code in a "linear" manner.
I find most C sources as far neater and easier to read, while still achieving 99% the same thing.

Back on topic: I think I'm going to try to switch camfind.c into polar coordinates.   Then, maybe find the centroid of the precision distribution.  Also, still need to get the disambiguator working better with the watchman controllers.

@cnlohr , I was referring to just using lighthouse POV angles and HMD sensor configuration. No normals. (not required by POSIT). I feel it is fast enough for realtime tracking (I was able to perform the entire computation 100000 times per second on my 3 year old i5 laptop, using the slow c#.)
Anyways, hope to catch at least some of the next live sessions on my trip through NZ. You guys rock!

Feeling very lucky to be back from the Christmas markets in Belgium after the horrendous attacks in Germany!
I've just taken a quick look at the normals data vs light-up for a side-on view data file and it looks quite promising for being able to quickly provide an accurate initial pose to the LH. With the HMD on the floor (approx -2m down and 3.5m away?) that would put sensor 1 presenting an aspect ratio of around 1:0.84 x to y - we see timing ratios of 1:0.87.
It also looks like (through sensor 12) that there is a minimum amount of power necessary at the sensor in order to detect that it is being lit and that the laser width is likely much thinner than the sensor width (2.75x2.75mm if it's the Vishay part)).  With a very shallow side perspective it only lights in the X axis (i.e. virtical laser axis) implying that the coverage of the laser in the Y axis is not enough?
Will hopefully be able to look at more of the data to try and get a better feel for the problem variables this evening after work.

Ok, so looking at it some more it's nowhere as promising for an accurate vector combination as I thought (I've deleted my previous post as confusing).
I pulled all the info from (livestream_test_2_x_axis.csv) in to a pivot and looked at the averages rather than a dip in to the centre, and the lit timings must be affected a lot more by the width of the laser line than I thought.  Assuming the photodiode sensor area is 2.75mmx2.75mm that means the laser centre is pointing at the diode surface for approximately 100 to 175 ticks at distances of 2-3m (60hz, 21600deg/s, 48M tick)  But there are sensors with averages of up to 557 ticks (RX30).
This implies that either the laser dispersion (6+mm width?) is lighting the well before the centre of the laser line reaches the sensor, or that the processing circuitry is somehow extending the duration, or a combination of the two.
More investigation is necessary I think...

@shaise : I think a lot of good data can be pulled from the normals and length of pulses.  Makes me nervous to try to use POSIT, especially since it doesn't look too different from what I tried initially, just that it would converge much, much faster.   Though that would mean I could supplant my original algorithm if I could figure out what was going on.
@LeeCookGHA : There is a fair bit of analog circuitry from what I understand that helps infer intensity, not just dispersion.  From what vk2zay mentioned in one of the livestreams when I suggested piping the thresholded data straight into an ESP32, he indicated that wouldn't be a good idea - so I'm thinking there is more to it than dispersion width.   This also kind of makes sense if you think about it as charging an integrator if it's very bright that will take several light-cycles to decay and finally go under the threshold.

I have a strong feeling we may get a few hints from this vid. So weird that it should show up right now...
https://youtu.be/75ZytcYANTA

It took Hackaday a little time to edit the videos, the talks have been showing up one by one every few days.  There is nothing much in that video about the inverse problem you are currently trying to solve, it is more about the hardware challenges.
I can confirm some of the assumptions in this thread though.  The width and divergence of the beam, the sensor size and its pose with respect to the base station is responsible for the varying pulse widths you see for rotor beam hits.  You will need to use the centre of the beam hit pulse, not its leading or trailing edges.  The exact width varies, the middle of it estimates the true centroid.
Your volumetric plots confuse me.  As you have noted yourself it appears angle is less well determined than range.  This is not true in general for triangulating systems; something is broken.  You might like to attack the problem in 2D first then extend your solver to 3D.  In 2D an object pose has only 3 degrees of freedom and the maths is simpler to reason about, but has basically the same form as it will be in 3D.  Starting with one beam, one sensor, then adding sensors until the solution is unique is instructive.  Directly trying to invert the projection problem may not be the best approach.  PnP and POSIT are built around camera models, they are instructive to study, but probably not the way you should solve the Lighthouse inverse problem.  Lighthouse is definitely not a camera, especially once you utilise the calibration information for the base station and absolutely not for moving objects.  That shouldn't stop you from trying simplified models on static data sets first, but for good dynamic performance with real-world base stations you will need something more complex.

@vk2zay: So, getting back into this now... After looking at some hypothetical situations, it seems that the scatter of being fairly precise as far as depth goes but not precise as far as lighthouse position goes is to be expected.  I suppose I should make this more concrete, and run my voxel representation on more "perfect" scenarios.  For that aspect of finding the lighthouse, I think switching to polar coordinates would be best.  For me, I think it would be more difficult to do 2D then extrapolate to 3D.  I work much more intuitively in 3D.   Additionally, I am specifically only interested in two-lighthouse environments, so it makes sense for me to stick to that especially considering approach 3 listed below.
I'm definitely discarding POSIT and PnP at this time.
I do want to do some more things to try to refine the solution.  I think coming at it from multiple angles and using these several pieces of information will help resolve to the best solution possible.  I intend to:
(1) Try shifting answers by the length-of-pulse up and down some to verify I am using center-of-pulse.
(2) Measuring pulse time as a function of distance and dot-product of the lighthouse-normal.  Then using this to aid the lighthouse position resolver.
(3) (Dependent on #4 and #11 ) Use watchmen controllers in role of evaluating positions of lighthouses, but not just to determine which way is "down" and the "floor" but also to resolve it from the approach of:   If lighthouse B is here and lighthouse C is here, they both make sense for the HMD, but their expectation of where the controller is makes no sense.  My only concern with that is it would require at least one photodiode on the watchmen to be visible to both lighthouses.
(4) Just toying with it: I could skip from this (Phase 2) of my grand libsurvive scheme straight to Phase 4 (Making an ESP8266 sensor) and ignore Phase 3 (Finding locations and poses).   I would just make a jig to calibrate the lighthouse locations with by using a coordinate frame.  Of course, this jig was for a camera localization problem I had to do a few years back, would be using photodiodes.  But it would by golly make it easy to define a coordinate frame for the room and find the lighthouses.

My idea for finding the location and orientation of a base station would be using the Inscribed Angle Theorem in combination with the Law of Sines and other basic geometric formulas. I've mentioned this in chat in the last live stream but without explanations it's pretty hard to understand. (Remember the PNG file with the triangles and circles?)
I've made a video explaining the concept in 2D but I don't know how to solve the problem in 3 dimensions yet. Should be possible somehow™.
Any math/geometry people in here that like a challenge? :)
Video
Geogebra file
Also sorry for the poor voice-over quality. I recorded this at 4 AM and am not that fluent in the (spoken) English language to begin with. Youtube's replay speed setting can help if you don't want to sit through it all. :)
So basically this would be a non-iterative approach to the problem but I'm not sure if it would work that well with Lighthouse's phase-shifted J/K sweeps when the tracked object is in motion. Might work in combination with an iterative optimization step afterwards.

I attempted to process some of the data and attempt to graph it in 3D.
https://sawaiz.github.io/viveDecode/
This data is from the hmd_moving (hmd_still has some slight movements so this is a bit more interesting to watch). The data is split up into events (400k ticks for x and 400k ticks for y create a event) and then graphed in time. The x is converted to phi, and y to theta, and the radius is currently a constant.
Points to note

The points at 0,0,0 and those stuck on the axis are the ones missing some data points, those should be removed from analysis.
There is a timeout on the points that don't get hit, so those need to be filtered out. This can be seen by graphing time from sync vs time. Its likely some number of ticks from the pulse.
There is some sort of mirror image on my graph, everything is from LH1, so I don't know where that could be coming from, perhaps my math is wrong somewhere.

I'll likely be trying to build the point constellation next to compare against the points, from three matching points in the constellation, you should be able to find out what he distance is.

I just saw this now.  I wanted to comment in this thread, I think I have the data from the HMD and watchmen going.  File is: find_lighthouses_with_watchmen.csv.zip in #8
When I click that link above, nothing shows up.   Should I be seeing something?

@nairol I think we can get a faster solution using spherical coordinates and vector algebra. In 3D, for every sensor we know 2 angles tetha and phi. In order to reconstruct the sensors in 3D we are missing lenght or r. We also know the distance between each sensor lets name it k. First we grab the angles from 2 sensors, then we subtract vectors and let them be equal to k. We do this with 1 more sensor and we are left with solvable systems of equations (3x3). The problem is that we would end up with more than 1 solution, so we add another point to the equations. We now know the position of the object relative to the LH.

Every approach I have taken to this problem requires calculating the rotation matrix for lighthouse which has to use cosine terms to relate the 9 variables to the 3 Euler angles but this causes the solution to be nonlinear which means you then need to use an itterive approach to get a good solve, and yeah then you will have more data then equations so you need to use least squares which only further complicates things. But I have a couple more ideas to try

Check out the data for distance/angle to pulse-length in #8 - maybe we should be looking at a hybrid approach that uses multiple mechanisms and then we select the best based on several approaches.

Something like this, I just tested chrome, edge, and mobile chrome, so It should work. Its 3d so you might need to zoom out or rotate a bit.

I would like for the solution to be non iterative though, it just feels so much more elegant.

While I'm here, I'll also drop this in here, its the time vs time from sync. The points at the bottom in a straight line are points that are timing out I believe. Don't know if its much help, but It made grasping what was happening a lot easier for me.

@Sawaiz -- lol you implied edge was a browser. I used firefox (doesn't work).  It works in Chrome.
I'm still not 100% sure what I'm looking at. If it is the HMD position from the PoV of each lighthouse?  If so, what tactic are you using?  Is it something more naive?

@nairol Thanks for the video description.  It's been long enough since I've had trig that I didn't recall the inscribed angle theorem, which is massively helpful. One thing I ran into is that you don't just have one circle that the lighthouse can be on-- instead there are two, depending on which direction you choose the line for the center of the circle.  Other may have already figured this out, but it struck me that with two points in 3D, the surface that the lighthouse could be on is a torus.  And that's why when you take a 2D slice, you get 2 circles representing where the lighthouse could like.  I was trying to figure out a way to calculate the intersection of tori, but maybe that's a bad approach.  Instead, if we can use three points to define a plane, then work on that plane to discover the two points where the lighthouse could lie, is there a way we could then rotate that plane to define a circle in a 3D space?  Not sure what axis it would have to rotate around, or if that's even valid.  But, if we can get multiple circles in 3D, that seems like a much easier intersection problem to solve than the intersection of multiple tori.

@nairol - my brother was thinking a similar approach.  I was toying with trying it, and just using an iteritve approach in 3D to try to find the optimal intersection, since in 3D, I think it is a donut shaped object that the inscribed angle theorem produces. (I think @mwturvey is right about it being a torus, since it's basically a circle wrapped around the axis made by the two points you're looking at.)
@mwturvey I don't understand what you are talking about when you are talking about another possible solution wrt not intersecting multiple tori.  (I could have sworn it would be greek, so torodes, but as it turns out, nope, latin!)

@cnlohr I was trying to figure out a way to avoid having to find the intersection of multiple tori, but I think my comment above amounts to sleep deprived ramblings.

I'm approaching the problem with simulated data first.  Given 3 points and the relative angles from a simulated lighthouse, I can generate 3 tori.  In the image below, you can see that the lighthouse (red cross) is at the "intersection" of the tori.  I still need to work the algorithm to find the intersection, but at least I can see what I'm doing now.
It's also interesting to see that there are two points where the tori converge-- both at the lighthouse location and in the exact opposite direction of the lighthouse.  I guess the normals will be helpful in filtering that out.

Wow. That intersection looks a lot like a portion of the "convergence" animation that Alan Yates posted here:
https://twitter.com/vk2zay/status/812220006129745920

Wow, I had no idea what to make of that animation when I first saw it, but, yeah, I think you're right!
I played with this a little more: I added a 4th point which now generates 6 tori.  I assumed the normals to all be in +Z, so I could be lazy and just chop off all -Z points as possible LH solutions.  I then took one of the tori (the light blue one), and for each point I found the nearest point on each other torus.  I used that to compute the least squares distance from each blue point to all of the other tori.  I then put a light blue star on the point that matched the best. (Look in the lower right.)  The red star is the location of the actual lighthouse.  It's very much worth noting here that I haven't introduced any noise into the signal, so not sure of the noise immunity with this type of algorithm.  I did try it with a much lower angular quantization, and it appeared to still work pretty well.  I can post pics if anyone wants them.

Sounds like it's getting dangerously close to a time when you should be trying the real data.

@geekmaster in 2D one way to solve the problem is basically circle intersections, pick one of the three sensors, you know the distance from it two the other two.  Each distance is a circle where the other sensor could be if you pin down the first sensor.  Similarly for the 3rd sensor there is a circle (likely of different radius) from the first where it can be.  Now you can parameterise the distance of the 1st sensor along the radial from the base, this parameter can vary from zero (touching the base axis), out to the distance where the circle locus to the 2nd sensor intersects the radial to the 2nd sensor only at one point.  (i.e. for only 2 sensors there is an infinite number of solutions where the line between the 1st and 2nd sensors lays in the plane segment between the two radials).  Adding the 3rd non-colinear sensor with its own circle from the 1st (or the 2nd if you like) and the intersection with the 3rd sensor bearing radial gives you a unique solution for position and orientation.
In 3D it can be done the same way, but with beam planes and sensor distance spheres instead of lines and circles.
You can think of it as adding constraints for each sensor you have a measurement for.  For zero sensors the object can be anywhere at any orientation.  With 1 sensor all you know is that sensor must lay on the beam plane (let's use the camera approximation and say radial line from two beam plane intersections instead of just planes, but you get the idea...), it can be at any range, any orientation (well you can narrow it down to a cone of orientations with the sensor normal and its response angle, but you need not).  Adding a 2nd sensor means the line between the sensors must lay in the plane spanned by the two sensor radials but the object can also rotate around the sensor-to-sensor line by any amount (and rotate about the cross product of both radial directions as long as the sensors themselves are still on the radials).  Adding a 3rd non-colinear sensor lets you solve for a finite number of orientations per selected 1st range, but the overall solution is not unique, there are multiple solutions where different sensor ranges can produce the same bearings with different orientations.  Adding a 4th non-coplanar sensor will disambiguate the pose solution.  Overdetermined solutions using 4 or more sensors are best done with iterative methods that minimise the residual projection angle errors of the solution pose - perhaps using subset consensus methods to reject outliers if you have a large amount of redundant data.
The shape of the convergence region of the 2D 3-sensor problem is probably not related strongly to the 3D version.  In 3D you have 2 additional rotation degrees of freedom and only one more spatial degree of freedom; the expressions for the Jacobian elements are much more complicated because they have 3-space rotations,  Some 2D slices of the 6D map of the 3D problem might be similar to the slices of the 3D map of the 2D problem...  Guess I should try plotting some.

@vk2zay That's very similar to what I was trying to do, I figure that if you know the coordinates in the camera view and the coordinates in the world view then you could determine the orientation and translation of the HMD. Using spherical coordinates and the distances between sensors, its very easy to compute the position of each sensor in camera view. Then using a this method http://nghiaho.com/?page_id=671 we could calculate the rotation and translation of the HMD.

@octavio2895 yep, something like that should work.  The solution (pose of the tracked object) is the rotation + translation that minimises the error between the measured bearings and the bearings that would result at that pose.
Given model points Pn posed at a translation of x and a rotation of r there is a projection function F(Pi, x, r) -> (azimuth, elevation).  This allows you to formulate an optimisation problem; fit F(Pi, x, r) - Bi = 0 using x, r over i where Bi is the measured azimuth and elevation of Pi.  The function F is basically two parts, the posing bit which gives Pi' = R(r)Pi + x and the projection bit which turns Pi' into Bi and is of the form P(x,y,z) -> B(azimuth, elevation).  Putting the base station at the origin makes the projection easy.

Instead of raw data, is there any way I could get some data for the angle/ tick count of the tracked sensors, as well as an approximate location of the lighthouse location relative to a static HMD?  (Basically the physical location info and output of the disambiguator, I believe.)
Eventually, it would be nice to have a few such data sets for testing purposes, including both having the HMD relatively centered in the lighthouse's "view," off to an angle, and also having the HMD facing toward the lighthouse and off toward a side.
I did plug in the data provided by @Ardustorm above, and got a lighthouse position of:
(0.380, 0.491, 1.875) for that data set, but I don't know where the lighthouse really was to compare against.

So this was my idea for a slightly different approach toward getting lighthouse position.  I still haven’t worked through the maths to see if it is viable, but I think it should be.
Take three sensors which have light data.  Create a plane in the HMD reference frame from those three sensors.  Now create a circle on that plane which intersects those three points choosing one of those points to be a zero degree point (this point should ideally be common with other plane/circles creations?) and work out the angle of the other two points on the circle wrt to the zero.
For those three sensors take the X/Y (az/el) swept angle positions and create an ellipse.  Generally you need 5 points to create an ellipse but, by having the known angles it should be possible with three.
Do this for as many sets of three sensors as is possible.
The idea would be to then fit those ellipses to their respective plane/ circle using cone/plane intersection algebra to give the position of the point of the cone.  The point of the cone for each set should be the same, and also be the origin of the lighthouse.
Thoughts?

Thinking about it some more, because lighthouse gives absolute angles, I think it should be possible to lock the position and orientation of the HMD wrt to the lighthouse with only two sets of three – and potentially without the cone/plane fitting…
As before, create two circles with two sets of three points getting: the centre of the circles, the points with angles and, the normal of the plane the circle sits on.  Calculate the distance between the centres of the circles.
Create the ellipses as before locating the centre of the ellipses and work out the normals of the associated circles from the ellipses (this will be the circle normal in the reference frame of the lighthouse).
Lock the HMD plane normals to those created by the ellipses – this should lock the HMD attitude in the lighthouse reference frame.
In theory it should now be possible to align the centres of the circles with the bearings given by the centre of the ellipses to give a distance from the lighthouse.
Talking rubbish?

I don't have a Vive, so I can't gather sample data through libsurvive.  But I do have a pair of lighthouses and a custom made target with 6 sensors.  Using it, I captured 15 sample data sets.  I've run about half of them through my code so far, and so far almost all look like they're converging nicely.  (There's one data set that is an outlier, and it looks like one of the sensor reads was skewed.)
The biggest drawbacks right now to the algorithm I'm using is that it eats up a lot of RAM and compute resources to generate point clouds for every torus and then iterating through the points and computing distances.  However, there's still a huge amount of potential to optimize it down.  Also, I'm not yet attempting any calculation of the orientation of the lighthouse.
I'd like to start cleaning this up and integrating it.  Where is the best place in the architecture of libsurvive to put lighthouse location detection?

I've been testing my code with data you've been sharing. It's not exact but that's because I'm not averaging nor applying any type of filtering to the points, I'm just using the first 4 points on every sweep and threat them as accurate. Surely there is a lot too improve, like developing an algorithm that grabs 4 random points of the HMD, process it and averages with any other 4 points. Or an algorithm that's able to distinguish points that are off directly (like any point that's too separated from all others can be excluded without any analysis), indirectly (like using the IMU to estimate the pose between sweeps) or analytically (like analyzing all poses from random points and determining which point is causing error, or using the normals with the average pose and determine which point is nonsense). By using my code and the data As-Is yields the following results.
By comparing my results to the measurements you gave, I get an accuracy of about 5-10 cm which I expected. My guess is that by manipulating the data with the methods I described earlier you can get closer to reality. The Euler angles are in degrees and the translation vectors are in meters, I'm not really sure which distance is XYZ and which angle is roll pitch and yaw because is taking the point 0, 0, 0 of the HMD as the origin (so it depends heavily on the angle) but my best guess is that it's YXZ. The RMS error you see is how close is the the pose reconstruction given the distance of each point, it's not a good way to measure the accuracy of each pose because its not considering the accuracy of the distance. I don't expect it will get any better than this.
I'm cleaning up my code to upload it asap. It's in python btw (sorry?).

I've been implementing the idea that I outlined above and, from what I can tell, it works well and is quite fast:
https://hackaday.io/project/14977-room-based-vr-positioning/log/52081-about-turn-the-mathematics-done

Here's the code I used, it solves the pose at about 130-150 Hz, there's a ton of room to improve.

@octavio2895 I have tried your code.  I'm not sure where your source data came from, but I tried using the data from issue #8 and, I'm getting much larger errors:
Translation Vector
[[ 0.30292643]
 [ 9.8524632 ]
 [ 7.24489426]]
Rotation Matrix
[[-0.89377251  0.44851961 -0.00092523]
 [ 0.25054407  0.49755022 -0.8304646 ]
 [-0.37201931 -0.74247824 -0.55707064]]
Euler Angles
-153.386804368<PHONE_NUMBER>58<PHONE_NUMBER>85
Distance [[ 12.23320434]]
RMSE: 0.0941585319627

It is definitely not 9,7 units of distance away!  Any way you can hop on discord today and we can work through it?
@LeeCookGHA - Will start reviewing your work now.

@mwturvey -- will be reviewing yours too.  I'll be in discord for the next bit, as well as later tonight.

@cnlohr were you using the data with watchmen? My code does not distinguish between hmd and watchmen at the moment, its an easy fix though.

I included WM0/1 in the data, you'll need to throw it out.  I think to get really good solutions you'll have to use more than the HMD, but that's just a guess.

I think we can finally put the nail in this issue's coffin.


Branch not being correctly identified when fetching tags since 4.0.19

Hello, since the release version 4.0.19 the following command which we use in a custom script is not returning the correct branches containing a tag:
git branch -r --contains tags/[tag]
This command returns the correct branches for Git Clone versions below and including 4.0.18. I noticed that since version 4.0.19, the git fetch tags command was changed as following:
4.0.18: git "fetch" "--tags"
4.0.19 and above: git "fetch" "--tags" "origin" "refs/heads/master"
These changes cause some tags not be identified to their correct branches. Attached are 2 logs for the same commit, one using 4.0.18 and the other using the latest version. This result specifically is what I'm interested in, which is only visible in version 4.0.18:

[new branch]      release/1.1.9              -> origin/release/1.1.9

Are there any workarounds to this change that can allow us to get the results as before?
4.0.21.pdf
4.0.18.pdf

Already found the correct way to adjust to these changes, don't think it's a Git Clone specific issue, therefore I'm closing this


can use 'xdg-open' instead of 'firefox' to open url (system::posix_open_url )?

On debian for Raspberry PI, there is no firefox by default.
system::posix_open_url can't open url (label).
I googled and found 'xdg-open' which can be used to open url by default browser.
Is there any reason not to implement it to nana?

ps: My implement. It works OK on Raspberry Pi Desktop and ubuntu
              auto path = "/usr/bin/xdg-open";
		if (stat(path, &exists) == 0 && S_ISREG(exists.st_mode)) {
			char name[] = "xdg-open";
			char *argv[3] = { name, const_cast<char *>(url_utf8), nullptr };
			pid_t pid = 0;
			posix_spawn(&pid, path, NULL, NULL, argv, environ);
			return;
		}

This feature will be shown in release of 1.7.4


update Friday schedule

We can also shorten the follow up CryoHub slot before the survey. Don't see a need for 30 mins there and 15 mins works fine

Also make @tsnow03 the main presenter of this session

Don't see a need for 30 mins there and 15 mins works fine

I suspect we'll start a little late, so figure it will work out. @aaarendt thoughts?


Support show loading when NFTCard request metadata and loading image

In NFTCard, Maybe Skeleton is better than loading ? Or maybe we can use both of them?

Good idea, Skeleton is better!~


Continuous Clearing Tool Version 7.0.0 release

CC tool Migrated from .NET 6.0 to .NET 8.0.
Publish Continuous clearing(CC) tool produced Logs and BOMs as artifacts in the pipeline by CC tool
Updated SBOM to Siemens standardized SBOM.
CC Tool application version info should be displayed in the CLI
Terminate the Continuous clearing tool execution when the SW360 project status is Closed
Releases to have the Relation field value as "Contained" from  "UNKNOWN" while linking to projects
NPM Releases not attaching the parent-child relationship correctly.

Some files missed

not required


Ability to add many blocks per route filter

@jeromegn pointed out to me in #105 that people might want to call many times before_x or after_x so I updated the filter, it no longer raises an exception if there's already one filter for this verb/path.
And now calls all the blocks in the order they were defined.
Also I'll make it clear in the docs but these convenience methods should not be used by plugins/addons, instead they should do all their work in their own middleware.
PS: this time I ran crystal tool format should look better than the previous PR :smile:

Very nice!

LGTM :+1:


include/rnd.h missing header guard

Missing header guard
Source root/include/rnd.h
1
/*

This header file should contain a header guard to prevent multiple inclusion (the macro _RNDUP is checked for, but is not defined).
2
 *      Copyright 1996, University Corporation for Atmospheric Research
3
 *      See netcdf/COPYRIGHT file for copying and redistribution conditions

I have fixed on my current branch, up as PR #755.


Changed root device detection to be more accurate. Added volume tag a…

…nd attachment data to snapshot tags.

:+1:


NETRON as a foundation for AI Plugins

How difficult would it be to give NETRON a plugin capability?
The ability to write plugins could open the door for things like AI Ethics (bias inspection), network surgery, and a slew of unimagined capabilities. It would open the door for many people to expand the domain of AI (democratise).
NETRON is the defacto standard viewer/explorer. It's ubiquitous just like Tensorflow or Pytorch. Can it be taken to the next level?

@JohnnyOpcode can you provide a specific scenario how this would work technically across desktop, browser and Python Server and submit a pull request.

@JohnnyOpcode can you provide a specific scenario how this would work technically across desktop, browser and Python Server and submit a pull request.

I will have to think about and study the Python issue (I was not aware of it quite frankly). For Desktop/Browser I was thinking some form of JS event hooking maybe?

@JohnnyOpcode @lutzroeder
I think if you want to start to modify the net structure, the Js itself is not sufficient. Most of the algo to do it, uses python librairies like onnx helpers or onnx surgeon.


Sample Deployment Problem

I am trying to write and debug a W10 UWP IOT Console application for a Raspberry Pi project. I've downloaded your AppModelSamples-master collection for guidance and successfully compiled the CsFindStr project. When I try and deploy it (by pressing "Remote Machine") the deployment starts,
gets as far as "Updating the Layout" but terminates with the error "This app does not support the contract specified or it is not installed".
All other projects (non Console) deploy without error.
The SDK was updated this morning, and the target machine is running W10 Version 10.0.17134.1
Any guidance gratefully accepted.
Les Wilkinson.

Did you ever find an answer to this issue?  I've been fighting it all day.


What do Pair, L, T stand for in the code?

Hi, I'm a beginner and would like to ask a question. What do Pair, L, T stand for in the code? What do they mean?
# Pair x L x T x 3 x H x W
video = np.zeros((len(s), self.max_frames, 1,
                  3, self.rawVideoExtractor.size, self.rawVideoExtractor.size), dtype=np.float)

As far as I understand:

Pair: number of samples (videos)
L: length of video in frames
T: time axis? It's always 1 rendering it practically unnecessary...
3: RGB channels
H: height
W: width

Happy to hear thoughts of other members who have been using this repo!

T is a scalar representing a set of frames extracted from the same one-second-interval. With an fps of 30, each group of 30 frames will share the same T value. I guess that this will play a role in the frame extraction strategy.

As far as I understand:

Pair: number of samples (videos)
L: length of video in frames
T: time axis? It's always 1 rendering it practically unnecessary...
3: RGB channels
H: height
W: width

Happy to hear thoughts of other members who have been using this repo!

thank you very much!


Added comparing field against another field

Allows queries to have fields (identifiers) on the RHS of where clause conditions

Hey, @aravinth2094! Sorry, I just saw this. This is a very good improvement, thank you for contributing!
May I ask you to just include the sql.go and sql_test.go content in your PR?
The README is autogenerated from the tests, so if you want to add content to the README you can just add tests.
Please note that you modified the go.mod as well.
With this small modification I'm happy to merge! Thanks again.

Hey @marianogappa, Very happy to contribute to such an amazing Go library!
This PR already contains the sql.go and sql_test.go files.
The changes in README file and go.mod file was a happy coincidence when I performed go test.
P.S. Please do let me know if I misunderstood your comment. 😃

Oh, I see. I just tried it and I get the same result. Sounds good then. Merging. Thank you!


Model missing files

Hello, thank you for your work! When I load the model for testing, I get the following error：
raise _format(EntryNotFoundError, message, response) from e
huggingface_hub.errors.EntryNotFoundError: 404 Client Error. (Request ID: Root=1-676aac74-63116c445599dc622d58bb37;d1928463-b738-4df7-8138-b392b0028209)
Entry Not Found for url: https://huggingface.co/cckevinn/SeeClick-mind2web/resolve/main/adapter_config.json.
During handling of the above exception, another exception occurred:
....
raise ValueError(f"Can't find '{CONFIG_NAME}' at '{pretrained_model_name_or_path}'")
ValueError: Can't find 'adapter_config.json' at 'cckevinn/SeeClick-mind2web'

Hi,
How did you load the model? It seems that you are trying to download something during loading. We recommend first download the checkpoint from hf and then load the model through your local directory.