/robowaifu/ - DIY Robot Wives

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

LynxChan updated to 2.5.7, let me know whether there are any issues (admin at j dot w).


Reports of my death have been greatly overestimiste.

Still trying to get done with some IRL work, but should be able to update some stuff soon.

#WEALWAYSWIN

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)


Welcome to /robowaifu/, the exotic AI tavern where intrepid adventurers gather to swap loot & old war stories...


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?
>>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.
Open file (54.34 KB 802x898 Confusion1.png)
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.
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.

Report/Delete/Moderation Forms
Delete
Report

no cookies?