Rename project with consistent rhythm namespace

[patcon]

Oren mentioned that a rename of the project was overdue: #109 (comment)

Ok, so doing a quick inventory.

• random note: website is http://www.rhythm.mit.edu/rhythm-badges/

Name	Proposed Name	Description	Status
openbadge	rhythm-badge	Main repo and badge hardware files.	✅
rhythm-rtc	---
rhythm-server	rhythm-server-js
openbadge-server	rhythm-server-py
openbadge-hub-py	rhythm-hub-py
openbadge-hub	rhythm-hub-mobile	Cordova mobile app. (aka RoundTable)
openbadge-analysis	rhythm-badge-analysis
openbadge-analysis-examples	rhythm-badge-analysis-examples
openbadge-analysis-test-badge	rhythm-badge-analysis-test-badge
openbadge-rfduino	rhythm-badge-rfduino		💤
rhythm-cradle	---
rhythm-landing-page	---
rhythm-meeting-mediator	---
rhythm-client	---
rhythm-dashboard	---

I've still got some other summary I'm hoping to do, like getting active/inactive status, and which prices work together, but curious to hear more about how the ecosystem works :)

Once we have this sorted, I'm happy to put together some PRs to get the name change finalized and ready to go

[OrenLederman]

Most of the current rhythm-* projects aren't mine, but i'll see if my colleague can change them. @dcalacci, what do you think? The names will make more sense if you use a more descriptive prefix for the online/web projects.

To maintain consistency, I prefer to have rhythm-badge-* for everything that is purely badge related. So:
openbadge-server -> rhythm-badge-server (no "py", since there's one server)
openbadge-hub-py -> rhythm-badge-hub-py
openbadge-hub -> rhythm-badge-hub-mobile

Note that the analysis package will be more difficult to change since it requires renaming the package itself and everything that points to that package (including many private analysis projects that I have). But it's doable. I'll try to allocate time for this sometimes soon.

[patcon]

Ok sound good! Thanks! Might you or someone else be able to sketch on a scrap of paper the relations between the projects above, and post that here? Unless I'm missing something, it's hard to understand how they relate (both over time with deprecation, and within rhythm ecosystem). The more detail on relationship, the better :)

[OrenLederman]

Fair enough (and I should update the readme..). You should be able to see some of it in this paper (might be behind a pay-wall) - https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8259434 In general, these are the main repos: openbadge <-> hub-py (or mobile) <-> server People wear the badges. When turned on , the badges only broadcast their id and wait to be activated by the system (by the hub). Once activated, they collect and store data locally until the a hub request it). A unique case of badge is a "beacon" - a badge we use only as a location beacon. These badges simply broadcast their id. You can use ibeacons instead, but this feature hasn't been tested that much, and not well documented. Also, when you use a badge as a beacon, the system will configure it for you, keep track of it's voltage, and make sure it's still active. The hub gets the list of badges (and beacons) from the server, and continuously look for badge and beacons. You can have multiple hubs (they synchronize their work via the server). The hub will do a scan, then connected to the badges it has been, one after the other. The hub will activate badges that haven't been activated yet (for example, after changing batteries), set their internal clock, and set the id and project id that they broadcast (an optimization for how we track proximity). The hub then request data from the badges, and store them locally. Every now and then, the hub sends the data to the server. The server contains the list of badges in each project, aggregates all the data collected, and provide monitoring for the system's health (especially with our new dashboard, yay!). Besides that, there is the analysis library. You can use it to read our JSON data format into python pandas, and then create the basic data structures we use for analysis. The pipeline for proximity data is much more mature and clean compared to the audio code. There are examples for how to use them in the examples repo (which is currently messy, but it's all there). Hope this helps.

…

On Wed, Nov 14, 2018 at 1:53 PM Patrick Connolly ***@***.***> wrote: Ok sound good! Thanks! Might you or someone else be able to sketch on a scrap of paper the relations between the projects above, and post that here? Unless I'm missing something, it's hard to understand how they relate (both over time with deprecation, and within rhythm ecosystem). The more detail on relationship, the better :) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#114 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAWUCR-ZU88q7yzx7QhLhgDP8-xDSYn_ks5uvGalgaJpZM4YdeF6> .

[patcon]

This is so unbelievably helpful! Thanks Oren. I might try to synthesize it into a Google Drawing file that we could render in the README overview repo