Skip to main content
SAGE
Search form
  • 00:01

    [MUSIC PLAYING]

  • 00:14

    DIANA KRIS NAVARRO: Hack New Yorkis a super close community.We all contribute to the whole entityof what is Hack New York.We all organize dinners and meetups with each other.So much goes into making the experience reallygood for hackers especially, because we care so muchabout people who put in their effort in one weekendto learn something new.

  • 00:35

    DIANA KRIS NAVARRO [continued]: Those are actually really, really cool.I have a great deal of respect for the hackersthat came in today because they literally took a weekendto just sit down, not get that much sleep,drink a lot of Soylent, and really--and code really hard for, like, 24 hours.

  • 00:51

    DOUG RUDOLPH: Something that isn'ttalked about a lot in technology is the hackathon culture.And hackathon culture is really importantbecause it teaches students how to build somethingoutside of the classroom.

  • 01:03

    CHRIS WIGGINS: And the mission nowis not as much as just discoveringtechnology, but thinking about the impact of technology.I think students are realizing in 2018how personal computing is.So 30 years ago when we said personal computing,we meant that you would have your own personal computer.But computing is personal.It's in the palm of your hand.

  • 01:23

    CHRIS WIGGINS [continued]: It's telling you about reality, and what to buy,and what's true, and who to meet.So I think students now really areaware of the impact on society and culture of technology.So that's one change over the last 10 years.It's gone from this is a cool APIto build on top of to what's the impact of this technology

  • 01:47

    CHRIS WIGGINS [continued]: and what can I do to impact people's lives.One thing you see at a hackathon, or a Hack NYHackathon, is when the fellows, the alumni come back and lead,they're also finding out what they themselvesare capable of-- not just as technologists, but as leaders.Let's go find people.

  • 02:07

    CHRIS WIGGINS [continued]: OK.Raghuraj.All right.What did you need help with?

  • 02:11

    RAGHURAJ: Yes, we all go to Rutgers,and we've known each other for a while.So we just rode the bus up together,and we were just talking.And that's how we came up with this idea.

  • 02:20

    DOUG RUDOLPH: Just out of context,can you guys explain your code real fastand what you're doing, just so I got a good understanding?

  • 02:28

    RAGHURAJ: If you put three devices in the roomwith Bluetooth, you could use the three locationsto locate where this device is in the room.

  • 02:42

    DOUG RUDOLPH: Oh, I see.

  • 02:43

    SAM: So we built a system for determining where a Bluetoothdevice would be in a room.We used a triangulation algorithm, I believe,in order to locate the phone in the room.So each one of these receivers were sending out waves.And basically, where they intersectis where the phone was located.

  • 03:05

    DOUG RUDOLPH: And then break it down.You have the Bluetooth--Bluetooth emitters on--

  • 03:10

    RAGHURAJ: So we either have three clientswhich have Bluetooth emitters.

  • 03:15

    DOUG RUDOLPH: And they're in the corner of each-- of the room?

  • 03:17

    RAGHURAJ: Yeah.So we put them in three corners.That's the spatial-- the space that we can--

  • 03:23

    DOUG RUDOLPH: So then you also have a serverthat you're trying to read from.

  • 03:26

    RAGHURAJ: Yeah.So with the server, that's going to be pulling from these three,and then calculating this information,and then displaying.So we don't want to do anything but just pull Bluetoothand send information.

  • 03:39

    DOUG RUDOLPH: OK, cool.So what do you need help with for the server?This is actually a really hard form of data collection.And so I think one thing to understand about data scienceis half of it is collecting.And I would honestly say the majority of data scienceis cleansing the data and making it accurate.And then the final part is actuallyanalyzing it and putting it onto a graph that people can see.

  • 04:02

    DOUG RUDOLPH [continued]: So what you can do with applying that data is the funpart of data science, but the hard partis really the collection.And so in their process, they're tryingto do real time data collection, whichmeans taking plots of points from Bluetooth dataand admitting it to a graph.And that server can luckily store key moments,like take a screenshot of when someone

  • 04:24

    DOUG RUDOLPH [continued]: was in a certain specific spot.And from that, what you can do isyou can store all that data in a database.And you can actually map where people went over a time series.

  • 04:33

    RAGHURAJ: OK.So how do you get three concurrent sourcesof information to stream into one server?

  • 04:43

    DOUG RUDOLPH: I see.

  • 04:44

    RAGHURAJ: At the same time.

  • 04:45

    DOUG RUDOLPH: In the--

  • 04:46

    RAGHURAJ: Without threading.

  • 04:48

    DOUG RUDOLPH: So--OK.That's actually not that bad.The problem they were trying to solvewas mapping people in real 2D, 3D space to a screen.And their approach to solving it wasby placing Bluetooth emitters in the corners of the room.And with those emitters, they were calculating how longit took for your phone to talk to all three

  • 05:10

    DOUG RUDOLPH [continued]: emitters in the room.And when you do that, you can calculate how farthey are just based on time.And what's really cool is once youhave how far they are in the room,you can map them to the screen.So I know-- so I'm assuming you guys are using Flask currently.

  • 05:28

    RAGHURAJ: We can use something else.

  • 05:29

    DOUG RUDOLPH: So yeah, I would actuallyrecommend a different tool.So what you guys are doing right nowis you guys are listening on one thread,and that's fine that you're listening on one thread.But the problem is that thread is blocking.What that means is when one device comes into that thread,the other two can not do anything.So there's something-- you can use something called

  • 05:50

    DOUG RUDOLPH [continued]: asynchronous development, which would just be--it's still one thread.But when it's listening for different devices,it can stop in the middle of listening at one momentand go to the next one.And it can do that repetitively--repeatedly around 20 or 30 times a second.So what you're getting is kind of like--it's kind of like threading where

  • 06:11

    DOUG RUDOLPH [continued]: you have a scheduler that will jump from thread to thread.But this really is just one thread,and it's just a state machine.And when you jump from one state--from one thread to another, it pauses the state in thread 1and starts from where it left off in thread 2.And then it can just do that for any given state.The problem they were running into

  • 06:32

    DOUG RUDOLPH [continued]: was that when they were reaching out to more than one device,they were being blocked by a specific set of threads.Generally when you have a server,the server is capable of listening to multiple requestscoming into that server.And because a server should be able to do that,their goal was to try to recreate that feature.But something that's annoying is actually,

  • 06:54

    DOUG RUDOLPH [continued]: that feature is not just built in.So for example, when you send a request to Google,there's actually probably about 5 billion peoplesending that request.So how do you distribute that?So their problem was that exact problem, but on a lower scale.And so even though they were tryingto solve that problem on a lower scale,it's the same type of method to actually fix it.What they were doing was they would just listen to one phone,

  • 07:15

    DOUG RUDOLPH [continued]: and when they were done, they'd takein another phone's request.But what they actually wanted to dowas, after they took the request from one device, pause,and then start seeking for the next device.And given maybe 1 millisecond, if they didn't hear anything,look for the next device.And this idea is called a non-blocking asynchronous

  • 07:35

    DOUG RUDOLPH [continued]: request.And the idea with that is that once youhave the state of one request, you canlook at the state of another.And essentially, you just run this loop reallyfast through the states of all these different requests.And once the requests are finished,you can then distribute back information to the phone.So it's this incoming set of requeststhat you have to handle, and it should

  • 07:57

    DOUG RUDOLPH [continued]: be able to handle any number of requests up to a given number.You can use node if you use node.

  • 08:03

    SAM: But no Javascript.

  • 08:04

    DOUG RUDOLPH: But you can also use--there's a Python framework called Tornado.

  • 08:07

    STUDENT: Oh, I've heard of that.OK.Yeah.We can learn that.

  • 08:09

    DOUG RUDOLPH: Yeah.I can show you guys--I use Tornado at work, actually.The way to break it down is you have the actual userinterface that the person sees, and then you have the server.So the user interface is going to berunning on its own thread on one machine.So when you see a demo, you're goingto see that thing live on stage.That thing has its own thread.

  • 08:31

    DOUG RUDOLPH [continued]: And you can think of a thread as a wayto have two things running at the same time.Really, a machine can only handle 10, 16 threads.So you have to think about it as one thread to draw on.You're down a thread now.You have, like, 15 left.So how do you manage those 15 threadsto take in 100 requests every couple seconds,

  • 08:52

    DOUG RUDOLPH [continued]: if not every second?So the way to do that is to have an asynchronous non-blockingloop.And what that means is you reallyonly need one other thread.And that one other thread is a state machine.When the Bluetooth emitter sends a request to the phone,that's one state.When it sends it back, that's another state.In between those two states, there

  • 09:12

    DOUG RUDOLPH [continued]: are subtle states in there in between.But the server-- you don't actually need to know that.The server is pretty capable of handling all those subtleties.So what's kind of nice is when you have those twostates going, you can have the phone handle it at one point,and then the server can handle it later.So what's nice is since there's this delta time,this small moment where the phone is keeping trackof what's going on and not the server,

  • 09:33

    DOUG RUDOLPH [continued]: the server can go, hey, let's pause hereand jump to the next phone.They've been trying to work on the Async framework.And so what's kind of nice, is youhave one way to handle multiple requests by quicklyjust iterating over in that brief period of timewhen a request gets sent from a server.And your math is good too?

  • 09:53

    STUDENT: Let's see.Oh, wait.Why is the body empty?Last night, Doug was really helpful.It's been a long time since I've done some of the maththat he'd done.

  • 10:02

    RAGHURAJ: I'm finishing the math,and then probably we'll end up building--So we were doing vector math, whichis very much along those lines.And I have no background there.So he helped in there, and then just general stuffwith networking and figuring out how to asynchronously managea distributed system of devices, which can be tough.

  • 10:26

    RAGHURAJ [continued]: And he's pretty experienced.

  • 10:28

    DOUG RUDOLPH: I think you guys got this under control.

  • 10:30

    RAGHURAJ: Yeah.

  • 10:30

    DOUG RUDOLPH: Yeah, OK.I'm going to head out, and check another group.

  • 10:33

    RAGHURAJ: All right.

  • 10:33

    DOUG RUDOLPH: I'll be back.

  • 10:34

    RAGHURAJ: Cool.

  • 10:43

    DOUG RUDOLPH: I'm holding B. Don't worry about that.Let's go.I think at the end of every hackathon,there's always a mad rush, especially because youdon't know what can go wrong.Do you need help?We had asked to put our devices up in advance,but one of the limitations of our hardware,and I guess in the building we're at,

  • 11:04

    DOUG RUDOLPH [continued]: is there's like very locked-down Wi-Fi networks.And we need the Wi-Fi in order to send all the data we collecton each individual machine to a centralized server, whichthen does analysis.

  • 11:16

    SAM: How are people over there--

  • 11:17

    RAGHURAJ: Yeah, so that's what this strip is for.So these are our Bluetooth receivers.So we're trying to put them up in three spots of the room,because our hack idea relies on having threepoints to triangulate a signal.So it's like a microcontroller that's pretty commonly usedin hacking.

  • 11:39

    RAGHURAJ [continued]: Hacking isn't making projects and things.

  • 11:42

    SAM: [INAUDIBLE]

  • 11:43

    RAGHURAJ: OK.B is this one.We actually don't need them.I'm sorry.It's fine.It's fine.It's fine.

  • 11:49

    SAM: The server is up?

  • 11:50

    RAGHURAJ: It's better that we don't.

  • 11:51

    SAM: The server is not up?That's fine.You did a good job.

  • 11:56

    RAGHURAJ: During our hack demonstration,could you hold up that sensor?

  • 12:00

    STUDENT: Which one?

  • 12:01

    RAGHURAJ: I'm show you.

  • 12:02

    STUDENT: Yeah, I'll hold it.

  • 12:03

    RAGHURAJ: Just don't-- yeah, don't stand in front of it.But that's perfect.That's exactly what I want you to do.Yes!

  • 12:15

    PRESENTER: Let's get started.We're going to start with Marauder's Map.

  • 12:22

    RAGHURAJ: Wouldn't it be interestingif you could locate yourself in a room using your Bluetooth?Everyone has their phone on them all the time.Every phone has Bluetooth on it.So we thought it would be interestingif we could try to locate ourselveswith our phone in a room.In order to accomplish this, we havethree devices placed in three separate parts of the room.Right there, you can see Doug is holding up one of them.

  • 12:44

    RAGHURAJ [continued]: So the way we're doing this is somethingcalled trilocation, which is--the same math is how earthquakes are found.So each one of those things is measuringmagnitude of signal strength of the Bluetooth deviceon his phone.This is a live demo, so it's a little scary.As he moves around, ideally, the coordinate

  • 13:05

    RAGHURAJ [continued]: should change if nothing crashed.[CHEERING AND APPLAUSE]And we call it Marauder's Map because it'slike the map in Harry Potter where you cansee where everyone is moving.[CHEERING AND APPLAUSE]

  • 13:21

    PROFESSOR: As an academic, I vaguely understood softwareengineering and startups.But you really learn a lot from talented students.Nobody is invested in the future like students.Students are really interested in finding outwhat the next five to 10 years are going to be like.So in a way, students are always telling you the future.

  • 13:43

    PROFESSOR [continued]: You just have to listen.So Hack NY for me has been great because students are constantlyteaching me what the next five years is going to bring--technological trends, sectors that are opening up,whole flavors of startups that are being formed,what languages are on the way out, what languages areon the way in, what open source machine learning tools

  • 14:07

    PROFESSOR [continued]: are most useful, what machine learning and data scienceopen source tools are on their way out.So for me as an educator, it's actuallybeen really useful to see these studentsrevealing to me the future.

  • 14:21

    PRESENTER: The next one we're going to announceis best hardware hack.Can I get a drumroll, please?[DRUMMING]Marauder's Map![CHEERING AND APPLAUSE]

  • 14:33

    STUDENT: This is your--this would be your fourth, right?

  • 14:36

    RAGHURAJ: Yeah, I'm guess I'm coming off a hot streak.But you never really know.It was really what resonates with judges.Some judges like to see really, really technical things,and sometimes they just want to see something that'smore fun and interactive.And I guess we went down a very technical route, whichmeant it was a lot harder for us to explore why this is useful.

  • 14:58

    RAGHURAJ [continued]: More it was like, this is a technologythat could be really cool.

  • 15:02

    DOUG RUDOLPH: So what's really interestingis hackathons essentially enable you to go out there and buildsomething that no one would ever think to build before.And this is really the first time we're seeing this.Because five, 10 years ago, these toolsjust weren't as accessible.The internet was just behind that point

  • 15:22

    DOUG RUDOLPH [continued]: where sharing these kind of things wasn't so hyperactive.And so now we're so far-- and honestly, we'reso far in the future, we're on the riseof all these different trends that we don't evenknow are going to be a part of our life.

Video Info

Publisher: SAGE Publications Ltd

Publication Year: 2019

Video Type:In Practice

Methods: Sensors, Internet of things, Spatial analysis, Big data analytics and tools

Keywords: algorithms; asynchronous communication; Bluetooth; coding; data collection; data management; digital technology; future considerations; hacking; looping; programming; programming and scripting languages; time management; triangulation; Wi-Fi ... Show More

Segment Info

Segment Num.: 1

Persons Discussed:

Events Discussed:

Keywords:

Abstract

Chris Wiggins, PhD, co-founder/co-organizer of HackNY and Associate Professor at Columbia University, provides insight, while Doug Rudolph, fellow/co-organizer of Hack NY, follows a 24-hour hackathon team designing a Bluetooth sensor system for location tracking.

Looks like you do not have access to this content.

24 Hours to Create a Bluetooth Sensor System for Location Tracking: hackNY Student Hackathon

Chris Wiggins, PhD, co-founder/co-organizer of HackNY and Associate Professor at Columbia University, provides insight, while Doug Rudolph, fellow/co-organizer of Hack NY, follows a 24-hour hackathon team designing a Bluetooth sensor system for location tracking.

Copy and paste the following HTML into your website