Hi, I'm Dr. Phil Percanti, I'm the Director of the Army Research Laboratory and welcome to ARL, What We Learned Today, a podcast where we talk with Army scientists and engineers about the science and technology that will modernize the United States Army and make our soldiers stronger and safer. Today we're going to talk with Phil Osteen, a roboticist in our Vehicle Technology Directorate who is researching how robots adapt to adverse environments. Phil, welcome to the podcast. And before we start, I would like to say that Phil is a roboticist, not a robot. That's correct. Now I'm not a robot. That is a fact. Well done. So Phil, tell me a little bit about yourself. How long have you been at ARL? Well, I started as a contractor in 2009 and I got brought on board as a civilian a few years ago. I went to the University of Florida and I got my master's in mechanical engineering and I was very fortunate because I wasn't quite sure exactly what I was going to do but I just so happened to be finishing up my undergrad when around the time when the DARPA Urban Challenge hit and somebody kind of TA who I owe a lot to, Steve, thank you Steve, he said come join this team. There's this urban challenge happening and I didn't quite know what that was but it was perfect timing for me and from the moment that he said we're going to be working on robots and really interesting problems I was hooked. So you were in Gainesville? I was in Gainesville, Florida, that's right. So what's the difference between living in Gainesville and living in Aberdeen? I actually live in Baltimore in the city in Kansas. Oh, Kansas, nice. It's a heart of city. I love it. I love it there. It's walkable to all kinds of things. The difference between Gainesville and Kenton, it's night and day. Gainesville's college town and that's it. I mean, there's not all that much industry there although I think that there's room for growth of startups and things like that because we do have very good engineering departments. But living in the city is just a whole different thing. There's good and bad, but I really do enjoy the city. So my wife and I moved, we just moved south of Baltimore. We lived in Severn, Maryland. But we lived in Virginia, northern Virginia for a long time, probably longer than you've been alive. And we went to Kenton and we were like, oh man, this is a nice little part of town. Yeah, I love it. What's the best place to eat in Kenton? We're off topic, but that's okay. I want to know what the best place to eat in Kenton is. I mean, most people would say momers on the half-shell, they have just phenomenal oysters. If you like oysters, and that's a very divisive issue, I think, then that's a great place to eat. But there's new places cropping up all the time that I think are amazing. But my favorite was one that was right across the street from me called the Yellow Dog, but unfortunately it is no longer with us. I'll check out some oysters there. Yeah. Oh, so what are you working on? So I think that my high-level goals are the same as many people in DoD. I want to get intelligent robotic systems in the field as soon as possible, because soldier is the most dangerous profession on earth, and I think it's our responsibility to try to think of ways to make that job a little bit safer. And I think that putting autonomous systems in certain situations that are otherwise very dangerous instead of a soldier is a great way to make their job safer. Right, so move soldiers out of harm's way with a robotic platform. Right. So what does that mean, though, right? So if I put an autonomous platform on the battlefield, somebody has to control it. Well, so that's the trick, is that I think that the battlefield is such a chaotic and uncontrolled environment that the robotic systems have to be able to make some decisions on their own, right? Because you don't necessarily want to consume another soldier's attention completely by just tele-operating a robot. And even if you were okay with that, you can only do so much from a remote location completely and control a robot. So the trick is to get the robot to actually make some of these decisions for itself. So what are the big open questions that you're working on? So specifically, I'm interested in how the robot sees and understands its environment, in particular when things go south, right, which they will in the battlefield. And what happens is sensor data when either a sensor malfunctions or the environment doesn't support the use of a sensor, for example. I give an analogy that if you have a soldier that's doing a room clearing or a building clearing operation, that could be a dangerous mission, right? Because you don't know what's around the corner and there could be an ambush or there could be some kind of threat, right? So in order for a robotic system to do that, it would need to be able to make decisions on the fly that a soldier would. So for example, if the lights go out suddenly, does a soldier just sit around and do nothing? No, they're going to use whatever sensors are available to them to regain situational awareness. That could be trying to feel their way through the room, hopefully not. Hopefully they have night vision goggles, they could put those on. And in any case, the soldier is adapting to the environment on the ground and using whatever sensors that it has to regain situational awareness. So is there a specific set of questions that you're working on? Right. Yeah, I think there's three things that I'm most interested in from the dealing with adversity point of view for sensing and perception. One is what happens when effectively a sensor just completely malfunctions? You know, we don't want that single point of failure in your autonomy packages. And I think in a lot of cases, even today, that if that situation arose and the lights went out and the robot was relying on its camera too much, that it might not be able to perform its mission. I've often thought that the easiest way to mess up a robot on the battlefield was to give a bunch of kids peanut butter. That's exactly right. Just have them go up to the optics and rub some peanut butter all over the optics. So that's actually one of the things I'm interested in as well, not giving kids peanut butter, but that's exactly the right idea. Well, you could take it too. I kind of think of it from a funny point of view. Just a picture of a bunch of kids running out to stop a robot with peanut butter. But there are other ways you could do it as well. Any kind of oil or grease or even dirt, anything that gets on an optic or a lens can really foul up an autonomous system. And so outside of just a room clearing at the front line of battle, let's say you had a robot that's doing a patrol. And it's just sort of on a normal mission, there's not any active conflict, but it's interacting with people. If you look at the news right now, there's plenty of stories of people, researchers putting robots amongst people, and the robots are completely benign. They're doing mall security or they're trying to hitchhike their way across the U.S. And they don't make it. Because people don't have, it's psychologically a different, it's not as ethically dubious to mess with. Exactly, they kind of like the ability to mess with it. Part of it is just testing to see how good this thing really is. How good are you really, let's just say you put the lens cap on the camera. What happens then? So I think that even outside of the front lines of battle, you're going to have to deal with people, and they're not necessarily enemy combatants. They're just kids, being kids, right? So are you on the sensor side or on the perception side? That's a good question. I would say that I'm on the perception side. I take whatever sensors that I can get my hands on and try to make the most sense of the environment. And I do work with people on sensors. Directorate as well, though. So do you think that we will ever get away from using laser radars? That's an interesting question. It's actually in the news lately, because I think that Elon Musk is saying things like, they're not useful, for example, right? That's because he's trying to sell a low-cost RF solution. I completely agree with you. But from our perspective? Well, I mean the problem from our perspective is that they're active, right? So they produce a signature. I'm more of the opinion that I, like I said, I want to get these things in the field as fast as possible. And if that means using lasers, then that's okay for now, right? But we do need to try to get away from them if we can. But I mean, look, Mother Nature gives us inspiration. We have two eyes and we're able to, we don't need laser beams shooting out of our heads to see the environment. That's true.  We have an amazing big brain. Several billion years of evolution. Right? So the implication that, oh, it's no big deal, you know, in the next three, five years we won't need laser rangefinders is also, I think, implicitly assuming that we're just going to solve the intelligence problem fundamentally. The AI problem. But also, you know, there's also bats do use, not lasers, but they use echolocation. They use things like that. They're emitting, they're doing time of light principles, which are the same things that we work with with laser rangefinders. So I think it's perfectly plausible that, you know, people also don't have eyes in the back of our heads, but why wouldn't we want to put cameras behind, you know, to see all around the robot? Right. So tell me, what's your specific project? It's called adaptive multimodal fusion. That's the one that we're talking about now. I'm on a few different projects. I'm involved in the robotics collaborative technology alliance as well. We have some previous work in multi-sensor calibration. I mean, one very practical challenge of getting these robots to work and autonomy stacks to work is that they need to use a lot of different types of sensors. They need to use cameras and they need to use laser rangefinders, as we said, inertial units, all kinds of other things. It's one of these garbage in, garbage out principles that you need to have good input to these autonomy algorithms in order to get the best performance. And one way to get the best input is to understand where the sensors are with respect to each other, and that's, we call it a calibration problem. So I've worked on multi-sensor calibration in the past, and I'm continuing to work on that and transitioning it to GVSC. GVSC is... The Ground Vehicle Systems Center. It's formerly known as TARDAC. Formally known as TARDAC. Drinking Automotive Research Development Engineering Center. That's right. That's what everybody knows. So they're frequently a transition partner. I mean, the end user of our research at the end of the day is the soldier, but to get it to the soldier we need to sort of robustify some of our algorithms at the basic research level. GVSC is often our partner in particular. Right. Well, I'm interested to learn a little more about what you say, because, well, much of what you've talked about has to do with resilience. Right. Particularly with sensors. If you look at commercial cameras that are in cell phones, which would probably be the cheapest kind of a sensor you could put on a robot, but they're very susceptible to changes in the environment. Yep. Nighttime, daytime, shadows, cloud conditions. Bright sun. Right. So is that part of what you're working on? Yes, it is. I mean, I, first off, I think that we're going to have different levels of quality of sensor on our different platforms, because there's going to be a lot of different types of platforms. Some can't necessarily support due to size, weight, and power constraints, the type of computation that you might hope for, or the best possible sensors, because they weigh too much, simply because they weigh too much. But I think that it's incumbent upon the other sensors to try, that every sensor has strengths and weaknesses, and we have to try to leverage the strengths and use certain sensors according to the context to determine this other sensor might not be reliable right now. And the trick is that you have to do it on the fly. That's the real hard research challenge. Right. Is to determine that a sensor's data is of lower quality, suddenly, for some reason, and then adapt accordingly. Very good. Are you, so much of what you're doing is part of the essential research program? That's right. Different activity. The AI. AI for maneuver and mobility. That's right. AI-MM. And you're on the mobility side, for sure. Right. Vehicle Technology Directorate. That's right. Right. Are you on Spassuti Island? That's right. I work on the island. Okay. Talk a little bit about Spassuti Island. Spassuti Island is, when I first got here, I thought it was just some kind of magical place, because you're going to work on the island, which is part of the Aberdeen Proving Ground, just so everybody knows. Right. It's on Aberdeen Proving Ground. And the first time I was driven out to work, I was actually blown away. It's kind of like working on a nature preserve. I mean, every single day, I'm treated to osprey with fish in their talons and all kinds of things that are moving around, all kinds of animals. At night, it's a little bit dicey, because you don't know what animals are out there. But it's a really great location, I think, to perform some experiments, because there's really not that much traffic going through this area. So what kind of ranges, we have outdoor ranges and indoor laboratories on the island? That's right. On the island? Right. I work in a group of buildings that are sort of clustered together. They're large. And some have indoor motion capture systems, for example, just to get ground truth for aerial vehicles and ground vehicles. But we also have an outdoor flight field right outside of the building. So I mean, the value added for being able to just walk outside and test your algorithms on a platform right outside your back doors is high. And we also have a small loop that's paved, so we can test some on-road, off-road, ground vehicle navigation. Excellent. Well, I want to ask you, because you kind of hinted at it, but I want to be a little more specific with a question regarding the research that the Army Research Laboratory does in autonomy and robots, and what's going on in the private sector and in the academic community, and how do we differentiate the need for what we're doing versus what's happening in those other places, how do we differentiate, and then how do we collaborate? Right. I think that's a great question. First off, I think that there's no doubt that there's many different companies, large companies that are racing to win the battle to build the driverless car. And they see it as a trillion-dollar industry. And so there's autonomy that goes into that. And some of the algorithms are algorithms that we use as well. Right. But I mean, imagine a driverless car that's driving and suddenly it loses GPS and then suddenly it loses its map, which it's got this really fine-grained survey of the environment. And then for good measure, throw a camera. Like, the camera just doesn't work. And these things are actually going to happen because there's a famous story from when Google was scaling up. Right. They had this search algorithm and it was working great. And then suddenly they scaled to some size at which it stopped working. They couldn't figure out what it was. And what really happened was that memory corruption or service failing is a very low probability event. But when you scale to the level that Google is starting to scale to, suddenly it becomes a likely event over the course of all your servers. And that's going to happen with driverless cars and with, as we scale in DoD, the number of systems that we bring into the field, sensors will just fail, for example. And so my point is that they have assumptions about their environment that we can't make. And so we're working on the problem ahead of time because we assume that the battlefield is going to be chaotic and that things will go poorly at times. Whereas in general, still, right now, all the driverless vehicle technology that I know of is working in relatively controlled environments. Well, I hear you. Yeah. I don't want to put you on the spot on the podcast. However, there's a burning question that I have with all of this because if you've ever driven in Boston coming out of Logan and you get into that tunnel system, right? I stayed there a week ago. So you get into that tunnel system and you're trying to use a GPS-based map. It's a mess. It's chaos. You get lost at every turn. It's chaos. So I think it becomes a liability question for the private sector and the commercial business to have a driverless car that can't survive in an environment like that. I agree. There's a very specific question of what happens to these cars when you lose GPS, when the map goes south, right? They're going to have to deal with that same question at some level. I agree. I think that they also recognize this, but I don't know... I'm not sure what they're doing in their internal R&D labs necessarily. That's something that we should, you know, learn more about, right? But I suspect that they're trying to get the autonomy working as well as they can in their pristine environments first and then trying to move maybe to more challenge, let's say GPS is out. But that doesn't necessarily account for all the other sensors that could fail as well. Right. And so, again, our environment, the battlefield, we don't have the luxury of saying, well, we can kind of use it in the really pristine environments. You know, things will go wrong. I think also they will always have a map. That's right. And you might be in an environment in a military scenario where no map in the world... We had a map. Right. So you're starting in a chaotic environment, right? The map has changed suddenly. Right. So in that sense, I think, you know, that's a real differentiator. Right. And the research that you're doing is really out in front of what's happening in the private sector. Even though there's so much investment in that space, I think ARL has been able to carve a niche for itself. Right. And the Army in general, everyone associated with this kind of work in the Army, has carved a niche because we've sort of hit on the important problem and you've hit on what the real open questions are. So I'm really excited that your community in particular has gotten to that point. Yeah. Because it's always a challenge. We get asked this question all the time. Right. And I think for someone like you who's, you know, kind of new to the Army, new to the field, you're going to get these kinds of questions from the people that are making decisions about where to resource, you know, scientific endeavors, right? Exactly. So it's important for us to be able to say, here's why it's different. Right. And here's why you have to do it. Right. I mean, I think commercial will have to do it at some point, as I said, but I don't think that they're thinking about it as early as we are. Very good. Well, it's always a pleasure to talk to another Phil. Phil's have to stick together. That's right. There's only so many good ones out there, right? There's only so many Phil's, period. What else do you want to talk about? Well, I just got back actually from Boston, and I was in a meeting and it had to, it's from the autonomy community of interest, which is cross-service. All the different services under DOD are trying to focus and address the most difficult problems in autonomy. And in this particular case, the focus was how to engage academia and industry when there might be some reservations about working with, working on DOD applications, which it's come up in the news lately. And I think that the message that I agree with that they were trying to spread is that we have to address these concerns. We have to at least have a dialogue, and we have to maybe not come to consensus, but achieve some version of mutual understanding so that people in industry have an idea of what our problem set is and what our solution approaches are, right? And we have an understanding from their perspective of what the ethical and legal and moral questions are that we need to think about, right? We can't avoid that conversation, because I would say that, you know, other states don't necessarily have to worry about that. They can recruit every single person that they want to work on these problems in whichever way they choose to work on them. You know, we have the luxury of living in the country that we do, that some great minds work at ARL and some work outside of it. And we need to be able to at least get them to understand where we're coming from and start a dialogue so that we can make, you know, we can effectively get the best autonomy out there. Those questions are emerging, and I think you're right. We have to have a discussion about the application, really, of autonomous systems for the Army's sake. And I think it's very important for us to tell anybody associated with this question that our goal is not to put autonomous platforms on the battlefield who can make decisions about launching weapons. Sure, absolutely. That is something that we perhaps will never do as a country. Right. However, our adversaries may, in fact. They may. Right. And so we have to be conscious of that. Right. But also, there will always be, from a U.S. perspective, a soldier in the loop. Yes. Or on the loop, as they say. Right. With regard to autonomous platforms. But you're absolutely right. I think that conversation does have to happen. I think that, honestly, this type of form, like a podcast, is a great place to have it, too. And we just need people to understand that we're thinking very hard about this. We're not taking these concerns lightly. Right. And there was a very large meeting, as I said, I was just at, that was really focusing on exactly this topic. Well, maybe in the future, we'll have a podcast on this very topic, Phil. I would suggest that. You can lead it. I think that's a great idea. Great. Careful what you wish for. All right. Anything you want to ask me? Oh, my goodness. I guess, you know, the Army Futures Command is a very generational, it's a generational shift in the way that we do our work. I guess, what have you seen that gives you the most hope about our ability to be as modern as we possibly can? Well, you know, I have tried for a long time my career. My career is getting long in the tooth, Phil. But for a long time, I have tried to bring scientists and engineers closer to the soldiers who develop war-fighting concepts. So under Army Futures Command, we've stood up what's known as the Futures and Concepts Center. Okay. And they're responsible for developing the new war-fighting concepts, which is multi-domain operations. Okay. That concept will be used or is being used to modernize the Army, right? So we talked about what's happening in Russia and in Europe. We've talked about what's happening in China and in North Korea and the peninsula. Right. We've talked about modernization a little bit from an autonomy perspective. But what we didn't talk about was the notion of how war-fighting has gone from just the air in the land to now what's called five domains of warfare. Right. Air, land, sea, space, and cyberspace. Right. Which is a tremendously complicated space. When you think about it and how autonomy, artificial intelligence, machine learning, all play across those five domains is a very, very interesting problem from not only from an open research question point of view, but from a modernization point of view. Right. What we want to do from a research perspective and from a science and engineering perspective is be engaged with the people who are thinking about developing those kinds of concepts from the very day they're initiated. What typically has happened is you have soldiers who put concepts together. Once the concepts are developed and formed, then they ask the scientists and engineers, hey, what do you think and is this technology going to show up or not? Right. That's the way we used to do it. Right. Now we're doing it together. This is really exciting because it teaches them about what really physically rooted technology is and when it will appear, and it teaches us about what really warfighting concepts are and how they're really going to use technology. Right. Because if we don't talk to soldiers, we're just making it up. Exactly. I mean, we both have different, slightly different detailed knowledge and we're all, that's all the same objective. That's right. Obviously. And I think that it is very important to get us in the same room so that we can start to learn to speak the same language. That's right. To me, this is the most exciting thing and it's really a new part of ARL's mission is to be able to bring our scientific understanding, the things that you articulated, even this discussion of ethics, right, into the discussion about new concepts. Right. Because what's so interesting is this concept of multi-demand operations is the driving force behind how the Army is going to modernize. Okay. And the more we can get our science and technology into that conversation, the more effect what you're doing today will have on what the Army of the Future looks like. It's extraordinarily powerful. So I'm totally, totally just stoked. Yeah. Obviously I've noticed some of these changes through more interaction with men and women in uniform. Right. Yeah. Well, you know, that's the thing, right? How many soldiers have you ever talked to? Well, I was lucky enough to take a greening course. I was very, you know, that actually, I think that maybe not mandatory, but that should be very encouraged. Yeah.  Right. And then when you put on the gear, you really realize exactly why they asked that question. Absolutely right. Every single ounce counts. And so, you know, and also just being able to spend a full week with them and really get to know the non-commissioned officers and otherwise, right? Yeah. Incredible soldiers. Yeah. Absolutely. And the more we can interact with them, the better. So I'm all for that. And I also believe there's also been this notion and a little bit of confusion, I think, in the staff about, well, we do long-term research. We're focused on, you know, 2035 and beyond. Right. You know, are you pulling the laboratory in near term to work on things that are, you know, supposed to be developed three to five years from now and isn't, aren't we just confusing people by doing this? And my answer to that is absolutely not. You can, you can think about technology. We just had a discussion about what autonomous platforms will look like, you know, 25, 30 years from now. But those ideas about what they should look like and how soldiers will interact with them based on what we've learned today, those ideas need to be articulated today. That's right. To the people who are forming the concepts for the future. And that's what I want everybody to understand because it's so valuable to have those conversations and to put what you're learning into what I call a form of consumption that soldiers can take and use, which is much different than writing a paper for an academic journal. Absolutely. Right. And that's the art that we have to teach ourselves because this is something new for us. So what I would say is, you know, to everyone who's listening, you know, don't be apprehensive about this, you know, race it because it really will take what you're doing and just, you know, up your game with regard to the ability to give it to someone who can make use of it. That's the goal. I mean, that will be the way that I would measure my work as being successful as if it ever were to get to save a life, for example. Right. We do this because we want to serve our country. Right. You know, it's one of the major reasons anybody comes to work for the Army because it's not really for the money. I mean, the challenges are great. The problems are great. The science is great. That's right. The people are great. But ultimately, it's service to the country in a way that is very, very meaningful, I think. That's right. So thank you for your service. Thank you, too. Thanks for joining us for ARL, what we learned today. In upcoming episodes, we'll continue the discussion about the underpinning research that will build the Army of the Future. Please consider listening, liking, and subscribing. For the Army Research Lab, I'm Dr. Phil Percanti. Thanks for listening.


The goal of this e-lecture is to introduce you to the sound system of old English. You might ask how can we set up a sound system of a language where we have no audio recordings, let alone native speakers? Well, the details of the sound system of an extinct language are normally inferred from the written remains and if they don't exist either, the principles of comparative phonology are applied, sound shifts, losses and so on. In the case of old English, we have written records, especially from the later history. But even with these, we can only arrive at an approximation and have to set up a sound system where no auditory verification is possible. Nevertheless, we will try. And even more so, I will produce the sounds of old English. So, let's start. This is what we will be doing. First, we will define a reference variety of old English, then we will look at the old English phonemes in detail. We will take a look at the orthography of old English and we'll finally try and exemplify the sounds of old English on the basis of a written text. So, let's start. Now, surviving texts from the old English period occur in four main varieties. West Saxon, Kentish, Merchant and Northumbrian. Towards the end of the old English period, the West Saxon Kingdom, West-X, became dominant and the West Saxon variety became the literary standard. Thus, most scholars treat West Saxon as the leading variety of old English. Today, the following classes of phonemes are assumed for the West Saxon variety of old English. We have 15 monophthongs that can be subdivided into seven long ones and seven short ones and one central monophthong. We have four diphthongal phonemes and we have 17 consonantal phonemes. The consonantal phonemes had much the same value as they have in present day English, but they have a different distribution. The vowels by contrast differed considerably from their modern counterparts. So, let's look at all phonemes in detail and let's start with the monophthongs here. First of all, with the long monophthongs. We already said there were seven long monophthongs in old English. So, let's look at them in detail. Here is the first one. Tide, the E as in Tide, present day English, this is of course Tide. Then we have an E as in Greene, present day English, Green. Old English had an A as in Dale, present day English, Deal. There was a low back vowel, A as in Gart, present day English, Goat. A mid high back vowel, O as in Foda, present day English, Food. And a high back vowel, O as in Housse, present day English, this is of course House. And then a vowel which did not exist or does not exist in present day English any longer, the rounded high front vowel, U as in Mousse, present day English, Mice. As you can see, orthographically, these long monophthongs were all indicated by means of a Macron on top of the vowel. So, this is the indication of vowel length in orthography. The pattern of the long monophthongs in Old English is a highly congruent pattern. Let us now add the short monophthongs. And as I already said, there are seven short monophthongs too. So, here they are. Each long monophthong had a short counterpart. Presentation is overlapping because we cannot put them in the same position on a chart like that. Here is the first one. Kisson, short E, a high front vowel as in the present day English verb to kiss. Short A, which is slightly lower than the high one. Bed, a mid high front vowel which is approaching the mid position. And a low front vowel, short vowel, A as in that present day English, this is that. And then a low back vowel, here it is. Macian, present day English make. Here is the counterpart of the long mid high back vowel, O as in Hopian, short O. This is the short O, a high back vowel, full, present day English, full of course. And here is the equivalent of the front, rounded front vowel, Phyllian as in present day English, Phil. And last but not least, there was one central vowel, namely the schwa. Sorry, I had to switch off this one. This is the one in Julliver, which means present day English, believe. So in unstressed position, we have this short central vowel. So the whole monofungal system was a relatively congruent pattern. Each front vowel had a back vowel counterpart, however, the quality of the mid high front vowel, E, was a bit lower than that of its back vowel counterpart. The most important difference as compared with present day English was the availability of rounded front vowels, long O and short O, like in German for example. Like present day English, old English also had the central vowel schwa, which occurred in most unstressed syllables, for example in the prefix Ye or in suffixes for example De. Let's continue with the four diphthongs in old English. Now, the diphthongs in old English occurred in two pairs, long and short. They were all centering, that is their second vocalic element was the central vowel schwa. This movement towards the central target can also be referred to as ingliding, so all old English diphthongs were ingliding diphthongs. Here they are, let's start with the short ones. The first one is Er as in Herte, present day English Hart. The second one has a lower onset. It is Er as in Eller, which means present day English all. And the two long ones, here is the first long one, Er, Behr, which means present day English beer. And the second one is Er, which occurs in the word Schaap, present day English sheep. A relatively straightforward diphthongal system. Here are the seventeen consonants. And again I want to stress that they are consonantal phonemes. Old English retained all consonants of common Germanic, although the distribution of some of them had been affected by some sound changes. So let us compare the consonantal system with that of present day English. Let's first of all look at the inventory. Now there were some strange or amazing inventory differences. For example, the Schaap, the first one here, as in Licht and the Schaap as in Fucht. Were part of the sound inventory, however, as you can see here, there were allophones of the phoneme H, that is the glottal fricative. Similarly, the R as in Ahran was a special allophone of G. So this is an inventory difference, however, on an allophonic level. Now secondly, we have distributional differences. And this is quite interesting. The voiced fricatives, V, as in Driven, V, as in Bavian, or Z, as in Reason, they were only used in voiced contexts. Elsewhere, for example, word initially, their voiceless counterparts are used. So let's look at them in detail. So here is the labiodental fricative phoneme with two allophones. The V in voiced environments and the voiceless allophone elsewhere. And similarly, we have the dental fricative phoneme again with the voiced allophone in voiced contexts and the voiceless one elsewhere, Bavian versus Thunur. And likewise, the alveolar fricative, voiceless sonar and voiced in a voiced environment, Reason. Thus, we can establish the following rule. A, well, let's call it fricative rule for Old English. Whenever we have one of these fricatives, labiodental, dental, or alveolar, we have two allophones. One allophone occurs in a voiced environment and it is voiced, V, V, and Z. And the second one occurs in voiceless environments. Finally, we have some special sounds in Old English. And these, of course, concern the pronunciation of the R. Now, one thing is assumed for Old English and that is a high degree of roticity, which means that the R was pronounced in all contexts, even after vowels. And secondly, it is hard to say what type of R was used. Was it the alveolar trill as in driven? Was it the alveolar approximate as in driven? Or the alveolar flap as in driven? Well, it is hard to say. Thus, it's up to you which one you use. I normally use the alveolar trill as the primary allophone of the R, but we could say that the allophones of R are in free variation. Further differences between present-day English and Old English concern the use of the Vila nasal and the allophonic realization of K. Well, having talked about the phonemic system, let's now talk about the orthography of Old English. The Anglo-Saxons first used a runic alphabet. Now, this alphabet was called Fudak after the initial letters of the symbols that had all names. And so here we have the phail, the ur, the thorn, the os, the R, and the ken. And so, if you combine these letters, the initial letters primarily, then you get Fudak. Now, each rune was a letter in the alphabet, and it also stood for a word. The earliest use of runes, and this is just an excerpt, was for magical purposes. There were many different Fudaks. The fragment used here is an older Germanic Fudak. Later, Irish monks brought the Latin alphabet to England and some new letters with it. And the Old English writing system was based from now on on a modified Latin alphabet. Now, here are some symbols that were used in Old English but are no longer used in present-day English. I just marked some significant ones. This one, for example, is the so-called ash. You know that from the phonetic alphabet. And then, of course, we have here the macrons as length marks on top of the vowels. Quite interesting is this one here. Here we have representations of the dental fricative, the ev, the second one is the so-called ev. And the first one is a capitalization of a character which is represented normally over here. And that is the character thorn used for dental fricatives. Let's finally exemplify Old English and read a textual excerpt. Now, here I have a little book which is entitled Old English Literature. And it was published by Randolph Quirk, Valerie Adams, and Derek Davy a long time ago. But these texts obviously don't change anymore. And I will read a little passage from the Anglo-Saxon Chronicle which was published or which was written in 991 as a short excerpt of the famous Battle of Maldon. So, here it is. That was Kaelan Sunu, the son of Forman Man, with his Franken-off shirt. There, Baldlicoste, on Thabritje Stoop. There, Stodon with Wolfstahne, Wien and Forchte, Alvare and Macus, Maudie II. Tha Nolden at Thamforda Flem, Jewirken, a key fast leacher with Thafund Verden. Tha Huile, the he, Wepna, Welden, Moston. This may suffice as an impression of Old English. Now, let us summarize. The Old English sound system is still very much Germanic in character and much closer to German than to present-day English. The 15 monophones, the four diphthones and the 17 consonants constitute the heart of the Old English sound system. In this e-lecture, please consider it only as an attempt. I tried to do my very best to pronounce all these phonemes with their alophonic realizations. And I hope the last passage of the Battle of Maldon gave you some impression about what Old English could have sounded like. Thanks for your attention.


Here you are, Lige. Yes. Welcome, welcome everyone. And as Maurice said, it's actually a good thing that we are not so many people. So we can have more hands on and more discussion in the end. Because we want to also, it's not about only what's new in Wallace. I also want to show you this thing and have a hands on here basically. So we use Wallet Connect to open the box and then you can get drink vouchers. And as you are so few people, the chances are higher. And we also like have status IM hardware wallets in there. So basically after you open the box with Wallet Connect, it looks like that. There are your vouchers, some stickers, and on the left the hardware wallets. It would be super awesome if the hardware wallets only get taken by people that actually have an Android phone with NFC support that it can really be used. Because currently they are quite expensive but they get cheap. So it doesn't really make sense to just collect them and they get dust. Please really test with that. So you can take one if you open it, but really then also test around with that. So now a little bit, what's new in Wallace? One thing that really really changed is the account management. Before, I thought it's a really good idea to just create an account in the beginning that you can just get started. So you start the app, you have an account ready and you can do things. Basically that was not the best idea because it depends on the use case how you want to use your wallet. Not all want to use it with a burner wallet. Some want to use it with different accounts, for example with the Trezor. So now when you start the app, you can select your use case, concentrate it on what kind of account you want to start. Like the first, as the burner basically, I took this name from Austin Griffith. Just Austin Griffith current is wonderful term of a burner wallet so everyone knows what's going on there. That was actually how it worked in Wallace before. Like I didn't have a password because I think that's easily to get started is the thing, so it was a burner wallet but I was never calling it that. But the name is really good and now also like distributed in the whole ecosystem. So that's now called that. The second thing, and I think you basically should go usually from a burner to a Trezor. So there is I think nothing much in between. We have more stuff in between but I think that's the way to go because if you then really have an account that is worth something. You want to protect, you should protect it with a hardware wallet and that's connected via USB OTG. Now with the Model T with USB-C it got really easy because before it was a bit fiddly you had to have this OTG adapter and put it in the right direction but now with USB-C connected to the phone that's really easy. And it's also updated to the recent Trezor. That's also a little bit of a drawback. I couldn't get backward compatibility without a lot of overhead. So I'm just now like well it's just compatible with the latest version so you really have to update but that's also how a Satoshi Labs does it internally. They really want you to update and then force you basically to do that. I was looking into backward compatibility but the problem is like it's a protobuf and it would increase the app size a lot and I'm really caring about the app size and I didn't really want to do that. The next thing is for example if you switch your phone it's import key so you export it on the old device you import the new one you also don't want to create a new account you just start the app, you import it. The next thing if you don't even want to have keys on there is watch only so you just specify an address or scan it and then you can just watch it so some people just don't trust their phone but if you just want to watch if you get something incoming you can only use that for that. The next thing is NFC and that's also very very new that's basically about these key cards which are also like in the box. They are really new and wallet is the first wallet that supports the key card now it doesn't yet support all features currently you can make transactions and set up the wallet make transactions and that's basically first of all it but it's a good thing to start there are way more features that this key card can like what's really interesting is the pinless derivation paths basically so you can pay it post systems and imagine it like the mixer recently also came up so imagine like a mixer that always fills up your latest pinless derivation path and you just pay with it in a private manner that opens a lot of possibility and also like in the mobile case what you would use case is copying of these cards because that's really probably you want to copy these cards without exposing the key to the device that's copying if you want to do a direct copy unfortunately you can't direct copy the cards but the key card team basically invented a system with multiple wallets you have basically witnesses in between that nobody sees the whole key but you can still transfer the key from one card to the other for backups I think that opens up a lot of possibilities but it's quite new and I want people to actually try that out the advantage is to a real hardware wallet is like you don't have to plug it in it's NFC basically you just tap so you tap on your phone and then basically your transaction is done or got signed and then it's done when it's sent somewhere so you don't have to plug in some USB it's a bit more convenient that way and it's also way cheaper but what you see like the big disadvantage of course of that is that you don't yet have displays on that so it's a bit less secure but you have the trade-offs but it's a good trade-off for a lot of use cases that's how it looks basically then you either have to select you want to do a new card or you haven't already initialized card unfortunately currently you need to like basically when you have a new card remember three things it's like a pin six digits a book 12 digits and a pairing password for the daily usage you just need the pin if you forget your pin and the pairing password you need that if you want to pair with a different device basically so in day-to-day usage you just really care for the pin and then basically after you press that it has you like to bring the NFC tag close to your phone sensor and action and then it's basically the same as always that's another thing like people asked just for pin protection I think really you should go from a burner to a hardware wallet but some people asked for that I don't really know why because I think then the protection of your pin or the protection from your phone is basically you should only use that when you like do 20 euros like pay for drinks or something like that it shouldn't be high value and then the obstacle of having to remember a pin is higher and the security gain is not that much in the end but people asked for it very loudly so I added it and you can now protect it basically and also you see that's an internal keypad because also people asked for passwords that's even more rudimentary because I also think because here you share the keyboard basically these keyboards are external services you share your password with Google and that's a problem so rather I think use pin but some people asked for passwords you can now also do password protected accounts what also a lot of people don't find is basically the shortcuts because what you really often want to do is just scan something and with Android you have these wonderful shortcuts so you basically just long press on the walls icon and then you have scan and chance act if you need other shortcuts let me know but these are the use cases I know especially scan for example if you want to use it with the box just get the scan you don't have to go into the app and then select scan deep in there you just shortcut scan, scan the QR code and you have your use case ready in the end this is the new account listing basically that also has a little bit changed basically when you want to manage a lot of accounts in the end then you want to basically start some accounts that you really use often you want to just select the ones with the key or just basic filtering and you also like the indicators you're on the top right you see basically you don't see my cursor here basically these are watch only accounts there's a burner account pin so the images are used always that you recognize from creation to right there and if you're everything that is basically this greenish color you can press for example like on the burner then you export your key so that's your key export then these are the networks there's also like a lot of more new networks now supported basically everything that's an Ethereum list change you see this different symbols here, Goalie for example has this lightning and that means you have really really fast access to a thousand just one click and you basically auto your current address is auto filled and it's just basically one click to fill your account some like rinkabee where it's just like this present thing it's a bit more complicated because you have to do this tweet thing and that's a bit more cumbersome I can't just invoke that from the app that easily so basically you can still go to the folder but it's a bit more manual process it's not really that fast so I also start with Goalie because it's basically just you open create a burner give me money and then you have your money and you can spend it and try things out in the end and also now with the Goalie pusher you also automatically get pushed to token so you can transact token transact ether and can try the different stuff with that these are basically all the networks then supported in the end it's all a chain ID network and if you want to add some networks just add them with a pull request to Ethereum list chains and then basically you can press the sync button on the top right and then the new chain is also added yeah that's it that's the new tokens tokens basically the same like Goalie the root token then also has this faucet link and you have standard tokens and I think over a thousand of them and those are collected in Ethereum list tokens so if you want to submit your own you can submit them there that sounds a bit stupid like you just change a toolbar but it's also like a security implication because when you make the wallet your own you basically recognize clones or recognize fakes that just pop up but they might not know the color of your wallet so you're especially warned before and I want to do that a little bit more because I want to show you what you can do so you have some just otherwise it's quite easy to make a fake app that just pops up and you put your credentials and it makes something malicious you have also this security information now it basically gives you your latest patch day but it's only important if you really hold a key on the phone so if you use it with a treasure that your latest patch of your system not of the app but your latest system patch not so long ago you have to see routing because routing would break the app isolation also warns if the phone is rooted that will also not be good checks for lock screen and different other stuff yeah now I want to talk a little bit about what was added and now I want to talk also like this is the thing perhaps people have read the blog post recently of the Ethereum foundation like subtraction is a really beautiful concept and I also removed stuff from all it not only screens like before I was also removing screens that just de-duplicated but one thing is a bit first a bad thing I moved away from the light lines because they just provided so bad user experience like the default there is still a flavor for light lines but the default is now not anymore I want to move to RPC I want to move to Incubed it should come in Q2 like I got the deadline Q2 and then basically the minimal verification I think it's a much better user experience in the end and you still don't have the centralization problem let's see when it comes out it might be quite easy because it's also RPC based flavor I had it in before because also WalletConnect in the beginning had Firebase so I had it added and I had it as a flavor because I needed to put it out anyway for Afteroid so it was not working on Afteroid so I had two flavors like one with Firebase for Afteroid and one with Firebase for Google Play but I now completely removed it because it's not used for WalletConnect anymore and it also really helped the direction of making the app build reproducible and Firebase was a problem there alongside a lot of other things so I now just did a step to remove it and also it helps new developers because Firebase also have the secrets and then I had to have a Git crypt in there and hide these secrets so now there's no more secret and there was a problem before for people that just try to build the app clone it, try to build it but then you rely on the secrets to work so it's now completely removed subtraction following yeah a bit in the reproducibility I had it already recently building reproducible unfortunately now there's a new bug where just one bit is different yeah in the but we figured it out so that's only forefront there is a new field but I think that can really help in the future because there's also a problem how do you like you know this app is open source but how do you know that the binary get belongs to the source you've seen and that can really help so we can really then spread out different people build the app and agree on the hash form the release hash for the comment hash and then you can really trust this app way more and there were also like some organizational changes everything was grown in the beginning in the Wally's organization but there was this library key theorem that was growing in Wally's but now matured into a new organization called computing because there's also people that the advantage of having everything there in Kotlin is you can not only compile it to Java and use it for Android for example but you can also use it to compile it to JavaScript and have like basically static typing with JavaScript but I didn't want to have it because it was then exploding also like in kithium split in different modules to have it easier and it was just growing in the so it's better to split the organization there and have a bit of separation of concerns yeah now a little bit bullet connect also updates like to the new standard you can also like try it out here we have some things to try it out later on also Pedro will talk a bit deeper for sure about Wally connect about that afterwards but he's basically changes like the new standard also make it visually a bit more pleasing please try it out and now we also see that the adoption gets by higher like now Metamask is on the train so we get traction and we need more dApps now to try it out like this is also one dApp and Pedro shows a dApp let's do more dApps and really try it out because I think that's a beautiful concept basically to separate wallets from the dApps yeah that's for me basically if there are any questions otherwise Pedro will go directly with wallet connect yeah thank you all questions it's minimal verification clients basically so it's a smart contract where you can register as a provider of data and then you have a stake there and then you basically sign all the blockages you like on request and you can lose your stake if you signed the wrong blockages or like so I can trust the data regarding to the stake basically also depends like sometimes like if I pay my coffee I don't need the millions of steak because it's just about the coffee so then it's also like can somebody with small equipment basically do it yeah but just it's a project from Slocut basically and they did talks also about that unfortunately it's not like the servers yet to release so you can do the server part already but the client part I need especially the C++ one is not yet done but they said like Q2 and Q2 is basically a month or something like that so it should be but I think it's a nice solution because the thing is with light clients it sounds light but it's still heavy you know you still have to have this peer-to-peer chatter you still have to download a lot of data it's less than a full note but it's still a lot of data in the end and then if you see you don't only have one chain you have basically multiple chains you do that for everyone and let's say main chain was now 50 megabytes but then you have different chains and always have this also this weighting of until it's zoomed and that's for users is really bad you have to wait until it's zoomed your phone gets fucking hot, your battery is empty users are just angry and it doesn't have anyone it's the right thing to do usually that's also like I was really struggling to remove it basically it's not removed it's just basically not the main thing it's still a flavor you can build it and use it but the main thing is now the APK size got much smaller and I want to target emerging markets and they don't have the newest phones or data lines it's really important that the APK size is also small it has so much advantages the traffic is way less traffic also we have allowances of gigabytes it's like every megabyte counts and the like line is really like it's sucking data it's like basically you just do in the end you simplify and it proves with that and then yeah so here's the follow up what do you have a proof of is basically the latest head of the blockchain right the block hash yeah you have a signed block hash basically and from that you can go back and prove your but it's basically I'm an application developer so watch the talks from Slocut about that and yeah I don't want to go too deep into that because I basically just leverage that and that sounds like a good solution but scrutinize it if you're really into that really scrutinize before I put it in they put out it's a white paper out read the white paper yeah and then yeah other questions yeah you mentioned that you're not using the like client anymore but also not the in-cube stuff yet so what do you use in between RPC like basically everyone is doing it's just now basically you use RPC it's not good but basically everyone is doing it it sounds bad like everyone drama's out of the window and you jump afterwards and I really struggle to do that but the thing is also like for a lot of users strangely it doesn't really matter they just use it and they compare the user experience then they say you're wallet and getting your phone hot consuming all your data and still doesn't work sometimes because like clients also sometimes it just fails for some like yeah and just a horrible user experience and people just say yeah your app is bad okay and the thing is also like with these systems you can also make it more gradual you can also like basically have a trust slider in the end you might be okay with starting like with minimal trust you know just trying things out and then things get more serious and then you increase the trust slider and that will also in the end cost you money and there's also no thing also with light clients it will cost money in the end it's just not sustainable you know currently there are some like but you also see when there's a spike then the light clients servers are also you know that doesn't scale and there's now like there's this project basically rent light client servers but you also see with different nodes it's really good what they are doing but there's still a problem like phones still gets hot but at least you get a light client slot but imagine you don't get any slot so yeah it's a big mess but does it answer your question cool other questions no more questions okay thank you so much for all this great news and information


In this lesson, let's talk about Arrows and Lines. Remember that we are just going through stuff on the different features of Prezi, and then we will use all that knowledge to create a presentation together. Also remember that we work in a workplace with many levels. Every time we add a sub-topics, we are adding an open canvas, and in this particular open canvas, we are going to insert Arrows and Lines. Before doing that, let me add a couple of icons that will help me show better how this works. Let's change the color and make them smaller. Now let's add our Arrows and Lines. Let's say that we want to add an arrow on orange that goes from here. Let me insert also shape to here. Please pay attention to how the arrow sticks at some point. Book sticks to the image that I'm approaching to. And let's add another one, another arrow, that goes to here. I wanted to stick to this element. The main feature of working with Lines and Arrows is that they stick to elements. So if we want to move them around, when we move the elements, they are related to the arrows will change accordingly. We can also change the curvature of an arrow because we want to add here our logo. So let's upload it from my computer. But this is not going to work because the colors are not right, but it doesn't matter. We want to simplify how the arrows work. Of course, remember always that when you select an object, we have the Context and Menu for that object. We can change the color depending on the preset of our theme. We can choose our specific color. We can change the opacity. See what happens when I change the opacity of one of the lines. See how this is solid and not transparent while this one is having a slight transparency to the background. Again, click and you have the Context and Menu. You can change the thickness, make it thicker, stronger, and you can also save the element to your library. So if you have an arrow that you like that has the colors and the transparency and the form that you like, then you can add that same image from your library. Remember, right click, add to my library, and then when I go to insert arrows and choose my library, I will have the arrow really made here. That's it on the basic lesson on arrows and lines. See you in the next chapter.