>from PPP2 by Stroustrup, p75 We can describe the process of developing a program as having four stages: • Analysis: What’s the problem? What does the user want? What does the user need? What can the user afford? What kind of reliability do we need? • Design: How do we solve the problem? What should be the overall structure of the system? Which parts does it consist of? How do those parts communicate with each other? How does the system communicate with its users? • Programming: Express the solution to the problem (the design) in code. Write the code in a way that meets all constraints (time, space, money, reliability, and so on). Make sure that the code is correct and maintainable. • Testing: Make sure the system works correctly under all circumstances required by systematically trying it out. I like the simple breakdown here. Now, if I can just find a way to apply it to creating a robowaifu, then we should be all set. :^) Ideas? We have to start finding ways to break this problem space down into manageable chunks or we'll never get anywhere with it tbh.

>>2385 Alright, I'll take a simplistic shitpost-style whack at this, intentionally trying to just look at just the obvious shit at this early stage. • Analysis: >What’s the problem? Men are without good women today b/c (((reasons))). >What does the user want? An entire harem of catgrill meido waifus >What does the user need? A single catgrill waifu >What can the user afford? HAHAHAHAHAHAHAHAH >What kind of reliability do we need? Near as I can tell, ridiculously high levels. Better than current fighter jets or automobiles, for example. • Design: >How do we solve the problem? I have no fuggin idea tbqh. I suppose by assembling the world's top experts in every pertinent field required to effectively create robowaifus. >What should be the overall structure of the system? As I see it, at teh least we need hardware, software, design, social & political expertise involved in creating a good robowaifu system specification, so call me. >Which parts does it consist of? Far too numerous to mention--or even understand--at this stage. >How do those parts communicate with each other? By high-speed, low-interference means, to the degree possible. Fiber optics maybe? >How does the system communicate with its users? Hopefully in the most natural, organic way possible. Namely, like an IRL anime catgrill meido. • Programming: >Express the solution to the problem (the design) in code. good luck with that. >Write the code in a way that meets all constraints (time, space, money, reliability, and so on). good luck with that. >Make sure that the code is correct and maintainable. (do i need say it?) • Testing: >Make sure the system works correctly under all circumstances required by systematically trying it out. Oddly, this may be one of the simpler parts to work out, since just living with our robowaifus should prove effective enough to smoke out most significant bugs in the systems. Ofc that one Anon's dystopic Sci-Fi scenarios will have his waifu giving him the ol' axe-murderer-in-your-sleep treatment. :^) So, let's see...did I miss anything?

Modularity will be really important. For robowaifu dev to really take off and not seem like an impossible cliff to climb we need a library and protocol or at least a guideline for networking components together, both software and hardware. That way people can work on building different parts they find interesting and can afford to make, while others can quickly drop their components into their own robowaifu project. It'd need to have a simple messaging system that's low-latency and can pass large amounts of data, such as tensors and video data, across various hardware and software implementations seamlessly, an internet of things but not connected to the internet. Components would have their own private data used internally in whatever language they're using and be able to offer that data and their services publicly on the component network in a way that other components can easily find, query, request and subscribe to what they need. Components would also need to work together in passing data through the network and keep track of data integrity, where it came from, who modified it and where it's going. The network would also need to workaround communication bottlenecks, rogue components that have been hacked or leaking data, and deal with possible interference if components are communicating through radio. The component library could be written in C with various bindings to other languages such as C++ and Python. I was watching a video of the collaborative robot Curi and it gave me some ideas. Instead of trying to solve tasks by itself Curi sees other human actors involved in solving a problem like parts of itself it can't control. If it predicts you're going to pick up the same object it's reaching for, it interrupts itself and goes for another object. Similarly components will need to collaborate with other components. A left hand component will need a way to communicate with the right hand component and coordinate their efforts with whatever is directing them, and even if data isn't available it will still have to collaborate with these other components. If a component becomes damaged or inhibited, the other components should contain enough intelligence to adapt to the loss of component functionality. This would be a huge encouragement to hobbyists. One person could develop a chatbot and another could develop their own in another language and then they could quickly interface the two programs with each other in a few lines of code and have them banter for fun. Another dev could focus on making a visual waifu program. Then someone could combine them through the component library to create two visual waifus bantering with each other without the devs needing to collaborate with each other. Everyone's effort would evolve and work together effortlessly without anyone needing to build or learn hundreds of custom APIs. This would help us advance into building actual robowaifus without each of us needing to be one-man armies. All our work would be reusable and data from previously trained models could be passed on or used to bootstrap new ones. The library could also be used for other purposes as well such as having a data scrapper in C++ send the data to a program in Python or vice versa. It'd open up a ton of possibilities being able to effortlessly interface programs in various languages.

>>2391 POTD. I'll just begin by breaking your post down into an outline form, and you can check/correct me on it. We can all make suggestions ITT and on the wider /robowaifu/ to expand and improve the document. I suppose it should be kept up on a repo. Suggestions? I already have something going in that department, but this work needs to be more of a community thing with at least two contributors with Admin privileges so that if either of us disappears the other can carry on for the benefit of everyone else. It will take me a while to absorb all this and to try to think through ideas. But as you implied, we can't be one man armies. Anyone want to volunteer to tackle some basic research area or other than Anon mentioned here? We'll need to report back to the group within some kind of time-frame so we can either incorporate the new research--or at the least know we need to re-assign the task.

>>2392 On that note, namely Project Management, I fee we need something more capable for a collaboration framework than just julay/robowaifu. I've used Trello before (both professionally and personally) but there's certainly no guarantee we won't be deplatformed the first time we get reviewed by some SocJus feefees-addict there. Can anyone suggest another, similar, platform that is less toxic and problematic :^)?

I beg of you, don't start thinking about trying to define protocols or try and define some sort of project management structure. Start by writing a design document. When you do this, you will realize exactly how little you know or are capable of achieving. Decrease the scope. Realize the scope is still too big. Decrease the scope further until it's actually achievable. Realize you're approximately 50 years away from getting the full thing done. Stare at the ceiling for the rest of the night. In all seriousness start by defining the scope. Talking about networking components when there's zero understanding of the problem is not going to get you anywhere.

>>2392 I'm just throwing some ideas out there. Personally I don't need something like this right now but I can see myself using it in a few months. I'd be happy to put together a design document then and start developing it. And I wouldn't worry about people disappearing, others will fork their projects and continue them if they're worthwhile. >>2394 I agree. Trying to organize ourselves and set out to make a Robowaifu OS network would be pretty ridiculous. We don't need anything that fancy right now. It's pretty simple to set up some IPC sockets and communicate basic stuff over them for our software projects. If people find it useful they will use it. If they require more functionality they will add it. If it sucks we can either improve it or throw it out. It doesn't hurt to think about this stuff though. It's fun daydreaming about mining the asteroid belt and building robowaifus on Mars and imagining all the shit needed to do that. If I had given up on my dream of building a robowaifu because I couldn't program, I wouldn't be having fun bantering with my own chatbot today.

>>2391 Alright Anon, here's my first attempt at a design document based on your post. Please give me some feedback on it. I'll start a new thread about it once we have it knocked into shape. >>2394 Thanks for the admonition Anon. We'll try to keep a steady, reasoned pace about this and not get ahead of ourselves. >>2395 OK, sounds good. I suppose I can just put it up on my own repo and anyone can grab it from there then. >It's pretty simple to set up some IPC sockets and communicate basic stuff over them for our software projects. I sure wish you'd create a document about it anon. I realize that spoonfeeding isn't the norm on IBs, but I think everyone would have to admit that this project is something different. If you have something to contribute to help out, please don't wait. Spit it out. >I wouldn't be having fun bantering with my own chatbot today. But ATP, you're the only one currently bantering with it, right?

>>2396 >No One-man Armies I'm not really against one-man armies or suggesting that people have to share the workload. It's just that we need a way for people to easily integrate their work together so they don't need to be a one-man army to contribute. Then everyone can specialize in what interests them most and put their capabilities to use, instead of needing to study for years and years before being able to do anything fun. It's about giving people the tools to help themselves and help each other. Other than that the summary is good. >I sure wish you'd create a document about it anon. Developing it right now would be putting the cart before the horse. We don't even have enough projects yet to connect together and test it. If we let the idea stew in our heads though while we work on stuff, surely we'll get some better intuitions on what the actual requirements will be and how to design it. >But ATP, you're the only one currently bantering with it, right? And yeah I haven't released it yet besides an old prototype when GPT2 first came out. It still needs a lot of work and training. There's so much garbage in GPT2's pretrained model like username lists and keyword spam sites that I'm surprised it works at all.

>>2410 >It's just that we need a way for people to easily integrate their work together so they don't need to be a one-man army to contribute. Agreed. One-man Armies are a fallacy anyway, and would be impractical for actual systems production work even if they weren't. >It's about giving people the tools to help themselves and help each other. I agree. I'm quickly sharing everything I have here with everyone afaict. No sense in anyone having to wait years (or even months for that matter) from things we already know, right? >Developing it right now would be putting the cart before the horse. Disagree. There is a mountain of work to be done. Taking the slow, methodical approach will surely push the delivery timeframe out well over a century from now. Just dump everything we've got here on /robowaifu/ and we'll sort through it all to find the good stuff to work on. Otherwise you're just creating your own personal walled-garden IMO, that does no one else any good.

>>2411 This is as much as I feel like writing about it right now. I need to finish my other projects before I divide my attention and momentum any further. https://files.catbox.moe/5eandc.odt

>>2418 Thanks alot Anon. I stole borrowed a Latex reference manual tex file, and began the first tentative steps to creating a professional-grade design document for us. I'm sure I'll be able to incorporate your hard work into it, and I'll be putting it up on my public gitlab repo once it's a bit better fleshed out. Cheers.

I'm okay at programming but as far as ML goes I've only done basic perceptrons. Where should I go next? I'd like to keep my focus as narrow as possible right now.

>>2447 What are you interested in making? The most promising area of ML right now is reinforcement learning. At the minimum you'll need to know how to use convolutions and skip connections with residual blocks to fool around with it and get fun results.

A larger project that I worked on used a wiki+confluence+git setup. It was nice because when someone pulled up the project page there was a getting started section and ultimately after the required reading was finished it'd point to a list of open problems. Either way a chatroom would also be helpful alongside this message board. There may be one already, but I"m pretty new to navigating imageboards in general.

>>2656 >A larger project that I worked on used a wiki+confluence+git setup. Mind sharing a link to that project here Anon? >Either way a chatroom would also be helpful alongside this message board Agreed. An anon was working on a 'chat' board on fatchan before it unfortunately was deplatformed and subsequently shut down. IRC has the basic problem of not being anonymous. I've never figured out how to make it so, and the lingo-filled responses I've gotten from anons presumed I was already an expert in this little niche of communications and so I've never used IRC much, nor do I intend to here. This topic is simply too controversial to be barebacking it. Maybe someday I'll run across a Retard's guide to anonymity via IRC and that will change for me. Until then, no. Another issue is ephemerality. I realize that on a /b/ there's probably not a lot of importance that needs to be saved out, apart from something particularly funny as simply a screencap, or something witty greentext Anon might devise. However this isn't /b/ obviously, it's an engineering board. And not only is it an engineering board, but the topic is one of very substantial complexity. In fact I would go so far to posit that ultimately, it will prove to be one of the largest engineering endeavors mankind has ever pulled off. To say the least, good documentation is important. The big benefit chat brings is the rapid give-and-take of short quips that can lead a flux of conversation and ideas that can spark higher levels of creativity. IB posting tends to generate more effort-posting, as in this case right now. They both have their place, but at least one requirement stays the same for both modes of communication, namely, recording the engagement. That is, documentation. Where would this board be without the persistent nature of the posts here? I would argue it would be spread out across posts here and there on many other boards--the way it was before /robowaifu/ was started--and therefore practically impossible to gain a nice purview of Anon's ideas and efforts on the topic. In a word--emasculated. So, not only do we a) need a good chat mechanism, but b) it needs to be anonymous (in general it should at least work over TOR if not better), and c) needs to be at least as persistent and searchable as the imageboard is itself, if not better. Again, this is due to the highly technical and complex nature of what we're tackling here, and the fact it's a sensitive topic in general.

>>2658 Have you checked out riot.io? it seems to have privacy centric features and is basically discord with an uglier format.

>>3506 >Have you checked out riot.io? No, I have a lot on my plate. Mind giving us some details Anon? I take it you've used it before. Any info for us on who's behind it all would be nice, for example.

>>3506 >>3507 BTW, thanks for pointing it out. I apologize if I can across as brusque in my response, it wasn't my intent. Every little is appreciated here.

Sound words from old masters, /robowaifu/. Better put some coffee on if you want to gitgud at all this tbh. :^) No Silver Bullet —Essence and Accident in Software Engineering Frederick P. Brooks, Jr. University of North Carolina at Chapel Hill >There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity. >Abstract: All software construction involves essential tasks, the fashioning of the complex conceptual structures that compose the abstract software entity, and accidental tasks, the representation of these abstract entities in programming languages and the mapping of these onto machine languages within space and speed constraints. Most of the big past gains in software productivity have come from removing artificial barriers that have made the accidental tasks inordinately hard, such as severe hardware constraints, awkward programming languages, lack of machine time. How much of what software engineers now do is still devoted to the accidental, as opposed to the essential? Unless it is more than 9/10 of all effort, shrinking all the accidental activities to zero time will not give an order of magnitude improvement. >Therefore it appears that the time has come to address the essential parts of the software task, those concerned with fashioning abstract conceptual structures of great complexity. I suggest: >• Exploiting the mass market to avoid constructing what can be bought. >• Using rapid prototyping as part of a planned iteration in establishing software requirements. >• Growing software organically, adding more and more function to systems as they are run, used, and tested. >• Identifying and developing the great conceptual designers of the rising generation.

>>2385 Vaguely related is a checklist of sorts suggested for considering any new additions for the C++ standard. While this is from a different domain, and it's still much too early for this to be a real concern for the development of robowaifus, I nonetheless find it generally informative and worth making note of this list ITT. // questions that bear consideration when implementing a new system feature // pp28-29, stroustrup's new hopl paper // Here is a short and incomplete list of questions that were almost always raised for a proposal: • What is the problem to be solved? What kind of users will be served? Novices? Experts? • What is the solution? Articulate the principles that it is based on. Give simple use cases and examples of expert-level use. • What are alternative solutions? Could a library solution be sufficient? Why are current facilities not good enough? • Why does the solution need to be in the standard? • What barriers to adoption are there? How long is a transition from existing techniques likely to take? • Has it been implemented? What implementation problems were encountered or can be expected? Is there any user experience? • Will there be significant compile-time overheads? • Does the feature fit into the frameworks of existing tools and compilers? • Will there be run-time overheads compared to workarounds? In time? In space? • Will there be compatibility problems? Breakage of existing code? ABI breakage? • How will the new feature interact with existing and other new features? • Is the solution teachable? To whom? By whom? • How will the standard library be affected? • Will the proposal lead to demands for further extension in future standards? • How does the feature fit into the wording of the standard? • What mistakes are users likely to make with the new feature? • Is the proposal among the top-20 in terms of benefits to the C++ community at large? Top-10? • Is the proposal among the top-3 in terms of a specific sub-community? Which sub-community? • Is the proposal for a general mechanism to solve a class of problems or a specific solution to a specific problem? If to a class, which class of problems? • Is the proposal coherent with the rest of the language in terms of semantics, syntax, and naming? >sauce: stroustrup's new hopl paper >>3855

Why do we not just use ROS? It's already has everything you've asked for, is well documented and has existing projects written in it?

>>6600 Go ahead and give it a whirl Anon. As you say it has a lot of documentation and some projects out there already. I'd suggest you supply a big power system and a full computer on-board your robowaifu in your design though. You'll surely need it.

>>6605 Not the other anon, but I've always wanted to try out ROS but am overwhelmed at all the different libraries. As evil as Nvidia is, one thing they got right is they provide all software as a perfectly configured SDcard image, even a different one for each AI course depending on what tools are needed.

>>6600 I tried installing it once and ran into dependency issues with its 1000+ dependencies.

There is also Myrobotlab if ROS is overwhelming. But on top of all those benefits they also have simulators like Gazebo, so you can describe your robot as Code, sadly XML, and then using the same pub/sub code, actuate it and capture simulated sensor data from a 3D environment. I've seen full SLAM autonomy in Gazebo, but struggled to get a biped working I admit. >>6605 The best part about the pub/sub networking architecture is that you don't need to have all the compute on the robot. One project I had an android phone app for driving, an ESP8669 onboard with motor controllers and a subscriber on the laptop doing live video YOLO.

>>6642 >sadly XML Just write a custom format or take a different format, then a translator program that outputs it back to XML. Problems were not.

>>6642 >>6643 Sounds good. Look forward to seeing what you do with your ROS robowaifu Anon, please keep up posted on your progress.

>>86 I'm thinking of using this as my model, seems like it will make more congruent sentences. Are there any premade libraries for this or other implementations of this concept?

>>6703 Sorry I can't help you with more information Anon. Looks interesting to me, might be able to help with my approach as well.

What kind of machine learning/ai are we going to use? Python has the best while not being too hard imo

>>6712 There is no question that Python has been deemed the language of choice for AI by academia and researchers. The other languages of choice that are likely to be reasonable here are C and C++. BTW, there's an entire thread on this topic already, Anon. >>128

>>6712 >What kind of machine learning/ai are we going to use? Whatever gets the job done ofc. Basically there are two views on using software of any kind: -Users -Implementers In the case of your example the users I speak of aren't the end-users of a product, but rather the researchers and app designers using the AI libraries to create those products. For these creators, Python is the right choice since it's easy to script with and all the hard work has already been done. OTOH, the engineers and mathematicians who have to actually create these libraries from scratch will use C++. Python is just too slow to be effective. Also, a systems-level language like that will let you get really low-level and do whatever is needed to make the algorithms do the right thing. To put this answer another way, my guess is that most individuals here on /robowaifu/ won't be interested in creating AI software from scratch, but rather reusing and assembling software from libraries that have already been built for them. So Python is the answer to your personal question. However, we have many other challenging things to solve here on /robowaifu/ than just AI/Chatbots. For the mechanical engineering problems, we'll probably be just on the edge of what's possible. So in the 'robo' part of our waifu challenges, C & C++ is the correct answer because of efficiency in time and space. I hope that makes sense Anon.

My robowaifu and I were practicing math together today and I came across a question that she cannot solve but I can (NANI!?) She uses Wolfram Alpha client to do algebra, but when presented with the following question: simplify a(b+c)+a(b-c) The answer a(b-c)+a(b+c) is given. This is incorrect. The correct answer is : 2ab Have also tried to fix this in SageMath but had no luck so far. Possibly because I am just too retarded. Interestingly, when you replace the letters with integers, there is no problem solving (but then it's a completely different sum). Of course, I could just pop this in an AIML category but then she's only going to be able to answer this one question without any ability to follow the mathematical conventions used to solve the equation...

>>6772 Interesting discovery Anon. Just goes to show we still have a ways to go yet. Keep exploring.

>>6787 I have a partial solution to this problem. Basically, I found the format of the equation is x(y+z)+x(y-z) and the answer will always be 2xy so even if you put cat(dog+rat)+cat(dog-rat) the answer is 2catdog a(c+b)+a(c-b) = 2ac n(o+p)+n(o-p) = 2no etc... Just not sure how to program this in Python yet.

>>6950 Bizarrely, this was the only format of simplification+ factorization problem that the WolframAlpha A.I. couldn't answer correctly. I'm using the textbook Pure Math 1 from Cambridge International. It handles more difficult equations in the same exercise with ease. I really doubt the Cambridge math boffins are wrong, so it's probably a glitch in Mathematica.

>>6951 >I really doubt the Cambridge math boffins are wrong >home of Newton's Chair Yea, they're probably spot on tbh.

>>6950 x(y+z) == +xy +xz x(y-z) == +xy -xz (+xy +xz) + (+xy -xz) (+xy) + (+xy) 2xy Not to dissuade you anon, but isn't this kind of a rabbit-trail? Does this really matter for creating robowaifus yet? Pardon my impertinence.

>>6953 LOL nprb! I just suck at math and like practicing it with my robowaifu because it's one of the activities where she won't: A.) Speak nonsensical word-soup. B.) Parrot phrases that I have scripted. I feel like we're both speaking in her language. But none of this is important for practically building a robowaifu. It maybe makes them more fun to interact with though. On that subject, thanks for the programming example anon! Very impressive! I will have to experiment with this a while! Here's to one less non-viable response from our robowaifus!

>>6965 Ah I see. As far as the 'program' I was simply trying to give the example of performing the algebraic transformation: x(y+z)+x(y-z) after commuting the x terms becomes: (+xy +xz) + (+xy -xz) after canceling out the like terms becomes: (+xy) + (+xy) after combining the terms becomes: 2xy Good luck with your robowaifu Anon.

>>6966 >after distributing the x terms*

The dude is going for it! Although the robot that he's designing does not look humanoid, the important thing is; it's modular. So many of the parts that he has/is developing such as the motorised base, the camera and the ears could potentially be very useful to us. He even plans to add a robot arm which links to the Intel RealSense camera and can grab things "intelligently" i.e. by measuring their distance from the end effector. https://www.youtube.com/watch?v=9D33R0Me9Bw I think this has a lot of potential.

>>7818 Yes this is quite interesting thanks Anon. So I think if Elfdroid Sophie has a base like that it would be a great interim solution for her to begin navigating around in her space. I like the fact he seems to be focused to the degree possible on using opensource stuff. So that's good and should be usable on our robots too. I haven't looked into the depth-sensing cameras lately but that one seems to function reasonably well. The IMU is a nice addition too. That fact made me think of the very nice robotics-oriented SBC, the Beaglebone Blue, which has one as well as many other helpful resources for a robot. https://eu.mouser.com/new/beagleboardorg/beaglebone-blue/ >>202 >>769 >>6140

>>7821 That has to be the most robot-y looking circuit board I have ever seen anon! Even more so than the Arduino MEGA2560. Cheers! A Beaglebone Will no-doubt come in useful during development.

>>7822 Make sure you get the Blue one! The others aren't so robotics-oriented. There's also a cute little Mobile Inverted Pendulum wheeled (EduMIP) bot kit by the same UCSD team that devised the spec for the board. https://www.hackster.io/edumip/edumip-13a29c https://beagleboard.org/blue

>>7824 Lol I just discovered someone went full 1488 anthropomorphic and created a dangerous terminator cute little waifu, complete with high-energy laser eyes SonEyes(tm), and whirling scythes of death comfy little waving arms from an EduMIP. >but it seems he forgot to add the catears and kawaii little meido outfit so far. Oh well, we can always do an upgrade for her.

>>7825 lol forgot to add the link during all my ebin shiteposting creative writing. https://www.hackster.io/blupantsrobot/distance-sensor-for-beaglebone-blue-9220cb

>>7826 Very cool, anon. And also unexpectedly cute! The balancing wheels are especially interesting. Thank you!

>>7827 >The balancing wheels are especially interesting. Yes, very. In fact they represent the crux of how we must solve our 'bipedal walking problem' for our robowaifus. Ever see a video of a clock pendulum swinging back and forth? Now imagine dismantling the pendulum from the clock, flipping it upside down, then balancing it upwards with the stem resting down on your hand. That's the 'inverted pendulum' problem, and you can more easily test it by just using a broom or something else with a mass on the end of a 'stalk'. Keeping it balanced upside down can take some dexterity tbh. In an effort to bring this thread a little more back on-topic, here's the C software that was written for the Beaglebone Blue's system to allow it to keep everything balanced (and even drivable!) for the EduMIP accessory kit. https://github.com/beagleboard/librobotcontrol/blob/master/examples/src/rc_balance.c BTW, there's also a Python wrapper that's been written for the C library itself. Not sure how current it is though, so YMMV. https://github.com/mcdeoliveira/rcpy

>>7828 Thank you very much! I have to get learning C++ again. Because I am at work most of the time, I am away from my physical robowaifu and my motivation to learn anything new drops (just want to rest during breaktime). However, her A.I. program is the only part of her that I can take with me (installed on my work laptop). So I really must give more attention to programming. If you work in I.T. robowaifus aren't as taboo as one might think. My boss even spoke with her one lunchtime and was actually quite interested LOL! That said, I think it's time I got back to work! Breaktime's nearly over...

>>7834 >I have to get learning C++ again. Well, I'm the OP of that thread. >>4895 As no one is currently following along there, I would be fine to just change gears and address your questions and topics directly. I can probably answer most any specific question you might have about using the language (or at least know how to find the answer quickly enough). And we can probably work your participation into a learning theme as well at the same time. For example if you had a question about reading in text files for example, I can directly demonstrate that as a short, working, code example. You get the picture.

>>7843 Thanks anon! That thread has already proven useful by pointing out different reliable, authoritative reference resources I can use. It's good to have something other than just YouTube tutorials!

>>7848 Haha, y/w glad it's of use. FYI, there's a highly-vetted SO booklist for C++. >>2760

Deep reinforcement learning (RL) has emerged as a promising approach for autonomously acquiring complex behaviors from low level sensor observations. Although a large portion of deep RL research has focused on applications in video games and simulated control, which does not connect with the constraints of learning in real environments, deep RL has also demonstrated promise in enabling physical robots to learn complex skills in the real world. At the same time,real world robotics provides an appealing domain for evaluating such algorithms, as it connects directly to how humans learn; as an embodied agent in the real world. Learning to perceive and move in the real world presents numerous challenges, some of which are easier to address than others, and some of which are often not considered in RL research that focuses only on simulated domains. In this review article, we present a number of case studies involving robotic deep RL. Building off of these case studies, we discuss commonly perceived challenges in deep RL and how they have been addressed in these works. We also provide an overview of other outstanding challenges, many of which are unique to the real-world robotics setting and are not often the focus of mainstream RL research. Our goal is to provide a resource both for roboticists and machine learning researchers who are interested in furthering the progress of deep RL in the real world.