Note: ITAC meetings are digitally recorded for meeting minute generation; audio files for each topic are posted to an authentication-protected repository available on request to any ITAC member. Presenters are welcome to request to have their audio program excluded from the repository.

 

All times below include presentation and discussion time.

 

Agenda – September 27, 2018

 

4:00 – 4:05 – Announcements (5 minutes)

 

4:05 – 4:35 – Duke Ocean XPRIZE Finalists, Tyler Bletsch, Martin Brooke (20 minute presentation, 10 minute discussion)

 

What it is: The Shell Ocean Discovery XPRIZE is a global competition with a goal to advance the development of marine robotic technologies to access and illuminate the deep-sea like never before. Duke’s team is one of nine competing in the finals this fall, and will be tasked to autonomously map and image the seafloor at 4,000 meters beneath the sea surface. Team Blue Devil Ocean Engineering will outline their tools and methods for this ambitious contest.

 

Why it’s relevant: Team Blue Devil Ocean Engineering is one of just two university-based teams in the competition. Their approach combines drone technology, dedicated undergraduate courses, and engineering innovation – allowing them to apply breakthrough technology to pursue real-world challenges.

 

The Shell Ocean Discovery XPRIZE is a global competition to develop deep sea technologies for high resolution maps of the ocean down to 4000 meters depth. Shell has contributed 11 million dollars, 7 million of which goes to prizes. Duke has already received some of the prize money and could win around $4 million. Duke is one of eight finalists in the final round. Participating actually costs us money because of the travel and equipment. Duke is competing against teams who, even if they won the prize, would not offset the amount of money they’ve spent to compete. In comparison, Duke has spent about $200,000 including the $100,000 dollars received as a contest finalist. This covers travel to Greece for 48 students and equipment.

 

This is the second XPRIZE where Duke has competed. We received support from the Provost's office for a grant to teach design through global challenges which included this type of competition. We started working on this in 2013 on the "Wendy Schmidt Ocean Health XPRIZE" which offered a $2 million award for the finalist. We started with 7 students but now regularly teach classes with 40 or 50 students.

 

We are attempting to solve realistic and important problems that are compelling enough for Shell to contribute $4 million dollars towards the prize. The second place prize is $1 million. Participation is interdisciplinary with different components on which to work allowing students to gain technical knowledge and skill. Students work in teams with some traveling to Greece and others going to San Diego and Monterey. We did not go to Puerto Rico which was an XPRIZE test site but became a FEMA help location after Hurricane Maria hit the island. Hurricane dangers may have been why the final competition is in Greece.

 

The parameters of the competition are that XPRIZE participants map 500 square kilometers of ocean floor down to 4000 meters within 24 hours. It may be impossible to achieve all of these goals meaning the team that comes closest to achieving this could win. However, the XPRIZE organization had a lunar landing contest with $10 million in prize money and none of the teams came close to achieving that so there was not a winner. It is unknown if we or anyone will be able to accomplish enough to win the prize money. Our goals are to compete and turn in a map.

 

Our plan is to fly drones which drop ultrasound transmitters that ping to determine distance from the device to the ocean floor. This is theoretical but was enough to establish us as finalists in the contest. We have seven teams working this semester. The devices utilize a winch to lower sonar pods containing epoxy-protected circuit boards that are capable of withstanding the water pressure. These sonar pods are lowered to 4000 meters (equivalent to 400 atmospheres of pressure) so there can be no air bubbles in the epoxy or the device will crack.

 

We have developed heavy-lift drones that can handle a takeoff weight of 90 pounds. Our custom drone can reach speeds of 36 mph and fly at an altitude of 350 feet which is a requirement in order to map in the time frame allotted. The drone is made of carbon fiber and custom 3D printed parts allowing us to fix or rebuild anything that breaks during a crash. We built a second drone with an improved design to serve as a backup and will need five drones to be able to map all 500 square kilometers.

 

We are using hybrid engines for our drones which allows them to fly longer than five minutes. Otherwise, there is a problem of energy density and weight in relationship to the batteries (lithium polymer). We built our first hybrid engine because two years ago we could not buy one. The engine we built is supposed to generate about 5 to 6 kilowatts of power and 24 volts and has gotten very close to this. There is now a company in China that has started selling hybrid engines for drones which we used on our new redesigned drone utilizing two engines.

 

Our sonar pod is made up of three "arms" in a pyramid design. All the electronics of our sonar pod can be protected using epoxy at a low cost. We tested our sonar pod and winch in the Reclamation Pond by Gross Hall. The bottom of the pond is very murky and we weren't expecting much signal but we were able to send pings the bottom. We plan to test very soon in the deeper Falls Lake.

 

Once we have our system in the water, we need a recovery process which is a challenge. Another university still in the contest discussed collaborating with us but once they heard our design plan, they declined because they didn't believe the pod could be recovered. Of course, we are skeptical of their design because their device has to achieve speeds of 50 knots under water which is too fast for the sonar to work. We are both in the finals so it will be interesting to see which approach comes the closest to the goal. For our pod recovery, we worked with an artist in computational media who was tracking objects with artificial intelligence. We asked if he could do this with an "Nvidia TX2" and he found a solution. The artificial intelligence software running on the drone is able to locate the sonar pod and winch in the water. For the mechanical part of the recovery, the drone must grab the pod and fly away with it. We are utilizing a hook that slides into a funnel attachment on the top of the sonar pod which expands to lift it.

 

We must generate a 3D bathymetry map of the ocean floor and we have two approaches. The first starts with a map that we modify using interpolation between the points which we adjust using neural nets and deep learning from the data we gather. We have 48 hours to generate our map and depending on the data we get, this could be enough time. If we have a lot of data, this isn't enough time. Duke Research Computing is helping us using 36 core gigabytes of RAM machines on which we can run our calculations. Data+ provided students. Because the neural net approach is always generating a map, we may get close enough to win the $4 million prize. The other approach is synthetic aperture sonar which is more common. We have issues with this in that our data is vertical rather than horizontal. For example, boat fishing sonar is horizontal so that as you move along the aperture is bigger than the device you use. We found open-source code developed in the 1950s that did synthetic aperture sonar before "going dark". This is because this technology could be used for submarine detection, so nothing is published. We have to take special precautions in that our equipment cannot stay in Greece and we must secure it due to the sensitive nature. When we get the data from our test at Falls Lake, we can start analysis and test the code but there is no guarantee we end up with a map.

 

We have six parallel paths on our project plan, four of which are on the critical path. We also have budget management and are dealing with expenditures which include shipping of all the equipment and arranging travel to Greece. We are staying on schedule and the receipt of partial prize money has helped tremendously. We are now planning for November in Greece where we will make our mapping attempt.

 

Q: Can you put the contest parameters in context? How large is 500 square kilometers? And what resolution?

A: One side of the area is 22 kilometers. Most of the deep ocean has been mapped to about a kilometer resolution using gravity satellites and very little has been done any other way because ships must drop devices. This becomes difficult at greater depths which is why Shell is interested in alternatives to get better resolution maps.

 

Q: On your drone, are the blades counter rotating?

A: Yes. This allows our drone to fly in different directions. Blade rotation is how it turns.

 

Q: Why did you use a triangular design for your floating device instead of a ring?

A: We believe this design is more stable. We've done the math and believe it won't tip over. Most of the weight is in the middle of the triangle and it takes a lot of pressure for it to capsize. We also wanted to use carbon fiber rods and 3D printed parts so when something breaks, we can easily fix it.

 

Q: Is there one drone for every device in the water?

A: Our final proposal was 10 sonar pods and five drones. However, we don't have the money for this so we plan to take two pods and two drones and map what we can. But to actually map 500 square kilometers, you need five drones and 10 pods (of course, with cooperative weather).

 

Q: For the Falls Lake testing, what exactly are you going to be doing?

A: We are not using a drone. We are submerging the replica of the pod that is not encased in epoxy to see how successful the equipment is at pinging the floor of the lake. We are going to drop some solid objects to the bottom since mud is notoriously non-reflective and try to get data for the signal processing team to analyze. This team has been using simulated sonar and we hope to present them with real data. If this works, then we will go out to the Duke Marine Lab and repeat our testing on the open water. We have one week during the XPRIZE mapping event and have been advised to set up quickly but wait for good weather. We believe our equipment can handle some waves, particularly slow rolling ones. Breaking waves may be too much for our equipment. If there are breaking waves, we won't compete (we don't want to lose our equipment).

 

Q: How have you been managing the different groups that have been engaged in this project?

A: We have a terabyte of storage and are documenting everything. As a new group starts, we tell them where the documentation has left off so they can continue working. We've noticed that each new group has been able to be productive more quickly (even within the first week starting the class).

 

Q: Is there anything you wish the Co-Lab had that would have made it easier for this project?

A: From the student point of view, the 3D printer success rate has been a factor. Supplies run low and some components take time to print. More printers would be helpful. When we are printing up a new drone, we have 20 to 30 students submitting jobs. Also, if there were more people on staff to maintain and monitor the printers, the success rate would be improved. We did try using more expensive 3D printing options but didn't feel this was fiscally responsible since the parts we print can break (and we do break a lot of them).

 

Q: How would you characterize your failure rate when it comes to 3D printing?

A: it depends on how trained the student is. Once they know what they're doing, we estimate there is a 30% failure rate. The parts being printed can be large which increases the chance for problems.

 

Q: How do the XPRIZE contest organizers know you've been successful and that your map is accurate?

A: The contest area is in a secret location that has already been mapped. That is why the project had an $11 million cost but $7 million in prizes. Part of that money went to the mapping. They may have used a giant ship for about a month to map the area and what they are hoping to replace since this process is so expensive. After the contest, we should receive the real maps so we can continue to work on our data.

 

Q: How is the computation happening?

A: We are doing almost every kind of computation you can imagine using a variety of devices from Arduino calculations to long-range radio communication to Raspberry Pi and laptop computers. We are also using Research Toolkits and Research Computing virtual machines for single node computation and if necessary, we could utilize Amazon Web Services.

 

4:35 – 5:05 – Innovation Co-Lab Roots Program, Michael Faber, Maria Liberovsky (20 minute presentation, 10 minute discussion)

 

What it is: The Innovation Co-Lab organizes short workshops to introduce the Duke community to technical topics. This presentation will discuss the program, classes that have been offered, feedback from the Duke community, and ways the program will improve in the new school year.

 

Why it’s relevant: As technology skills become more prevalent and relevant in nearly every professional field, it's important to keep the skills of our community on the cutting edge. The Innovation Co-Lab will talk about how the Roots program continues to help our community jumpstart their technical knowledge.

 

The Roots program is a technical training program open to Duke students, faculty, and staff. During the 2017-2018 school year, we offered 72 classes (29 in the fall and 43 in the spring). A few classes are held over multiple sessions, but the vast majority of our classes are single session. We find single sessions seems to be more popular. We survey after the end of each class to ask people how they felt about the class, ways we could improve the program, and other topics they would like to see. We also did an end-of-the-year survey to gauge feedback from our attendees on the program itself. We learned those who did not take Roots classes indicated it was because the topic at didn't match their learning goals. We also tried to determine how many Roots classes people attended. Fifty percent of the respondents took only one class with the rest of the respondents taking two or more classes.

 

Respondents didn't take more Roots classes because they lacked available time and others indicated class times were a factor. Based on this feedback, we provided more class times to accommodate a variety of schedules. Other respondents indicated the topics were a factor, so we tried to offer more types of classes. However, when we asked the question "When should we have classes?", we learned there was no consensus. Most spring semester classes were held in the 4:00-6:00 time range, but we continue to expand our schedule.

 

Respondents indicated of the types of classes they would like to see on the schedule that data science was very popular as well as Python, SQL, machine learning, and Docker. We are trying to respond accordingly. We noticed that 3D modeling and printing was in high demand, so we scheduled three classes this semester which were fully booked with waitlists. We are starting to offer classes for the high-end printers.

 

Our traditional class format is taught "in-person" with a length of two hours. We have some classes that are multi-day, but the problem with these are attrition. People attend the first session but often don't come back, so we are trying to find a solution. We offered some hour-long classes this semester including a session on Docker. This was well attended with good responses, so we are trying to find other topics that could fit this model while still making sure the attendees get something from the class. We offer a couple of online classes and are looking to expand.

 

Survey respondents asked for classes series that build skills but the problem is attrition and we have had discussed how to get people to stick with the class. Do we need to offer some kind of certification or credit for classes? We also get requests for more advanced topics and are expanding the offerings. We are also looking at flipped classes on multiple non-adjacent days. We did offer a class on sewing using sewing machines which was well attended at the Rubinstein building in a partnership with the DukeCreate program on campus.

 

During the summer, the Roots program offered a Doctoral Academy class which included five classes in an extended version of a track. For example, a web development track included HTML, CSS, and JavaScript. This was a fifteen hour course conducted over one week. The instructor liked having the same students which allowed her to learn about their needs and provide specific help. She could modify the content depending on the needs of the class. When the course was completed, the students were surveyed asking which topics were more difficult, which were easiest, and what should be added such as data science, data manipulation, and mobile development. The survey results allowed the instructor to plan for future classes and improve the difficult topics like GIT.

 

This semester we have 66 classes scheduled with more being added and it is very likely we will exceed in one semester what we offered in an entire school year last year. We also have more partnerships than before. We've had an ongoing relationship with Research Computing but also now partner with DukeCreate, Lilly Library, the Smart Home, and HackDuke. We have a greater reach across the university and can cross-post classes, resulting in much higher attendance than our classes last year. We also have more groups coming to us asking for personalized instruction. We have added a lot of new topics this semester in addition to our standard offerings such as web development fundamentals, data science, and Python. We introduced "Research and Medical 3D Printing" and all of the classes has been well attended and at capacity. We continue to talk about the Internet of Things, containerization, and many more. Most of our sessions have been in the Technology Engagement Center (TEC) but we have held a few sessions at the Rubinstein building as well as Lilly Library and at the Smart Home. This helps us reach as many audiences as possible.

 

There are several opportunities ahead of us. We are hoping to partner with other university departments who have asked about students and tailored classes (these would be prerequisites for classes or level-ups). The level-ups are especially beneficial for the new master’s in data science program. These university departments may be providing us with teaching assistants to help us meet their needs, especially for large groups of students. We have tried to organize some of our classes into tracks, grouping them by subject matter (most prevalent with the web fundamentals). We hope this will encourage our users to come back for other classes. We are also looking for connections with our instructors in order to provide a more cohesive curriculum. Another possibility is summer and immersive programming as part of the Roots program. We have that as part of the Doctoral Academy and Project Edge but there has been demand for more.

 

Q: Do you see partnerships with Duke clubs in the Roots program?

A: Yes. For example, we did a collaboration with the Duke Smart Home. We will also have a staff-taught "drones" class. We are always open to partnerships.

I would also recommend reaching out to the Library Data Visualization Services Group. They do fantastic data science courses on a regular basis. The cross pollination between the two audiences would be fantastic.

There are a lot of organizations that do training like this, not just the Co-Lab. We try to be careful not to duplicate efforts. The other organizations have done a lot in Python, R, GIS, etc. So we have not covered those topics quite as deeply but we still want to do the basic information.

Perhaps cross listing for discoverability might be a possibility.

 

Q: Who are attending most? Grad students? Staff?

A: It depends. For example, the GIT session is run four times a year, two times a semester. Last semester, the audience was primarily undergraduate but this semester it was almost all graduate students and staff. There also may be unknown factors affecting attendance. For example, the first-year design class learned about our advanced 3D printing session and took up all the slots which meant this was all first-year students attending an advanced medical 3D printing class. It depends upon how the information is passed around in a community. We also get questions from new instructors asking who they can expect to see attending and this is not something we can tell them. Even on the day of the class, people drop out and others sign up. This makes it difficult to plan for the audience.

 

Q: How often do you have people who are not affiliated with Duke try to sign up for classes?

A: It does not happen very often. Either those outside of Duke don't know about the Roots program or believe they are not eligible to register. However, it can happen. For example, a registrant may bring along a guest from another school. As long as there is space, the guest can attend.

 

Q: So those outside of Duke cannot register?

A: That is correct. You must have an active Duke account to register.

 

Q: Would we be able to help devise or describe a curriculum reflecting an overview of computer literacy topics like data analytics, security, Internet of Things devices, etc.? The target audience would be someone who "doesn't know what they don't know". How do you exist in the world today unless you know at least a tiny bit about those topics in terms of the digital society we live in? Perhaps this could be a "technology management" or "technology literacy" program.

 

Discussion:

When I think about the needs for educating graduate students, I expect a lot of computer literacy from them. They need to know Python. They need to know GIT. They need to know something about data analysis. Your program offers something that could be scaled up. If we as faculty knew that two or three times a semester there is a GIT or Python course that the grad students could attend, then I think you could advertise these more broadly to the faculty and graduate students as a resource in order to meet minimum skill levels necessary to function in a research environment.

I would agree with this whether it is an email to faculty or a printed catalog where we can mark the ones of interest. We tend to forget the Roots program as a resource.

We have tried to do this over the years, especially for faculty that we know are friendly to the Roots program. We would love to do this more efficiently but are not sure of a good way to do this other than reach out to department chairs.

The Office of Graduate Studies maybe a better solution. We are always trying to get graduate students to learn GIT or Docker. Some are able to pick this up using web tutorials on their own while others benefit from a classroom.

Even with web tutorials, you may have to listen to something multiple times in order to comprehend the material. That said, we do offer GIT as an online course.

I could really see a selection of core skills including GIT, Python, Docker, and scheduling systems such as Condor that together would make a great curriculum for computer literacy for scientific computing and advertise it that way.

 

Q: Do you have a UNIX fundamentals class? This is a required skill for a few of my classes. You could make this something that is due the first week.

A: This is the beauty of having some of these classes online. We don't have the resources for an in-person course (more than 20 in attendance becomes an issue). If there are topics that are useful to turn into an online course, this is area in which we are really interested. Our line in the sand is "If this is something that is unique or that is Duke-focused, we want to make an online course for it". If the content is not Duke-focused, there is probably something out there on the Internet. For example, a general Python usage class would not be useful because there are so many already out there. But if there was one with a particular set of skills related to Duke or something like Docker or VCM or GIT@Duke, those are attractive as potential online courses. We could get feedback on what should be prioritized as it relates to graduate students or classes.

But for those other courses where you say there are so many of them, sometimes the problem is some are great and some are terrible. You could recommend what are the best possible Python classes online as it relates to the time available to commit. This would be very valuable.

This is something we are working on right now.

 

5:05 – 5:30 – Web Application Security, Jesse Bowling (15 minute presentation, 10 minute discussion)

 

What it is: Web security continues to be an area of increased focus for OIT. Jesse will discuss the state of web security, what Duke University’s approach to web security looks like in terms of processes and tools, and some of the challenges and successes we’ve had in the space.

 

Why it’s relevant: As the number of web applications at Duke grows, the number of ways these applications can be exploited also grows – demanding additional, innovative resources and methods to stay one step ahead and address these vulnerabilities.

 

Website, web app, web service, and CMS are different terms for the same thing. A website used to be straight HTML displaying static content with links to other things. A web app was very dynamic content served over HTTP with the content changing using CSS or JavaScript or other technologies. A web service would also be served over HTTP but it was focused on data and was not really meant for people to view in a web browser. A CMS or content management system was a web app that was focused on making it easier for people to share content in a dynamic fashion. Not everyone wanted to write a webpage with a blog and a news section and a forum, so a CMS made this easier. Websites could also be in unusual places like a printer or a phone.

 

When we use an operating system, we expect to get regular updates to keep the system secure. These updates usually show up automatically with security and bug fixes. This is also true for native applications such as Microsoft Office which regularly applies updates to the suite of applications. But when it comes to web applications, this is a different problem. As you introduce customization, the web applications become more complicated to update.

 

Web application security is hard because coding is hard. If you don't have a web application vendor or support group, you have to maintain the web application security yourself. CMS  (content management systems) are web applications that if not updated regularly will have vulnerabilities. This includes plug-ins and themes that expand functionality. The update cycle with content management systems is not as mature as with an operating system.  There are also poor vendor practices that once integrated, make it difficult to update because the app functionality would break. WordPress and Drupal are popular and are targets when a vulnerability is known. A few years ago, an exploit in Drupal became known and within six hours there was massive scanning of the Internet to take advantage of it and install attacker code.

 

One of the most important questions a website owner must address is "How long would it take to recover my site in the case of an incident?" When a website is compromised, a new file may be written into the filesystem and this can be identified. But with a content management system, the vulnerability is stored in the database and requires a specialized skill to locate it. Even then, this is time-consuming and could take days. Can the website to be down that long? There are ways you can architect your website to recover more quickly such as keeping your content separate from your code. This is a relatively new process and not the way things have been done traditionally.

 

Q: Is there a hosted WordPress site at Duke?

A: Yes. Sites@Duke (sites.duke.edu). They now have the ability to host custom domains.