@Timo

This is my project, Mighty Camera. It is essentially a monocular SLAM camera running entirely on tiny onboard compute. See my past posts for details. Mighty also supports combining multiple cameras and synchronizing them to produce frame-level synced streams. In this setup, I’m using that hardware synchronization to generate depth with SGBM, while it also produces VIO pose. submitted by /u/twokiloballs [link] [Kommentare]

I have building alternative ways explore scientifc literature. The goal was to make the large number of papers published daily easier to keep up with by visualising the macro scopic trend. It is free to use at The Global Research Space for any one interested in giving it a try! How I built it I sourced the latest 11M papers from OpenAlex and Arxiv and ecoded them using SPECTER 2 on titles and abstracts then projecting it down to 2d using UMAP and creating labels within voronoi bounds around high density peaks at increasingly deep depths. There is also support for both keyword and semantic queries, and there's an analytics layer for ranking institutions, authors, and topics etc. I have also more recently added to ability to slide back and forth in time and a daily auto ingestion script to ensure the map is up to date. Feedback or suggestions is very welcome! submitted by /u/icannotchangethename [link] [Kommentare]

Hi everyone, Posted this a while back... a checklist I made while prepping for a CV internship (landed it, hence sharing). It's not a textbook, just a phase-by-phase map of what to actually study for CV/ML interviews: math → CNNs → ViTs → detection → tracking, plus specialization tracks you pick based on the role. After checking on it after a while it got a decent number of stars which surprised and made me happy that people found it useful to save it for later. I decided after that to add more in-demand tracks to help more people after doing some research of the basic internship requirements and maybe a little more. So, just added three new specialization tracks: Segmentation, OCR, and VLMs, on top of the existing ReID and Deployment tracks. Also cleaned up the structure a bit and added proper contributing guidelines if anyone wants to add their own track (3D vision, pose estimation, etc. are open). GitHub: https://github.com/David-Magdy/CVIL Feedback/PRs welcome, especially if something's outdated or miscategorized. And remember to keep it CVIL! submitted by /u/PolarIceBear_ [link] [Kommentare]

Follow-up to the v2 trajectory post and the noise characterization experiment. v3 adds image-based visual servoing. The problem with v1 v1 tracked horizontally by steering the car body. Ackermann steering has a minimum turning radius — if the tag moves outside a cone in front of the car, the only recovery is a multi-point turn. The camera was locked forward and the car had to point at what it wanted to see. IBVS decouples the camera from the chassis. The pan/tilt gimbal tracks the tag in pixel space regardless of where the car is pointing, and the car centering logic works from the gimbal's pan angle rather than raw image error. The camera can follow a target that the car physically can't yet reach. What v3 adds IBVS core — pan and tilt are driven by pixel error feedback: eu = tag_x − cx, ev = tag_y − cy. Error is smoothed with an EWMA (alpha=0.8), a 10px deadband prevents hunting at center, and corrections are capped at 2° per frame. The result is a gimbal that follows the tag continuously rather than only when the car is pointed at it. Four operational modes — ibvs_test (gimbal only, no drive), manual_ibvs (gimbal + WASD), rat_chase (gimbal + autonomous centering + forward drive), and world_ibvs (full v2 dual-tag world frame behavior). The modes let each layer be validated in isolation before combining them. rat_chase — the autonomous mode shown in the video. Car centering derives a steering angle from the gimbal's current pan angle via a feed-forward gain, then drives forward at a configurable speed and stops at a distance threshold. The car is on a test rig in this clip so the wheels are suspended — this is a hardware-in-the-loop simulation of the drive logic before putting it on the floor. ibvs_anchor_mode world frame — tag0 alone is now enough to anchor the world frame. First detection seeds T_world_anchor; every subsequent frame derives world → car_base from that anchor and the current tag0 pose. No second tag required. The full URDF renders in RViz2 and the car trajectory publishes live. Trajectory visualizer — trajviz.py reads the PLY files output by tf_bridge and produces an interactive Plotly HTML with a color gradient over time, cubic spline overlay, and sliders for spline order and smoothing weight. What the video shows The car is suspended on a test rig — wheels off the floor — running in rat_chase mode. Pan/tilt hunts briefly at the start while the EWMA settles, then locks onto the tag and tracks it. The gimbal motion looks smooth on the car itself; some snappiness is visible in the camera output feed, which is the per-frame correction still present at the edges of the lazy band. Drive and steering commands are being issued but the wheels aren't in contact with anything. Next step is putting it on the floor and running it for real. Bugs worth mentioning TF never broadcast in ibvs_test/manual_ibvs. tf_pub.on_frame() was only called inside _do_chasing(), which the ibvs_test and manual_ibvs branches never reach — they return early. Pi was detecting the tag correctly but zero messages reached tf_bridge. Fix: added the on_frame() call directly in the early-return branch. Z filter rejecting all valid frames — twice. The first version checked car_base_pos[2] against a floor threshold; car base is at Z≈0 so every frame failed. Fixed to check camera height instead. Second version: valid camera height readings clustered just below the threshold (0.000–0.054m vs 0.055m cutoff) and still got rejected universally. Root cause was that I was physically lifting the car during testing so Z filtering is inappropriate in that context. Made the filter an opt-in ROS2 param, defaulted off. Velocity gate blocking hand-carried movement. The jump gate inherited from v2 was set at 10cm — fine for autonomous driving, but every footstep when carrying the car exceeds that. Result: 62 skipped frames in 11 seconds, 2 trajectory points recorded. Added a separate ibvs_max_jump_m param (default 1.0m) for the ibvs_anchor path. What's next Put rat_chase on the floor with the wheels down. The steering and drive logic is implemented and confirmed sending commands — it just hasn't chased anything yet under its own power in v3. That's the next session. References Post history v2 noise characterization experiment v2 trajectory post v1 tag chaser PiCar-X introduction Hardware / code PiCar-X on Amazon Git repo submitted by /u/okineedaplan [link] [Kommentare]

Following up on my last post about this robot project (which I'm currently working on with a Raspberry Pi)—I thought I'd share an update on the project's progress, since I ran into a problem that took me a bit of research to figure out, and I was also able to reflect on it thanks to the very valuable feedback I received. (https://www.reddit.com/r/raspberry_pi/s/eCKPFWwPhk) The issue While testing the 4 DC motors from the web interface, I noticed something off: sometimes the robot would suddenly lurch forward at full speed when I'd only tapped a key once, and other times there'd be a noticeable delay between pressing a key and the motor actually responding. Not a one-off glitch — happening often enough that I couldn't trust the controls. What was actually going on After digging into it, the culprit was the PWM signal I was using to control motor speed. I was using RPi.GPIO's software PWM, which relies on a Python thread toggling the pin at precise intervals to simulate the signal. The problem is that thread has to compete for CPU time with everything else my server is doing — streaming gyroscope data 20 times a second, running the radar scan, handling Flask/SocketIO requests. When the Pi got momentarily busy, the PWM timing would drift, which explains both symptoms: a duty cycle spike (sudden full-speed lurch) or a delayed update (the motor not getting the new speed in time). The fix Switched to pigpio, which runs as a separate daemon (pigpiod) in the background. Instead of my Python code generating the PWM signal itself, it just sends simple commands to this daemon, which handles the actual signal generation independently of whatever else the Pi is doing. So far the difference is noticeable — no more random speed spikes during testing. The other thing I added: a watchdog Separately, I realized there was a bigger risk I hadn't addressed: the robot is controlled entirely over WiFi through a browser. If the connection drops for any reason while it's moving forward, there was nothing stopping it from just... continuing toward whatever's in front of it. So I added a watchdog thread on the server side — it tracks the timestamp of the last command received, and if more than 500ms pass without a new one, it force-stops the motors automatically. Independent safety net, regardless of what causes the disconnect (WiFi hiccup, browser crash, whatever). what I plan to do next Mechanical redesign: dropping from 4 driven wheels to 2 front-driven wheels + a rear caster wheel, mainly to simplify trajectory control (the 4-wheel setup made it hard to drive perfectly straight) Mounting HC-020K encoders on the front wheels for actual odometry instead of relying purely on the gyroscope (which drifts over time) Eventually fusing gyro + encoder data to get a stable heading estimate Repo's here if you want to poke around: https://github.com/enzocolombat/EC-Hub Genuinely curious what people think of the pigpio + watchdog approach — is there a cleaner way to handle the real-time PWM issue I'm missing? And for anyone who's done the encoder + gyro fusion thing on a budget robot, would love to hear how you approached it before I dive in. submitted by /u/Pasteque9000 [link] [Kommentare]

Ever since the post from last time: https://www.reddit.com/r/robotics/comments/1u1iql9/cubic_doggo_update_wobbly_imu/ I have tried to implement all the suggestions from the previous posts (thank you guys :)), and then spent way too much time tuning the PID, hoping it could perfectly balance the robot without wobbling. And the first video is showing my best full PID result so far: it can achieve perfect balance, BUT with randomly occurring spasms. A bubble level is added on its head. After standing+leveling, the platform is put on a slope. The bubble shifts, and the robot is trying to adjust it back Still cannot figure out the reason after quite some updates, though, but 50Hz reading rate with ~10ms lag, and legs lifting the whole body weight while changing tiny position probably are the culprit. So maybe it really doesn't need perfect leveling; it just needs some corrections on a slope. The second video is with P-only, fast reacting and no oscillation. Maybe this is showing the limitation of PID as compared to reinforcement learning? I am not at all sure. For now, though, I still want to see how P-only leveling performs during a walk gait. Link to the previous walking post without IMU: https://www.reddit.com/r/robotics/comments/1tghftd/cubic_doggo_full_github_record_it_can_now_walk/ submitted by /u/SphericalCowww [link] [Kommentare]

Worried recruiters see "ML/AI engineer" on a resume and assume zero security depth, even with real hands on work in the space. Anyone hired into security from a non-traditional background like this — how'd you frame it? submitted by /u/Xorphian [link] [Kommentare]

I haven't revealed her name in this video because I'd like to keep that private for now. XDXD As a first test, I successfully integrated an LLM, TTS, and ASR pipeline to enable voice conversations on the robotic car, even the response latency(LLM) is still slower. As a first test, I integrated a complete voice pipeline: → Microphone → Whisper Base (Speech-to-Text) → Ollama (LLM) → Kokoro TTS (Text-to-Speech) → Speaker The system runs locally on the Jetson AGX Xavier. Response latency is still slower... However, it is already capable of holding voice conversations while moving around autonomously. Current Stack(24 June 2025) Jetson AGX Xavier Ollama(LLM) Kokoro TTS Camera system orbbec camera Microphone and speakers(whisper base) Robotic car platform Until today, I am still improving the system. Future plans may include: Live2D avatar integration (will add later) Added VLM (Vision-Language Model) Shorter-latency LLM and VLM responses Improved voice interaction Update: The platform was later upgraded to a Jetson AGX Orin. submitted by /u/Tombother [link] [Kommentare]

Trying to understand how other people make this decision. Do you compare $/hr, $/token, throughput, reliability? Is there a tool or resource you rely on, or are you just doing the math manually? Asking because I'm an ML engineer who's been doing this in spreadsheets and wondering if I'm missing something obvious. submitted by /u/Technomadlyf [link] [Kommentare]

Hi all, I'm looking for literature on relatively specific tooling. In autoregressive LLMs, there is substantial published work that used NLI on sub-claims produced by LLMs to gauge correctness of LLM answers. In diffusion (or D-) LLMs, the SoTA model generations that I see (outside of perhaps LLaDA) seem to struggle to be as correct syntactically as the generations from premier AR LLMs, in addition to the issue of semantic correctness. My intuition is that this complicates the usage of NLI (the syntactic noise). What is the SoTA on syntax-robust NLI? submitted by /u/RepresentativeBee600 [link] [Kommentare]

I've noticed something interesting while browsing ML, Data Science, and programming books. A surprising number of them have animals on the cover. Not just one or two books, but entire shelves full of them. Examples include books on Python, Machine Learning, Hadoop, Linux, Data Engineering, and many other technical topics. I was curious: - Is there any historical reason behind this? - Do the animals have some symbolic connection to the subject matter? - Did one publisher start the trend and others copied it? - Or is it purely a branding/design choice? I'm especially curious about whether specific animals were intentionally chosen to represent certain technologies or if they're mostly random. Would love to hear the story behind this from people who've been in tech longer than I have. submitted by /u/Rough-Usual-275 [link] [Kommentare]

I want to team up on a ML project, no fixed idea yet. Open to whatever's interesting: NLP, CV, time series, whatever you're into. Looking for: anyone with an idea (Or without, we can think about something togther) + ML engineer to build it with Goal: my goal is to strengthen my portfolio and collaborate Drop a comment or DM if you've got something brewing and want a hand. submitted by /u/Sea_Smile1129 [link] [Kommentare]

This question is related to topics like language+ models (including multimodal) and things like "circuit" analyses. I think something related might come up in my work (factuality guarantees for model outputs) and I'm trying to orient to the SoTA. I found this old post on trying to deduce, for instance, whether a Transformer-based model "knows" which word a token is in. Even in this simple example, I noticed some meaningful problems (I detail in a footnote1 to not derail my question) - and I've heard that circuit research is pretty fraught. The post claimed to train a logistic regression classifier. What I'm curious about is, how do you balance between the capacity of this probe, and the underlying network? Specifically, I would like to know: Is there theory which grounds inquiries of "what you can learn" in concrete terms? (Perhaps in terms of provable guarantees about overfitting? Or are there Nyquist-type guarantees available about sampling based on frequencies of patterns in language corpora - i.e., can we say we've "seen enough data" to know the network can reliably do something in all cases?) Has any of the existing work factored in attempts to label the "difficulty" of examples? (Perhaps by ensembling some training of models and looking at accuracy on them. I realize bootstrap is insanely expensive for language models due to training costs.) Problems - well, first of all, the number of possible words is so small that I suspect performance looks unrepresentatively good. The classifier seems to gain in performance for words 5/6 after weakening, but that might just be learning "all sufficiently 'extreme' tokens should be words 5 or 6." For another, despite the claim advanced in the article (Nanda concludes the network essentially does learn positions), I happen to have screenshots from recently playing with Google Gemini and asking it how many "r"s and other letters are in Google. Not only did it answer incorrectly - it claimed 1 - but more worryingly, it spelled out G-o-o-g-l-e in answering. This belies a hypothesis of "it's incapable of learning exactly how to decompose tokens, so this question was unfair from a model capacity standpoint" but *still* leads to an incorrect answer! submitted by /u/RepresentativeBee600 [link] [Kommentare]