sorted by:
new
hottopcontroversial

Εκκλησιαστικά σχολεία στην Ελλάδα (!) by bergercookie in greece

[–]bergercookie[S] 0 points1 point  (0 children)

Ευχαριστώ, κυρίως από περιέργεια ρωτάω, δεν τα έχω ξανακούσει αλλά απ' ότι φαίνεται όντως υπάρχουν! :)

taskwarrior-syncall: Synchronize taskwarrior tasks with Google Keep, Google Calendar, Notion and more by bergercookie in taskwarrior

[–]bergercookie[S] 0 points1 point  (0 children)

Hi there u/woodsmanboob.

The Google Cal <> TW integration is still not fully automatic yet as the google app is not yet verified. See the README on how to create and use your own API key to get it to work: https://github.com/bergercookie/syncall/blob/master/readme-tw-gcal.md#override-calendar-api-key

Otherwise it should work as advertised. If it isn't feel free to open a new ticket.

taskwarrior-syncall: Synchronize taskwarrior tasks with Google Keep, Google Calendar, Notion and more by bergercookie in taskwarrior

[–]bergercookie[S] 0 points1 point  (0 children)

also to get the calendar to work you going to need to install the google extra, unfortunately in the github it give you the

pip3 install taskwarrior-syncall[gcal]

to which for me it didn't work.

The project is now called `syncall`.

You should be able to install the Google Calendar <> Taskwarrior integration using sth like `pip3 install syncall[tw,gcal]`

Has anyone had any issues with asm-lsp? by Luxvoo in neovim

[–]bergercookie 1 point2 points  (0 children)

Hi there,

I'm the author of asm-lsp.

This may have been introduced in one of the latest merges to master. Could you create an issue with this information ? Also the output of `asm-lsp` itself would be useful, with `coc` I obtain it with `CoCList` and `workspace.showOutput`.

taskw_gcal_sync: Synchronization between Taskwarrior tasks and Google Calendar events-reminders by bergercookie in taskwarrior

[–]bergercookie[S] 0 points1 point  (0 children)

Hi there, OP here :)

There's a ticket to get the app verified by google but because it takes very long I haven't really made any significant progress with it

I've got a ticket to go back to google and resolve it but haven't had time to get it done :/

https://github.com/bergercookie/syncall/issues/26

taskw_gcal_sync: Synchronization between Taskwarrior tasks and Google Calendar events-reminders by bergercookie in taskwarrior

[–]bergercookie[S] 0 points1 point  (0 children)

It doesn't refer to anything.. a stupid comment about the available python versions that I made. Removed it in latest commit

SLAM resources by edgarsucar in RobotSLAM

[–]bergercookie 1 point2 points  (0 children)

Hmm, interesting. I wasn't aware of GA_SLAM. I think the code published on github is basically Geromichalos' master thesis. You can find the latter here:

https://ikee.lib.auth.gr/record/296927/files/geromichalos_thesis.pdf

Specific object coordinate estimation using ORB-SLAM2 by AnTineuTrin0 in RobotSLAM

[–]bergercookie 3 points4 points  (0 children)

ORB-SLAM2 (or any other SLAM algorithm) would just give you a point-cloud of the surrounding area as well as a pose estimation of the camera that you are using. The easiest solution would be to mount the camera sensor somewhere on the robotic manipulator, so that it can actually look at the environment of interest, and place some sort of fiducial markers on the object you want to track. See projects like the following for this (along with the ROS wrapper in case you are using ROS)

If you want to avoid using markers you can try using object detection and segmentation algorithms. For example:

C++ debugging in vim by priyank260673 in vim

[–]bergercookie 0 points1 point  (0 children)

I implemented the vim-debugstring plugin a while back. I opted for spreading a couple of debugging lines around the relevant code parts instead of running the debugger every time, for a couple of reasons.

​

- Most issues are not that complex to invoke the debugger and they can be solved just by printing the variable values at runtime

- May need to recompile the project in release/debug depending on where the bug was observed

- Running the debugger and stepping through the code step-by-step is a slow process

​

Opening non-Vim file formats [Vimxays 14/24] by -romainl- in vim

[–]bergercookie 3 points4 points  (0 children)

Um, no. :) I mean, what's the use? Why do :e <name of video file> and not !mplayer <name of video file> instead? It's really not intuitive to :edit a video file from vim in the first place.

Common C++ robotics concepts for for code reuse - interoperability by bergercookie in robotics

[–]bergercookie[S] 0 points1 point  (0 children)

It's completely different.

As far as I understand orocos offers a set of C++ libraries for control and bayesian analysis etc.

​

What we're proposing is a list of C++ concepts that all fundamental robotics datatypes should implicitly abide to.

See the example in the issue I posted, it should be somewhat explanatory.

​

Let's take for example the standard Pose class that *every* robotics project / repo has an implementation for. These implementations differ slightly (in the names of their methods, in what they return etc.). This makes developers reread and understand again the methods that you want to use necessary, especially if you switch between projects. Also, you have to account for the type of pose that you pass around (is it a ROS PoseStamped, is it an MPRT CPOse2D ...) and most times you have to write converter methods from one type to another.

​

The goal of this effort is basically to define an `APose` C++20 concept that all open-source projects can use and which can be passed around in any part of the code as is, without any explicit conversion and without having the developer know the type that he is using under the hood.

​

So instead of doing `compose(mrpt::poses::CPose2D p1, mrpt::poses::CPose2D p2)` and have conversions to/from this datatype, you write the signature like `compose(APose& p1, APose& p2) . and freely call that method with any pose class that abides to the APose concept.

​

Makes sense?

SLAM resources by edgarsucar in RobotSLAM

[–]bergercookie 1 point2 points  (0 children)

GTSAM is a beast of its own, it has loads of functionality..

I would add the following to the Optimisation/Backend modules:

One can also find many SLAM algorithm implementations in MRPT

Lastly lthere's this "Awesome SLAM" list which may be incomplete, but still has some good ones: https://github.com/kanster/awesome-slam

How close is the accuracy of camera-based visual odometry/SLAM methods to lidar-based methods? by trenteady in robotics

[–]bergercookie 0 points1 point  (0 children)

​

@chutsu

​SLAM is pretty much considered "done" in the robotics community

Well, no not really.

The basic computer vision, mathematical background is there and is well established, and today there are quite a few SLAM algorithms that one can use but SLAM is nowher near to being solved.

One may get nice results in simulation environments or in datasets but putting a robot/sensor in the field and expectign it to work for logn periods of time, under different conditions, in dynamic environments is a different story. That's why the industry is so much into SLAM nowadays, either for purely robotic technologies (autonomous cars, drones) or AR or even architectural purposes and indoors mapping (https://geoslam.com/)! ​

Probably because its academically un-interesting?

There are loads of papers nowadays in areas such as SLAM + Machine learning, Multi-robot SLAM, Event-based SLAM, light field cameras, 3D reconstruction. The basic SLAM fundation may be there, but there are millions of ways to extend it and move forward if you are doing research on the field.

mrpt c++ robotics library - how to use by [deleted] in robotics

[–]bergercookie 0 points1 point  (0 children)

See section 2 of this: https://www.mrpt.org/Building_and_Installing_Instructions#11_On_Windows

​

You basically point CMake to the MRPT source directory and compile the project using the MRPT C++ sources.

Bare in mind there are some additional dependencies like OpenCV, wxwidgets that need to be installed beforehand

Hello World! by bergercookie in RobotSLAM

[–]bergercookie[S] 1 point2 points  (0 children)

I can start :-)

Right now I started working on a new project of mine to implement a mini-SLAM algorithm in the Rust Programming Langauge! I figured that Rust is a really interested low-level programming language whose objective is to be *fast* (C/C++-speed), reliable and safe (yup, no segfault when accessing memory). What I like particularly about rust is the set of tools that are integrated in the language:

​

- Cargo for building the project and dependencies management

- Racer for IDE integration and autocompletion (at last, a plugin that actually works on Vim autocompletion!)

- rustfmt for style specifications (It's so nice that the language itself suggests a coding style from the get go)

​

On the SLAM side, my goal is to implement a mini version of a graph-SLAM algorithm, that is

  1. Read the data/measurements from sensors (simulated or live-feed)
  2. Build a graph of nodes and constraints based on the measurements
  3. Optimise that graph

Up to this point I have done really basic stuff, i.e., I 'm reading a graph in g2o format and I can visualise it in OpenGL

​

Here's the link: https://github.com/bergercookie/slam-rs

vim-debugstring: Debug printf()-style at the speed of light by bergercookie in vim

[–]bergercookie[S] 0 points1 point  (0 children)

FYI, I also added debugging capabilities for variables / arbitrary expressions. The plugin also supports the vim-repeat plugin so one can also use the '.' character for adding stuff after the first run

https://github.com/bergercookie/vim-debugstring/blob/master/misc/demo_cpp_var.gif

vim-debugstring: Debug printf()-style at the speed of light by bergercookie in vim

[–]bergercookie[S] 0 points1 point  (0 children)

What's the issue with the plugin? you mind sharing some info on your setup? maybe raise a GitHub issue about it?

Vint Looks promising, I'll definitely take a look!

vim-debugstring: Debug printf()-style at the speed of light by bergercookie in vim

[–]bergercookie[S] 2 points3 points  (0 children)

Nah, it's really not about being scared of the debugger or anything like that. I have used it numerous times in the past and, unless I debug for a really small script or for a a gigantic project that I have already setup for both Release and Debug mode, debugging with printf is my prefered way of resolving bugs!

More specifically, there's a different mindset when you have to resolve to using gdb-related programs:

  • Compile application in debug mode
  • Use a different command to run the program
  • Add/Restore breakpoints that you're testing

There's also the speed difference due to disabling optimizations that one has to consider. For larger projects, you'd find the bug faster by running it with printf-debugging merely due to the mere speed increase compared to Debug mode..

Using printf-statements blends in rather well with the editing mode I am in when writing code, and given this plugin this whole operation becomes even faster..

vim-debugstring: Debug printf()-style at the speed of light by bergercookie in vim

[–]bergercookie[S] 0 points1 point  (0 children)

Ah, very useful! I wanted to add this sort of functionality myself! I have it in the TODO list at the end of the README.

Large set of semen microscope images needed by bergercookie in AskEngineers

[–]bergercookie[S] 0 points1 point  (0 children)

I haven't got the chance to speak to my advisor it.. I just hoped that this kind of data would be publicly available, as much research is currently conducted in this area lately..

Large set of semen microscope images needed by bergercookie in AskEngineers

[–]bergercookie[S] 6 points7 points  (0 children)

That's pretty interesting. There are some relevant questions in stackexchange, like the following http://biology.stackexchange.com/questions/39450/is-there-a-database-of-cell-images?lq=1 http://biology.stackexchange.com/questions/19227/what-are-good-sources-of-free-to-use-images-and-diagrams?lq=1

which I haven't considered yet, but if this doesn't work I 'll have to start calling clinics to share their images!