/robowaifu/ - DIY Robot Wives

Advancing robotics to a point where anime catgrill meidos in tiny miniskirts are a reality.

Server and LynxChan upgrade done. Canary update and a general address soon. -r

Max message length: 6144

Drag files to upload or
click here to select them

Maximum 5 files / Maximum size: 20.00 MB

More

(used to delete files and postings)


Remember, /agdg/ 's Game Jam is still going on. Go Team! :D


Robot Wife Programming Robowaifu Technician 09/10/2019 (Tue) 07:12:48 No.86
ITT, contribute ideas, code, etc. related to the area of programming robot wives. Inter-process and networking is also on-topic, as well as AI discussion in the specific context of actually writing software for it. General AI discussions should go in the thread already dedicated to it.

To start off, in the Robot Love thread a couple of anons were discussing distributed, concurrent processing happening inside various hardware sub-components and coordinating the communications between them all. I think that Actor-based and Agent-based programming is pretty well suited to this problem domain, but I'd like to hear differing opinions.

So what do you think anons? What is the best programming approach to making all the subsystems needed in a good robowaifu work smoothly together?
>>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.
So we've been working towards a set of general animation, interaction, and control systems for our robowaifus here on the board for a long time now. Thanks to some recent ideas by Anon a new angle on the general effort became evident and so we'll pick it back up again with a slightly different approach. This time it's using a fictional manga database textbook as inspiration material as guidance to devise and vett robowaifu scenarios. ATM it seems likely destined to supersede the previous works. Let us see. Note: This .pdf file is actually a 7zip of the project's distribution snapshot as of r/n. By renaming the file extension to .pdf, we can successfully post it here directly on the board itself. To test the system out yourself, you need to be able to build C++ projects, and the Meson Build system is highly recommended as well. Download the pdf, rename it's extension to .7z then extract it. Inside you'll find two files, one is the primary project tarball archive (.xz), and the other is an ASCII sha256 checksum file. You can issue the command sha256sum -c <whatever each ASCII sha256 checksum file is named each time>, and you will see an OK if the tarball got to you uncorrupted. You can now extract it as well, and inside you'll find all the codefiles, and the build control file named meson.build. This is a plaintext file with build instructions included inside for both the g++ compiler, as well as the afore-mentioned Mesonbuild system. Just follow the instructions to build & execute and you'll see the basic output from the program. The system doesn't actually do much yet, just outputs some basic data for several of the system's objects to prove it's all working. The primary point of posting it here right now while it's still unfinished is to both keep a running-record of it's development 'in-situ' as it were, and also to allow any Anons interested in either learning to code mid-sized C++ projects, or how this specific system in particular works to play around with it and test things. My plan for the moment is to use this thread as the primary distribution mechanism, then to eventually make a more formal release somewhere once it's working at a fundamental level (for some definition of 'working'). Regardless, it's all MIT (Expat)-licensed, so feel free to do as you see fit with any of it (as usual). edcca7fb1e7e88ab02189c671cffcd00468200d6812c40c551a14a1c0be234d4 *kingdom_of_kod-0.0.4.tar.xz
>>12607 >main.cpp // Kingdom of Kod // ============== // -Adventures of the heroes in the 'Manga Guide to Databases' // -Filename: main.cpp // -The program's entry point, and some basic tests of overall architecture /* So for now, this is just a basic proof-of-concept for a system to support Anon's ideas around robowaifu's information access-control systems. If things proceed apace, then eventually this should finally be an interim working expression of the custom /robowaifu/ 'waifu animation and simulation' system begun long ago. It's unclear yet just how far to go specifically, since ATM this is primarily to eventually support a different, testbed, project. Still, the intent has been around for several years along with the prior works, so it's likely this will turn into a primary effort after several revisions. In particular, probably some variant of the former robowaifu code that was developed over 5 years ago will be adopted, or it's architectural paradigms revisited at the very least. Even some of our _older_ (4/g/) works may be re-conceived here who knows? Time will tell. Certainly the general work is well outside the silly namesake title adopted in this current effort. Probably just some kind of an homage to the fairybot robowaifu work begun by Anon in his thread during the first year of the board. DESIGN GOALS: ============= -Primarily, to flesh out a screenplay scripting, animation, natural interaction, AI-inferencing, etc., system. For this effort, the ''Manga Guide to Databases'' characters, scenarios, and topics act as inspiration and guidance. -Characters -Layouts -Props -Environments, Lighting, and Effects -Mesh generation for Blender -Automated CV-based sourcing for character designs directly from the manga -Properly-formatted script generation -Integrate with the RW Simulator or some other animation visualization system -Secondarily, a few technical design goals currently center around devising a JSON-based SQL database system to use with other projects, such as the robowaifu access-control AI project, and the later form of the RW simulation system. -Use JSON as the data system -Support BSON binary loading & storage -Support direct system streams via standard C++ insertion/extraction operators -Maintain an even more natural interface than the 4G language can provide -Search for even more compact data representations for embedded platforms -There will obviously be new goals that develop during the progress with the current effort, as new 'vistas yet-unexplored' open up before the adventurers themselves. Let us go forth afield & see what profound truths they uncover! :^) -Book sauce: https://nostarch.com/mg_databases.htm */ #include <iostream> #include "Action.hpp" #include "Camera.hpp" #include "Character.hpp" #include "Dialog.hpp" #include "Effect.hpp" #include "Environment.hpp" #include "Human.hpp" #include "Light.hpp" #include "Prod_log.hpp" #include "Production.hpp" #include "Prop.hpp" #include "Robowaifu.hpp" #include "Scene.hpp" #include "Script.hpp" #include "Sequence.hpp" #include "Shot.hpp" #include "Timeline.hpp" #include "rw_cli_args.hpp" using std::cout; /**----------------------------------------------------------------------------- * Print basic information about the @b Named_3D @a item * * @param item [I] * @param tag [I] * * TODO: add any add'l basic member fields display here as they are developed */ void prt_named_3d(Named_3D const& item, std::string const& type_tag) { cout << type_tag << ".name(): '" << item.name() << "'\n"; cout << type_tag << ".posn(): '" << item.posn() << "'\n"; } /**----------------------------------------------------------------------------- * The program's entry point * * @param argc [I] The CLI arguments count * @param argv [I] The CLI arguments C-string array * @return The program's exit status */ int main(int argc, char** argv) { rw::parse_args(argc, argv); cout << "Hello Anon, from the Kingdom of Kod!\n"; Human human{}; Character character{}; Script script{}; Prod_log prod_log{}; Dialog dialog{}; Action action{}; Environment environment{}; Prop prop{}; Scene scene{}; Sequence sequence{}; Shot shot{}; Light light{}; Production production{}; Camera camera{}; Effect effect{}; Timeline timeline{}; Robowaifu robowaifu{}; // perform basic round-trips to ensure member fields & functions are working /// human.name("human"); character.name("character"); script.name("script"); prod_log.name("prod_log"); dialog.name("dialog"); action.name("action"); environment.name("environment"); prop.name("prop"); scene.name("scene"); sequence.name("sequence"); shot.name("shot"); light.name("light"); production.name("production"); camera.name("camera"); effect.name("effect"); timeline.name("timeline"); robowaifu.name("robowaifu"); // TODO: add block of posn() assignments here /// prt_named_3d(human, "Human"); prt_named_3d(character, "Character"); prt_named_3d(script, "Script"); prt_named_3d(prod_log, "Prod_log"); prt_named_3d(dialog, "Dialog"); prt_named_3d(action, "Action"); prt_named_3d(environment, "Environment"); prt_named_3d(prop, "Prop"); prt_named_3d(scene, "Scene"); prt_named_3d(sequence, "Sequence"); prt_named_3d(shot, "Shot"); prt_named_3d(light, "Light"); prt_named_3d(production, "Production"); prt_named_3d(camera, "Camera"); prt_named_3d(effect, "Effect"); prt_named_3d(timeline, "Timeline"); prt_named_3d(robowaifu, "Robowaifu"); } // Copyright (2021) // License MIT (Expat) https://opensource.org/licenses/MIT
I'm pleased to say I've finally integrated robust (and fast) unit testing into the project. > I decided to go with doctest rather than Catch2 b/c convenience and speed. Basically doctest is a single drop-in header library, while Catch2 is unfortunately moving away from that. doctest is definitely faster as well. I'll be doing my first workout with the framework during this project, so ask about it little later OK? :^) https://github.com/onqtam/doctest >version.log 210827 - v0.0.5 --------------- -integrate doctest testing.cpp for basic type member tests -add hdrs_all.hpp & #include'd in rw_gen_utils.hpp -add doctest_single_define.hpp in testing/ -integrate doctest_v2.4.6.hpp -add include blanks: vision, label, resim, testing -add include blanks: phoneme, facial, viseme, kinematic, motion, planning -expand comments in rw_cli_args.hpp -rm help_exit() dead-code in rw_cli_args.hpp -spec rw::cli_app as static -add block of posn() assignments in main() -add non-working code example to main() javadoc -add TODO DESIGN to Posn file header -edit javadocs for Posn -various minor comment & javadoc edits focused on unified formatting >kingdom_of_kod-0.0.5.tar.xz.sha256sum 5ebe8533d6d39afad5bd5a3010d1336a30fac5514b1452c4d49c06b274cb9ad2 *kingdom_of_kod-0.0.5.tar.xz
>>12649 So, I just added external project dependencies links to meson.build, and realized it might help some anons to keep from thinking they needed to download+install them (they're already included in the above .pdf file), if I went ahead and posted the file's contents here immediately. >meson.build # Kingdom of Kod # ============== # -Adventures of the heroes in the 'Manga Guide to Databases' # -Filename: meson.build # -The build-management configuration for the project overall project('kingdom_of_kod', 'cpp', version : '0.0.6', license : 'MIT', default_options : ['cpp_std=c++17', 'buildtype=release', 'warning_level=3']) add_project_arguments('-Wno-unused-variable', '-Wno-unused-but-set-variable', '-Wno-unused-parameter', language: 'cpp') srcs_all = files('src/srcs_all.cpp') interns_dir = include_directories('include') externs_dir = include_directories('extern') # inc_dirs = [interns_dir, externs_dir] executable('kingdom_of_kod', ['main.cpp', srcs_all], include_directories : inc_dirs) # create a separate code testing project t = executable('testing', ['src/testing/testing.cpp', srcs_all], include_directories : inc_dirs) test('basic type member tests', t) # === # BUILDING WITH MESON (from the code directory): # -Initialize the project as a mesonbuild one (once only) # meson build # # -Build, then Execute # cd build && ninja && cd .. # build/kingdom_of_kod # # -(alternatively) Build with code testing, then Execute # cd build && ninja && meson test; cd .. # build/kingdom_of_kod # # -If you want to explore code testing options using the framework, then just # build/testing, build/testing --help, &tc. (choose some options from help) # === # NOTE: at any time you can set meson project configuration settings, but you should perform # the operation from within the project's build directory, not the code directory. EG: # cd build && meson configure -Dbuildtype=release && cd .. # executed from the terminal would ensure the project is built in release mode. # https://mesonbuild.com/Reference-manual.html # DEPENDENCIES: # As of this date in 2021, these are the sources of the 3 external dependencies # (already included in the project's codetree under extern/) # - CLI11 # https://github.com/CLIUtils/CLI11 # - JSON for Modern C++ # https://github.com/nlohmann/json # - doctest framework # https://github.com/onqtam/doctest # # While not a requirement per se, Mesonbuild is also highly recommended # - The Meson Build system # https://mesonbuild.com/ # === # BUILDING WITH g++ (from the code directory): # -Build, Execute. # g++ main.cpp src/srcs_all.cpp -Iinclude -Iextern -std=c++17 -O3 -o kingdom_of_kod # ./kingdom_of_kod # Copyright (2021) # License MIT (Expat) https://opensource.org/licenses/MIT
OK, so I've gotten the intial 'testing' hackery moved out of main() and into proper unit-testing. I've tightened things up a bit with testing, and gotten directories and meson.build ready for many, many more tests. ATM with just the single current TEST_CASE(), I have over 200 passing assertions going already. > With a project of this type, that number could easily grow to literally OVER 9'000! :^) Anyway, I feel like most of the basics are getting squared away during these first few days, so hopefully things can move a little quicker hereafter. Cheers! >version.log 210828 - v0.0.6 --------------- -add operator==() to Posn -ren 'testing.cpp' to 'test_basic_sanity.cpp' & adapt in meson.build -rm now-redundant prt_named_3d() from main.cpp -mv basic type member tests from main() over to testing.cpp -add include blanks: simulation, gui, widget, -add blanks test_animation, test_camera, test_gui, test_all to src/testing/ -add external project dependencies links to meson.build + various minor edits >s/Log.hpp/Prod_log.hpp (comment in file's header) -use 'auto& human = all_objs[0];' etc., in testing.cpp (to match test's text) -'add doctest.h to include/testing/' (correction of prior erroneous log entry) -add g++ testing build statements comments to meson.build -add the working .clang-format file directly into project's directory -various minor comment & javadoc edits >kingdom_of_kod-0.0.6.tar.xz.sha256sum 067f334adaec7f7ebc1b2f6fd32ec2592c58b2a521a50cc389ae034d8040dc26 *kingdom_of_kod-0.0.6.tar.xz
Since most of the system is ready in a basic way for TDD now, I was starting to think through some testing for the Camera class, and realized that a lot of the basic choices there depend very fundamentally on both the geometry system and the graphics rendering pipeline. These sort of define the entire approach to graphics visualization you choose, and it's pretty difficult to 'just rewrite it, bro!' if you invest a bunch of work, then decide to change ponies in the middle of the race. So, I'm on hold again while I stop and ponder whether to rework our older code, choose something like one of the big-ass major game engines (I think not tbh), or a graphics framework like SFML or OGRE. For now, I'm leaning towards OGRE-Next https://github.com/OGRECave/ogre-next Since it will probably be a few weeks before I make any new headway, I'll go ahead and push what bit I have atm here for safekeeping. Nothing much new added in this forced-release really, mostly just some blank testing stubs for unit-testing. >version.log 210830 - v0.0.7 --------------- -reorder tests as separate statements block in meson.build -add blank testing stubs for test_gui, test_camera, test_animation -ren both 'testing' dirs to 'code_testing' & adapt in meson.build -mv label & resim to training -add include blanks: training, auto_label, guided_label -add consts & noexcept in Posn -use 'this' member field access to fix param naming in Posn::assign() -move to member function for operator==() in Posn instead -minor edits to meson.build -various minor comment & javadoc edits >kingdom_of_kod-0.0.7.tar.xz.sha256sum 2c0785b1c495b0e45c73390899c3d297efaa3d07bd84162906feaab5263904cc *kingdom_of_kod-0.0.7.tar.xz as always, just rename the .pdf extension to .7z then extract files. build instructions are in the meson.build file.
Open file (413.57 KB 1178x1019 juCi++_012.jpg)
Not really about programming per se, but I stumbled on some better code tags to use here (>>11554) that render out quite nicely in Juci++. As will all javadocs, Juci will pop up a tooltip window whenever you hover over commented items. It does a better job than average on these types of tags and adds a bit of type highlighting. > Nothing spectacular, but it's a nice little tip to know. Cheers.
A video on adaptive motion smoothing using arduino. https://youtu.be/jsXolwJskKM
>>12736 Grabbing it now, thanks Anon!
>>12736 Had a look, it's quite good information Anon thanks again.
So, in dealing with the examining of all these different graphics & simulation frameworks over the past few days, I discovered there were some fundamental gaps in my own understanding of class hierarchies that I just assumed I had already mastered a while back. Derp. So, since this is the basics I cracked the books on, well, the basics. Chapter #14 of Bjarne's PPP2 begins diving into these topics overall and is the right place to start for me. > OTOH, now that I've also got unit-testing working for all my systems, I didn't want to just rely on a hodge-podge of 'tests' strewn together that has been my wont thus far. Accordingly, I added all the new testing harness stuff into a new basic, empty project so that real unit-tests could be done along the way for things I've just ass.u.me 'd before starting this re-research effort. While I was assembling it together, I realized that not only would I probably want a copy of this 'blank' project to use for all new future projects, but that Anons might want to use it too. And regardless (as with everything else important to my robowaifu-related efforts) I had better keep a copy of it up on /robowaifu/ itself for safekeeping (Robi's and BUMP 's archives of the board and such). >tl;dr So anyway here's a blank basic starter project in C++ that already has the doctest unit-testing framework, and everything all wired up in the meson.build file. Cheers. >ch14_all-0.0.1b.tar.xz.sha256sum 797e834fff5e8a6e7543e0fd19602f2ccfda68fb80c62152b3c779589ab470ac *ch14_all-0.0.1b.tar.xz as always, just rename the .pdf extension to .7z then extract files. build instructions are in the meson.build file.
>>12826 Just in case newcomers to programming find my silly """tests""" confusing, I added the first specific test case from the official tutorial page into it as well. Just replace the contents of test_basic_sanity.cpp with this code then rerun. Hopefully it will make more sense to you then Anon. The original wonky stuff I put in was just placeholders (but actual working ones). >test_basic_sanity.cpp // -Filename: src/code_testing/test_basic_sanity.cpp // -The definitions of a few basic tests #include "code_testing/doctest.h" //------------------------------------------------------------------------------ // Perform some simple tests; just do a few basic sanity checks. // TEST_CASE("A foo of bar will foo bar foo") { // REQUIRE("foo" == "foo"); //////// SUBCASE("A bar of baz will bar baz bar") { // REQUIRE(true == true); } //////// SUBCASE("A baz of baq will baz baq baz") { // REQUIRE(42 == 42); } } //------------------------------------------------------------------------------ // from the tutorial // int factorial(int number) { return number > 1 ? factorial(number - 1) * number : 1; } //------------------------------------------------------------------------------ // from the tutorial // TEST_CASE("testing the factorial function") { CHECK(factorial(0) == 1); CHECK(factorial(1) == 1); CHECK(factorial(2) == 2); CHECK(factorial(3) == 6); CHECK(factorial(10) == 3628800); } // doctest tutorial // https://github.com/onqtam/doctest/blob/master/doc/markdown/tutorial.md
Lol, I forgot the "Don't use unsigned. ever" rule, figuring to keep from having negative-radius Circles, and got bit in the ass by it. Code testing helped me find and (simplistically haxxord) "fix" it. >Circle.cpp snippet //------------------------------------------------------------------------------ auto Circle::radius(int const radius) noexcept -> decltype(bool{}) { // prevent "silly" mistakes (PPP2 p 493) if (radius < 0) // DESIGN: write error log entry too return false; // cerr << "radius_ before : '" << radius_ << "'\n"; radius_ = radius; // cerr << "radius_ after : '" << radius_ << "'\n"; // cerr << " |> exiting Circle::radius(const unsigned int radius)" << endl; return (radius_ == radius); } >test_basic_sanity.cpp snippet //------------------------------------------------------------------------------ TEST_CASE("Basic Circle class tests") { Circle circlea{Point{1, 2}, 3}; Circle circleb{Point{4, 5}, 6}; Circle circlec{Point{1, 2}, 3}; REQUIRE(circlea != circleb); REQUIRE_FALSE(circlea == circleb); REQUIRE(circlea == circlec); REQUIRE_FALSE(circlea != circlec); SUBCASE("Circle radius' can be assigned to after construction") { REQUIRE(circlea.radius(42)); REQUIRE(circlec.radius(9'001)); } SUBCASE("Assigning a negative value to a Circle radius returns a false") { REQUIRE_FALSE(circleb.radius(-42)); REQUIRE_FALSE(circleb.radius(-9'001)); } SUBCASE("Assigning a negative value to a Circle radius won't change it") { auto init_val{circleb.radius()}; // the initial, non-negative radius value circleb.radius(-42); REQUIRE(circleb.radius() == init_val); // change rejected circleb.radius(-9'001); REQUIRE(circleb.radius() == init_val); // change rejected } } Probably a better way to deal with this issue, but I'm OK ATM with this approach as tests will probably smoke out any issues that pop up over it.
>>12856 Durr. After a short break, I realized that by reverting the passed parameter type to int rather than unsigned I broke the working invariant for the Circle class that would prevent downcasting to an int argument for an initializer list (which is the form of member field initialization I always use). Thankfully, C++ allows ternery operators in field's initializers, which made the fix easy: >Circle.cpp snippet Circle::Circle(Point const& axis, int const radius) : axis_{axis}, radius_{radius >= 0 ? radius : 0} {} Testing was pretty similar to the form used for catching the issue with the assignment function. >test_basic_sanity.cpp snippet SUBCASE( "Trying to construct a Circle with a negative radius defaults to a zero " "radius instead") { Circle foobar{Point{1, 2}, -42}; // bad radius value attempted REQUIRE(foobar.radius() == 0); } Thanks for reading my dev blog be sure to like and upboat! :^)
Discovered this remarkable library from studying OGRE's Matrix3 code. https://www.geometrictools.com/
>>12901 Thanks, but this belongs into the tread for actuators. Someone posted the video somewhere already, in some other thread. You can see all the existing threads by looking into the >>catalog thread, maybe bookmark it.
Hi OP, thanks for your post it's a very pertinent topic for us. However, it's not really something that bears it's own thread, but is really about a nice programming hack. I'll be merging this soon into our Robot Wife Programming thread >>86, where MeidoDev agrees with you about it's value. Please continue sharing here with us, but you might check the catalog first before making threads as Anon suggested.
>>12826 LOL. So, I discovered I need to back up yet again what's that four, five times now? as I tried to work through Bjarne's code and integrate it with modern FLTK (currently v1.3.7) . Not to denigrate the great Bjarne Stroustrup (after all his work will literally enable us to eventually build our own robowaifus here), but tbh his code for the GUI chapters is a bit of a hot mess. From my perspective, once a student reaches chapter 12 of a textbook, it's time to 'take the training wheels off'. :^) The issue is his approach to simplifying things with the special file std_lib_facilities.h, and all that that implies. Meanwhile, FLTK has continued to improve, and isn't perfectly compatible with Bjarne's textbook code, so things break OOTB now. I had already worked out a simple way for us to use FLTK in an easy-to-use way here years ago, and so I'm going to focus instead on integrating Bjarne's code into my own code instead. That way I know we will have code that a) actually works OOTB, and b) have a guaranteed current FLTK/Modern C++ base from which to build & test it all from. Make sense? Anyway, I'm calling it the RW Windowing System creative I know right?, aka #RobowaifuAlwaysWins :^) > Cheers. >version.log snippet // RW Windowing System // =================== // -The software testbed for adapting RW systems to use the FLTK GUI backend // -Filename: version.log // -General log of the project's changes over time 210908 - v0.0.1 --------------- -original design work begins >rw_window-0.0.1.tar.xz.sha256sum b69a0309113b4774e2191b53a8d14f666a03e5e3d38de4c43e76a99dcda3e922 *rw_window-0.0.1.tar.xz as always, just rename the .pdf extension to .7z then extract files. build instructions are in the meson.build file.
>>12933 The meson.build file has been extensively updated to reflect the new testing approach, and also includes updated instructions for FLTK as well. I include it here: >meson.build # RW Windowing System # =================== # -The software testbed for adapting RW systems to use the FLTK GUI backend # -Filename: meson.build # -The build-management configuration for the project overall # ======= # General build system & compiler setups: # project('rw_window', 'cpp', version : '0.0.1', license : 'MIT', default_options : ['cpp_std=c++17', 'buildtype=release', 'warning_level=3']) add_project_arguments( # '-Wno-unused-but-set-variable', # '-Wno-maybe-uninitialized', # '-Wno-unused-parameter', '-Wno-unused-variable', '-Wno-unused-function', '-Wno-missing-field-initializers', language: 'cpp') # === # Project-specific code setups: # srcs_all = files('src/srcs_all.cpp') interns_dir = include_directories('include') externs_dir = include_directories('extern') # incls_all = [interns_dir, externs_dir] cpp_ = meson.get_compiler('cpp') lib_fltk_dep = cpp_.find_library('fltk') # deps_all = [lib_fltk_dep] # === # Everything's ready to go, so build the actual project itself: # executable('rw_window', ['rw_window_main.cpp', srcs_all], include_directories : incls_all, dependencies : deps_all) # === # Also build some separate code testing projects too: # test_basic_sanity = files('src/code_testing/test_basic_sanity.cpp') executable('test_basic_sanity', [test_basic_sanity, srcs_all], include_directories : incls_all, dependencies : deps_all) # === # This one will be run as well, if 'meson test' is also called (see below): # test_all = files('src/code_testing/test_all.cpp') all_tests = executable('test_all', [test_all, srcs_all], include_directories : incls_all, dependencies : deps_all) # test('run all test checks', all_tests) # ======= # BUILDING WITH MESON (from the project's base directory) # # -First, initialize the project as a meson build one (needed one-time only): # # meson build # # -Build, then execute: # # cd build && ninja; cd .. # build/rw_window # # -(Alternatively) build with code-testing as well, then execute: # # cd build && ninja && meson test; cd .. # build/rw_window # # -If you want to explore various code testing ideas with the doctest framework, # then run (just choose various options from the test program's help, &tc): # # build/test_basic_sanity # build/test_basic_sanity --help # === # NOTE: You can set meson project configuration settings any time, but you should # perform the operation within the project's build dir, not the code dir. EG: # # cd build && meson configure -Dbuildtype=release && cd .. # # executed from the terminal would ensure the project is built in release mode. # ======= # DEPENDENCIES: # As of this date in 2021, here is the source of the 1 'built-in' external # dependency (no system installation required, already included in the # project's codetree under the 'extern/' directory) : # # - doctest framework # https://github.com/onqtam/doctest # # Additionally, there is an external dependency that you will need to install on # your system as well. Again, here is the source of the 1 'not-built-in' # external dependency that you'll need to install first. Generally, these are # provided by your system's (or some other) package manager. But if not you can # clone the repo and build it locally (often a good choice anyway, perf-wise): # # - FLTK # https://www.fltk.org/ # # And while not a requirement per se, Meson Build is highly recommended (it will # also need to be installed separately): # # - The Meson Build System # https://mesonbuild.com/ # ======= # BUILDING WITH GCC (from the project's base directory): # # -Build, then execute: # # g++ rw_window_main.cpp src/srcs_all.cpp `fltk-config --ldflags` \ # -Iinclude -Iextern -std=c++17 -O3 -o rw_window # ./rw_window # # -(alternatively) build code-testing (only), then execute: # # g++ src/code_testing/test_all.cpp src/srcs_all.cpp `fltk-config --ldflags` \ # -Iinclude -Iextern -std=c++17 -O3 -o test_all # ./test_all # ======= # https://www.fltk.org/doc-1.3/intro.html # https://mesonbuild.com/Reference-manual.html # Copyright (2021) # License MIT (Expat) https://opensource.org/licenses/MIT
So, it sort of dawned on me that since no one's commented on my work, that no anon is actually following along atm. :^) > "Why is that?" I ask myself. > "Maybe all this is too confusing." I answer myself. Accordingly, before I work through repairing/integrating Bjarne's 5 GUI chapter's code from PPP2, I figured it might help any potentially-interested-but-intimidated-ATM anons who actually want to become coders and follow along with what we're doing here on /robowaifu/. Since getting FLTK running can be a bit of a bear for the novice, I decided that I could create the most basic FLTK window project, using just the absolute bare minimum I consider to be feasible. So here we go Anon, four code/project files just for you: Here's where it all starts, in main() . >base_window.cpp #include "Window.hpp" int main() { Window win{742, 442, "RW Always Wins"}; return win.display(); } What's an object without it's description? >Window.hpp #pragma once #include <FL/Fl.H> #include <FL/Fl_Double_Window.H> class Window : public Fl_Double_Window { public: Window(int const w, int const h, char const* label); int display(); }; You've gotta tell the class how to actually do stuff too. >Window.cpp #include "Window.hpp" Window::Window(int const w, int const h, char const* label) : Fl_Double_Window{w, h, label} {} int Window::display() { this->show(); return Fl::run(); } And finally, last of all the build. >meson.build project('base_window', 'cpp', version : '0.0.1', license : 'MIT', default_options : ['cpp_std=c++17', 'buildtype=release', 'warning_level=3']) interns_dir = include_directories('include') cpp_ = meson.get_compiler('cpp') lib_fltk_dep = cpp_.find_library('fltk') executable('base_window', ['base_window.cpp', 'src/Window.cpp'], include_directories : interns_dir, dependencies : lib_fltk_dep) Admittedly, this last file is a bit of overkill if you're just going to build something as simple as this. But tbh, it's not all that complicated. If you can read Python, then you can certainly read this, b/c after all it's Python lol. All I can say is that if you've ever had to deal with the nightmare of say, the Win32 API and drawing a basic window, then the straightforward simplicity of this code is pure pleasure. And it's also tough to convey to the newcomer to all this just how beneficial having a super-light framework such as FLTK is on low-end hardware, etc. This code could literally run blazing fast on an Arduino Nano attached to an LCD display, and do it in a very tiny compiled-footprint too. Hope this helps someone here /robowaifu/, Cheers. >base_window-0.0.1.tar.xz.sha256sum 91d57314748aa808b1336c7ad6bdccd5edc595c3a8dbfe4ba3c7e99dac6a13f1 *base_window-0.0.1.tar.xz as always, just rename the .pdf extension to .7z then extract files. build instructions are in the meson.build file. Also, just in case someone simply refuses to trust the whole 'rename the file to 7z' scheme I'm currently using just so that we can actually keep the codes here on the board itself, here's a previously-typical catbox link too: https://files.catbox.moe/fkdje9.pdf >=== -edit footprint comment -patch East-const in Window.cpp
Edited last time by Chobitsu on 09/09/2021 (Thu) 20:16:52.
>>12933 OK, I've gotten the initial refactorings worked out where the first example from ch12 is running. That was the hard part, so hopefully it will be pretty smooth sailing here out. I'm going to actually go over to the Modern C++ teaching thread with this project since it's really more about the language itself for this effort. But I want to stash what I have here for safekeeping for now. Cheers. 19f86e54b50b6e0bf905e8fd86a2252ad826f7587564511126ded3c6f2e04e57 *teaching_thrd-0.0.1.tar.xz
>>12933 OK, I've launched the new project over in the other thread now. (>>13062)
Open file (172.14 KB 1506x1284 EGMcMAQU0AAhz9L.jpg)
I don't know dick about programming, but I recently remembered seeing something about a guy putting a tracking device on his cat to monitor how it moves around outdoors and it really closely resembled something called a "Lévy flight", and there's a "Lévy flight foraging hypothesis" suggesting that animals switch between using it to optimize searching efficiency and brownian motion. I was thinking about how robots could use it for realistic behavior for exploring and mapping out its environment. I keep trying to think-up other ways this could be used but keep drawing a blank. I just wanted to get it off my mind.
RW Foundations : A suite of robowaifu libraries A software library is composed of parts that are all intended to cooperatively work together in an interrelated way. This uniformity helps the men developing the code to reason more easily about the different parts of it, as they tend to have a standardized way of interfacing together with each other. Developing them all 'in concert' under the same 'umbrella' library suite also brings an additional benefit organically; they all work together correctly. Different pieces of software that are developed entirely independently usually take a fair amount of effort to be able to 'convince' them to 'talk' to each other correctly. That's not the situation if they are designed in situ to do so beforehand. Additionally, even if one part of the RW Foundations libraries is mostly focused on a specific category of application (eg; Bumpmaster, or Waifusearch), folding those into the overall library will ensure that when the time comes, our robowaifus can also run this same software for us all by themselves. After all, the interfaces of the different library components are by definition meant to work together cooperatively. So, when we reach a level where a functioning robowaifu needs to use Bumpmaster or Waifusearch, she'll be able to do so with very little extra effort on the part of the men developing her. Thus was born the need for a 'library of libraries'. This is why we've taken some pains and care with the software architecture, and establishing these standards and protocols right up front is important. You should expect that the RW Foundations code will be an intrinsic part of most all projects going forward here. Additionally, we'll need to ensure reliability in our systems. The first step towards that end is understanding what is happening within our robowaifu's systems (particularly as we are devising and building those systems). To that end, we're providing a tagging mechanism; a 't_tag' (Tip Tag) that allows clear accountability of which component is acting/communicating with any other part. These must be easily-identifiable humanly speaking, and unique across the entire system. We also need to provide great flexibility. To that end, we're allowing for an architectural design that allows any class object to 'embed' any other class type object within itself for direct and 'personalized' functional access to it's services. This is actually a bit tricky to accomplish. For example think about what's happening inside the computer's memory if we were to simply naively say "OK, Class A, you embed Class B. Class B, you embed Class A". Segfault-city tbh. Yet that's exactly the kind of thing we need to allow for to provide maximum flexibility in our designs. The RW Foundations architecture provides for this in a simple, efficient, and direct way through base-class indirection and type-casting. We'll also need to provide a way for access into deeply-nested class hierarchies. Say, if one item in one part of the system needs to 'reach out' to something in another, remote part of the system to gain access to use it's services. For example, remote network access that is decoupled from the main system will require this sort of callgraph-chained approach to be both manageable and reliable. Providing a simple, direct way to achieve object callgraphs of this sort is needed, or they can quickly explode into a gigantic and unmanageable network that's infeasible to design well or to debug effectively. Not to mention even run on small-footprint hardware. Again, The RW Foundations architecture provides for this by the exact same approach; embedding other objects directly within an object, and providing for any-to-any relationships between them all. Two birds, one stone. :^) >(pt 1 of 2) >=== -split large post up -minor prose & grammar edits
Edited last time by Chobitsu on 11/21/2021 (Sun) 18:38:18.
>>14353 Abstraction and Modularization We need to take generalized scenario human concepts, for example "Sumomo, can you find great bathing software for us please?", and turn that into a series of concrete steps for the robowaifu that actually allow her to perceive, understand, plan, and execute on the request. This is a vastly more complex undertaking than an uninitiated newcomer might reckon on, since they commonly tend to personify many things around them. In particular, it's often hard for them to discern why something so obviously human-like as a robowaifu would have any difficulty performing this (highly complicated) task. After all, isn't it just 'common' sense? Get on the Internet and do a search right? Tackling a problem like this requires us to 'divide-and-conquer' the different parts up if we hope to succeed at solving it. This 'Abstraction and Modularization' is the very heart of the human aspect of software & hardware engineering, regardless of the other tools used. In the words of the authors of The Elements of Computing Systems (>>14338), >"You may wonder how it is humanly possible to construct a complete computer system from the ground up, starting with nothing more than elementary logic gates. This must be a humongous enterprise! We deal with this complexity by breaking the system into modules. Each module is described separately, in a dedicated chapter, and built separately, in a standalone project. You might then wonder, how is it possible to describe and construct these modules in isolation? Surely they are interrelated! As we will demonstrate throughout the book, a good modular design implies just that: you can work on the individual modules independently, while completely ignoring the rest of the system. In fact, if the system is well designed, you can build these modules in any desired order, and even in parallel, if you work in a team. >"The cognitive ability to “divide and conquer” a complex system into manageable modules is empowered by yet another cognitive gift: our ability to discern between the abstraction and the implementation of each module. In computer science, we take these words concretely: abstraction describes what the module does, and implementation describes how it does it. With this distinction in mind, here is the most important rule in system engineering: when using a module as a building block—any module—you are to focus exclusively on the module’s abstraction, ignoring completely its implementation details. (pp 28-29) While their project's design intent is rather different than this one's, these fundamental concepts of abstraction & modularization will be vital if we are to succeed at this grand venture. Providing abstractions for concrete computing tasks within and without a robowaifu, and building those large tasks from the ground up piece-by-piece, using interoperable software and hardware modules & components, is the basic plan going forward. Breaking down conceptual ideas into the different RW Foundation libraries & classes, and then allowing each and every one of these to freely call on all the others is the intended approach we're taking here. This allows us to focus on and think about just a few small parts of the overall problem at a time, without having to keep the entire system in our minds at once. Function-level access-control The primary goal behind the Tip tagging, is to provide a convenient mechanism to validate 'who-is-who' from one function to another across the entire system. However, in addition to the basic idea of tracking flows of the complex callgraphs, it also affords us a minimum degree of access-control, function-to-function. This should help provide another level of assistance to avoid unintentional misuse of function calls, and to help us write more predictable code. Perfection is unachievable in this life of course. :^) But hopefully using this approach of embedding tags for passing/checking inside calls (and widely throughout the system) can assist us all in our goals for reliable, predictable robowaifu software (whatever it's intended usage). I plan to also keep a close eye on the compute costs involved for this basic access-control mechanism, with an eye to ensuring it runs smoothly on SBCs and microcontrollers. Since it's all C++/C code start-to-finish, it should stay fairly efficient as long as we keep an eye on things, and do our jobs well. Future plans for the Sumomo effort are to begin implementing both the basic function-level access-control mechanisms described, and also a 'channel' mechanism to both maintain the state of (and reduce the pointer-chasing indirections of) to help reduce the resource costs involved with the setup/teardown common to system callgraphs. Hopefully I'll have progress along these lines by the end of this year. >--- To that end, I've taken an initial pass at implementing some of the basic architectural approaches outlined here. I've also created a simplistic (but working) test-harness project to prove out 3 of the fundamental aspects of the system's architectural design: - Every object's t_tag is unique within the system - Base-class indirection avoids an 'infinite member-objects' cycle - Working callgraph chain, 4-deep > Just follow the standard protocols for extracting/building/running the project, common to all our software projects here. A 'readme.txt' is embedded in the archive file itself to help get you started. I'll plan to release the more generalized version of Sumomo that includes some basic class declarations/definitions to begin fleshing out the interrelationships more clearly. This should happen next weekend, to help celebrate the 5th birthday of /robowaifu/ coming up. Cheers. >rw_sumomo-v211121.tar.xz.sha256sum b814041ea0b347ced9ff3ef284d72f5625ad075897e9a68adc2aebd732f10e27 *rw_sumomo-v211121.tar.xz >backup drop https://files.catbox.moe/xh6b3j.7z >(pt 2 of 2) >=== >minor spelling edit >add the single word 'great'
Edited last time by Chobitsu on 11/21/2021 (Sun) 19:25:12.
>>14353 >>14354 I discussed the Tip tagging concepts, but I didn't actually demo any usage of it from a caller/receiver. I added a 4th test that demos basic self-tests (potentially for access control, etc.) >rw_sumomo-v211121.tar.xz.sha256sum ce1246817cb3556fac7a32cb954ff89bf49c34ce67459e550d07c3aa04820b67 *rw_sumomo-v211121.tar.xz >backup drop https://files.catbox.moe/31zxct.7z
>>14354 Thank you, this sounds very exciting. I just wonder how hard it will be to understand how it works. Also, I'm currently working on the hardware and won't look into my software anytime soon. But glad to see that there's some progress. Looking forward to see an example for using output from some GPT-like network and then letting a parser work with that data, or several doing that in parallel.
Open file (108.61 KB 400x399 Sumomo.gif)
>>14354 You've written a lot and I mostly agree with your object oriented stance. I appreciate that you are working with C++ as it is rather efficient for an object oriented programming language. I program in Java and Python (blame my uni, it's all they teach) but, have wanted to try C++. >Commonly tend to personify many things around them This is a major problem indeed. Hopefully this project fixes that problem by providing anons with clarity on how robotic minds actually work. I infer from the title of this project that you're planning on building a Sumomo Tan? If so, know that you have frens that will help.
>>14360 >Thank you, this sounds very exciting Y/W. Yes, I agree. I've spent quite a bit of time making things this 'simple', heh. :^) >I just wonder how hard it will be to understand how it works. Well, if we do our jobs perfectly, then the software's complexity will exactly mirror the complexity of the real-world problem itself whatever that may prove to be in the end. However, in my studied opinion that's not how things actually work out. I'd suggest a good, working solution will probably end up being ~150% the complexity of the real problemspace? Ofc if you really want to understand it, you'll need proficiency in C++ as well. I'd suggest working your way through the college freshman textbook known as 'PPP2', written by the inventor of the language himself, if you decide to become serious about it (>>4895) . Good luck Anon. >>14361 >as it is rather efficient for an object oriented programming language. I agree it certainly is. But it's also a kind of 'Swiss Army Knife' of a programming language. And in it's modern incarnation handles basically every important programming style out there. But yes I agree, it does OOP particularly well. >but, have wanted to try C++. See my last advice above. >Hopefully this project fixes that problem by providing anons with clarity on how robotic minds actually work. If we do our jobs well on this, then yes, I'd say that's a real possibility Anon. Let us hope for good success! >I infer from the title of this project that you're planning on building a Sumomo Tan? Indeed we are. Those CLAMP girls knocked it out of the park with the character of Sumomo. She's the perfect fun little mobile-unit-robowaifu! :^) >If so, know that you have frens that will help. That's encouraging to hear Anon. Thank you. === -Added 'operator==()' for doing a deep equality check for comparing Tips, field-by-field. > >rw_sumomo-v211122.tar.xz.sha256sum 403e3905900c01f7d6b8b32263aad6b5c427e408f42ca0a3fa43966df6504e90 *rw_sumomo-v211122.tar.xz >backup drop: https://files.catbox.moe/zj3hwa.7z
OK, I added another class that implements the ability to explicitly and completely specify exactly which embedded member objects to to include during it's construction. This could be a very handy capability to have (and a quite unusual one too). Imagine we are trying to fit RW Foundations code down onto a very small device. The ability to turn off the memory footprint of unused fields would be valuable. However, the current approach 'complexifies' lol is that a word? :^) the initialization code a good bit, and probably makes maintenance more costly going forward as well (an important point to consider). I'm satisfied that we have solved the functionality, but I'll have to give some thought to whether it should be a rigorous standard for the library code overall, or applied only in specific cases in the future. Anyway, here it is. There's a new 5th test for it as well. === -add specified member instantiations > >rw_sumomo-v211122.tar.xz.sha256sum 61ac78563344019f60122629f3f3ef80f5b98f66c278bdf38ac4a4049ead529a *rw_sumomo-v211122.tar.xz >backup drop: https://files.catbox.moe/iam4am.7z
>>14353 >related (>>14409)
leaving this here Synthiam software https ://synthiam.com/About/Synthiam
Mathematically-formalized C11 compiler toolchain the CompCert C verified compiler https://compcert.org/ >publications listing https://compcert.org/publi.html

Report/Delete/Moderation Forms
Delete
Report