I built a small web app that lets you run tabular foundation models (currently just Google's TabFM) on spreadsheets without writing any code. Just drop in a CSV/Excel file, click a column header to mark what to predict, hit predict. Rows where the target cell is filled become the in-context examples and empty ones get predicted, right on the grid. A lot of people who'd benefit from these models aren't programmers, so I wrapped it in a UI anyone can use :) Repo: https://github.com/LckyLke/TabFMLabs Feedback very welcome! submitted by /u/Lckylke [link] [Kommentare]
try it right now without installing anything. the fiftyone app is running in a hugging face space for the first time (its a bit hacky atm, but working on polishing it up) space: https://huggingface.co/spaces/harpreetsahota/fiftyone-app full walkthrough: https://voxel51.com/blog/view-mcap-files-fiftyone submitted by /u/datascienceharp [link] [Kommentare]
Call for Papers and Demos Real-Time Conversational Agents (RTCA): Toward Natural Multimodal Interaction 1st RTCA Workshop [@]() NeurIPS 2026, Sydney, Australia 11 or 12 December 2026 Website: https://rtcaneurips26.github.io/ We are pleased to share the Call for Papers and Demos for the inaugural RTCA Workshop at NeurIPS 2026, focused on real-time multimodal conversational agents: streaming speech, video, and language generation; naturalness in interaction; and evaluation of live systems. Conversational AI has moved from text chat into the real world, voice modes that talk back, embodied avatars, agents that share our screens and tools. To feel natural, these systems must operate in real time, streaming while continuously listening, watching, and re-planning. This is fundamentally harder than offline generation: latency, turn-taking, backchannels, interruptions, and cross-modal alignment become first-class problems that the offline paradigm sidesteps. Recent progress on full-duplex speech–language models, real-time talking-head generation, and streaming ASR shows the regime is feasible, but the field still lacks shared benchmarks, vocabulary, and methodology for interactional naturalness. RTCA brings together researchers across speech, vision, language, HCI, social-signal processing, and ML systems around three intertwined questions: real-time generation under hard latency budgets, naturalness in interaction, and evaluation of live systems. Topics of Interest We invite original contributions on topics including (but not limited to): Streaming/low-latency speech synthesis, ASR, and full-duplex audio–language models Real-time talking-head, avatar, and embodied video generation; lip-sync, gaze, expressivity under streaming Streaming language models; incremental and speculative decoding for dialogue Turn-taking, backchanneling, interruption handling, and floor management Multimodal alignment under latency and partial-observation constraints Prosody, emotion, and paralinguistic generation in interactive settings Memory, grounding, and tool use during live conversation Evaluation of naturalness: perceptual studies, turn-taking metrics, perceived latency, interactive Turing-style tests Datasets and benchmarks for interactive (not offline) evaluation Efficient inference, on-device deployment, and the systems–quality trade-off Safety, identity, and trust in real-time agents (deepfakes, persuasion, consent) Submission Types We welcome: Full papers (up to 8 pages) — may be presented as posters and/or contributed talks. Short papers (up to 4 pages) — work in progress or focused contributions. Demo papers (Extended Abstracts or up to 2 pages) All submissions must use the NeurIPS 2026 style file and be formatted for double-blind review. Page limits exclude references and appendices. Papers must be submitted in PDF format via OpenReview (portal link to be published on the workshop website). The workshop is non-archival; authors retain the right to publish elsewhere. Important Dates (End of day, Anywhere on Earth) Call for papers opens: 18 July 2026 Submission deadline (papers and demos): 29 August 2026 Author notification: 29 September 2026 Workshop date: 11 or 12 December 2026 Organisers Niki Foteinopoulou — Tavus, United Kingdom Alessandro Conti — Tavus, Italy Jack Saunders — Tavus, United Kingdom Oya Celiktutan — King's College London, United Kingdom Cigdem Beyan — University of Verona, Italy Ioannis Patras — Queen Mary University of London, United Kingdom For more information, visit our website https://rtcaneurips26.github.io/ or contact us at [rtca-workshop@googlegroups.com](mailto:rtca-workshop@googlegroups.com). We look forward to your contributions! submitted by /u/Few-Ferret9700 [link] [Kommentare]
Hey everyone, We've been building Miu — an embodied AI agent on a Yahboom Raspbot-style platform (Raspberry Pi, mecanum wheels, RPLidar C1, PTZ camera, ultrasonic bumpers). After a lot of wiring and debugging, V2 is working enough that he can autonomously drive around inside a room without us manually joysticking every move. What's working: • LiDAR-based room scanning + obstacle avoidance • Holonomic mecanum control (strafe, not just diff-drive spin-in-place) • Ultrasonic as a "digital bumper" for stuff LiDAR misses (cables, furniture edges) • Live 3D viewer (Rerun) so we can actually see what the robot thinks • Backend orchestration: LLM plans missions, a separate executor drives the motors Nav2 / ROS 2 helped a lot as a reference stack and for A/B testing navigation — though our production path on the Pi is leaner (FastAPI + custom holonomic controller). Nav2 taught us the patterns; shipping meant ripping out a lot of complexity. What almost killed the project (real talk): Too many cooks on cmd_vel — vision pipeline, proximity reflex, room scan thread, teleop, and agent tools all wanted to move the robot at once. Classic race conditions. LiDAR serial lock — Nav2 container + our own LiDAR reader + live viewer polling the same serial port = chaos. Had to enforce one LiDAR reader and stop competing services. Control-loop bug — we were doing LiDAR HTTP calls inside the 10 Hz drive loop. Robot spun in circles after ~2 ticks. Decoupled sensor thread (LidarScanBuffer) from control thread — fixed immediately. Observability nightmare — logs split across Pi journal, movement_log, PM2 JSON (multi-GB…), Discord, activity stream. Couldn't answer "why did it turn left?" until we built a unified observability endpoint. Battery — still an issue. Continuous LiDAR + movement + inference drains faster than we'd like. Low-battery caps on movement duration for now. V2 architecture (what we changed): • One motion supervisor — single authority on motors • Mission FSM — vacuum / explore / find_person / teleop, one active job at a time • Planner vs executor split — the LLM picks what to do; it doesn't fire raw motor pulses every turn Next steps: • IMU + wheel odometry fusion (EKF) → AMCL for proper pose • Persistent room memory (episodes, obstacle map, cascade/EOD summaries) • Click-to-nav in the live viewer • Battery / power management tuning Happy to answer questions about the stack, Nav2 vs custom control, or mecanum on a Pi. Still very much work in progress — would love tips from anyone who's shipped a home robot without it becoming a full-time ROS babysitting job. Stack (rough): Pi 4/5 · Yahboom chassis · RPLidar C1 · FastAPI on Pi · Mac mini backend (Postgres, agent loop) · ROS2 Nav2 (research/A-B) · Python holonomic controller · Rerun for viz submitted by /u/Spinning-Complex [link] [Kommentare]
I have a technical interview for a machine learning position coming up, and I'm really nervous. Can you tell me about your experiences with this process? It's my first technical interview, and I don't know what to expect submitted by /u/Abatistta [link] [Kommentare]
Dr. Ayanna Howard, dean of The Ohio State University College of Engineering, former NASA roboticist and founder of Zyrobotics, explains why both universities and startups are necessary to advance robotics. Universities support foundational research that may not produce a commercial return for many years. Startups take that research and try to connect it to an immediate market need, moving quickly and changing direction when the technology or business model does not work. Howard also discusses the difficulty of building startups within universities because academic incentives are centered on research, publications and grants rather than developing products for customers. She sees the strongest model as faculty providing technical guidance while students lead the work of turning research into a viable company. Full convo: https://www.youtube.com/watch?v=lis9e9L4ScU submitted by /u/Responsible-Grass452 [link] [Kommentare]
Hello community, just a short reminder that Raffi Krikorian (CTO @ Mozilla) is live today for an AMA to discuss Mozilla's inaugural State of Open Source AI report. Topics include enterprise adoption, the real cost of "free"models, developer trust, Chinese open models and their impact, agentic AI infrastructure, and the future of open source with respect to Machine Learning & Artificial Intelligence. Drop your questions in the thread here: https://reddit.com/r/MachineLearning/comments/1upxdvc/raffi_krikorian_cto_mozilla_ama_on_the_state_of/ The AMA starts at 1pm ET/10am PT/6PM BST His team reached out to us and he provided proof via Linkedin here: https://www.linkedin.com/feed/update/urn:li:activity:7481380478365880321/ Thank you! submitted by /u/Benlus [link] [Kommentare]
I posted about an earlier version of this project here a few years ago. I always wanted to continue it, but life happened: house, kids, work, and suddenly project time disappeared. The old version worked, but it was five-year-old code, so I did what most people think about doing when they look at old code - I started from scratch. The project is called Vanchor. It is a different kind of robot than what is usually posted here, but still a robot :) Vanchor is an open-source GPS anchor/autopilot system for smaller boats using cheap electric trolling motors. The target is small fishing boats, kayaks, and other small boats with trolling motors (focused on bow mounted currently). The idea is to turn a cheap trolling motor into a simple autonomous boat-control system. Main functions: Hold position, similar to spot-lock Hold heading Follow waypoints Follow a shoreline Follow a depth contour Move between fishing spots Work around an island or structure Drift or orbit around an area Follow APB data from a plotter Test behaviour in simulation before using real hardware It is not meant to replace OpenCPN, chartplotters, or proper marine navigation. It is more focused than that: small-boat control for fishing and DIY automation. The new version has among a lot other features: Python-based controller Local web UI for phone/tablet use Simulator based on Fossen’s 3-DOF marine craft model GPS/IMU hardware support Driver system for custom hardware Location and heading from phone sensors through the PWA app, where supported Depth contours Catch logging GPX waypoint import Several fishing-focused control modes Early PCB designs Early 3D-printable servo/control models One thing I wanted to fix from the old version was the wiring. The boat setup quickly turned into a crow’s nest of wires, and debugging loose connections in a boat is not fun. Especially when you just want to catch some perch. So this version also has early PCB designs for a cleaner setup, plus 3D-printable servo/control models. The simulator is one of the more useful parts right now. It makes it possible to test control behaviour without having the boat, water, GPS, IMU, and motor driver available at the same time. The project is still early, but it is now at the point where outside feedback would be useful. Any feedback is appreciated. Especially feedback on the PCB. It looks fine when I inspect it, but it has been years since I designed my own, much simpler, PCB. And yes, even the 3D models and PCB designs were created with Fable. Without it, I would never have found the time to pull this together. So far, I am quite impressed by it. https://preview.redd.it/5u1eld6qlwbh1.png?width=3708&format=png&auto=webp&s=daa0ec1e2f3685177b538af5c972931e268b6c0a Repos: Main project: https://github.com/AlexAsplund/vanchor PCB designs: https://github.com/AlexAsplund/vanchor-pcb CAD models: https://github.com/AlexAsplund/vanchor-cad submitted by /u/aasplunds [link] [Kommentare]
The clip shows a dual-arm rig autonomously arranging flowers into a glass vase at 1x speed, fully autonomous, with three simultaneous camera angles in the corners so the full workspace is visible. Robbyant has released LingBot-VLA 2.0, a VLA model trained on roughly 60,000 hours split as 50,000 hours of real-robot data across 20 embodiments plus 10,000 hours of egocentric human video. The action space covers whole-body control to include head, waist, mobile base, and dexterous hands up to Unitree G1 and Fourier GR-2. On the authors' own GM-100 eval, where pi-0.5 and GR00T figures are also self-reported, Agilex Cobot Magic reaches 34.4% success and Galaxea R1 Pro 15.6%, with several tasks at 0%. The paper notes the model often makes partial progress then fumbles final precise placement or release, and OOD performance degrades sharply. Relative joint actions increased average success from 33.7% to 55.0% in ablations. submitted by /u/Feeling_Till_7418 [link] [Kommentare]
Tried creating same pick and place simulation with a few different models. The recurring pain point was resolving XML issues after the initial generation. Gave Drift a try for the same task. I spent more time iterating on the scene itself instead of chasing configuration errors. If anyone is looking for the exact prompt I used: Create a MuJoCo scene using a Franka Panda arm, place it on a table and a cube in front of it with a target pad. submitted by /u/AxBodiSpray [link] [Kommentare]
For open-weight LLMs, how practical is it to study defenses against post-release fine-tuning that weakens refusal or safety behavior? I've been seeing “uncensored” or “heretic” variants of new models appear very quickly after release, which raises a question I’m curious about: is fine-tuning resistance a meaningful safety goal for open-weight releases, or is it too narrow because determined users can always modify weights, switch models, or use other workarounds? And to a larger extent, is current safety training even worth the cost and effort if it takes 30 minutes and an automated script to break the model? I’m not asking about a specific method, just the threat model. What would count as a useful practical win here? For example, would increasing attacker cost or making safety removal less reliable be valuable, even if perfect prevention is impossible? Curious how people think about this from a model release, governance, and AI safety perspective. submitted by /u/Aaron_Rock [link] [Kommentare]
Researchers created a breakthrough technology that allows robots to feel and recreate touch just like humans. Using muscle-like air chambers, machines can now instantly mimic sensations ranging from soft tissues to rock-hard surfaces with 89% accuracy, revolutionizing robotic surgery and teleoperation. Credits: https://www.nature.com/articles/s44182-026-00102-2 submitted by /u/Similar_Suit_3709 [link] [Kommentare]