c/robotics

Hey r/robotics, I've been working with tactile sensor data for a while, and there's a problem that kept bugging me: every tactile dataset has its own format, its own sensor, and its own way of labeling things. Want to compare your material classification model on GelSight vs DIGIT vs DMA? Good luck — the annotations don't line up, the schemas are different, and there's no standard way to even represent a "tactile label" across sensors. So we built two things to fix this: **TLabel** — an open-source sensor-agnostic tactile data labeling toolkit (Python + Panel UI). It supports annotation, quality scoring, batch processing, and exports to HDF5/CSV/JSON. Think of it as LabelImg but for touch data. **TLabel-Bench** — the first cross-sensor tactile annotation benchmark. It provides: - Unified JSON annotation schema that works across GelSight, DIGIT, and DMA sensors - Standardized evaluation scripts for material classification, episode segmentation, and cross-sensor transfer - Compatible with existing datasets (Touch and Go, SSVTP, ObjTac, Daimon-Infinity, CLAMP) The key idea: we only distribute annotation files + download scripts, not the raw data itself. This respects the original datasets' licenses while still letting researchers work with standardized labels. Why this matters: tactile sensing is moving fast (GelSight, DIGIT, DMA, Xense, etc.), but the tooling for *labeling and comparing* across sensors basically doesn't exist. Every paper re-implements their own annotation pipeline. We're trying to fix that. Would love feedback from anyone working with tactile data. What sensors are you using? What labeling tasks do you need? GitHub: - https://github.com/liesliy/tlabel (labeling toolkit, pip install tlabel) - https://github.com/liesliy/tlabel-bench (benchmark + evaluation) submitted by /u/ImmediateArm7942 [link] [Kommentare]

like in the next 10 mins. I have everything ready. I already have another person whose doing his setup rn. I just wanna complete it and get it over with quick. Maybe we can hop on a call?? submitted by /u/SundeepKuPanigrahi [link] [Kommentare]

Everything works fine, just for these maze of cables, I have run out of ideas, how do I actually get rid of the mess? I am using 2 16 channel servo drivers. all 18 (plus 2 for camera) are connected to those 2. I am using a buck converter on top and a 4200 MAH battery. The raspberry pi relays all info to my laptop and it control the motion additionally i also need space to put an imu sensor over it. Help !! submitted by /u/Grand-Station-6886 [link] [Kommentare]

Hi everyone, ​ I'm completely new to robotics, IoT, and electronics. I don't have much knowledge yet and I'm currently learning from different sources online and through projects. ​ I'd really appreciate some guidance from experienced people here. Can anyone suggest good places to buy IoT modules, sensors, microcontrollers, electronic components, and other robotics parts at reasonable prices? Both online and offline submitted by /u/Wide_Specialist6225 [link] [Kommentare]

I've been experimenting with converting ordinary third-person videos into humanoid motion data. This demo includes several motion categories: • Acting • Sports • Combat • Dance The motivation is not animation alone. Recent humanoid robotics work increasingly relies on large-scale motion datasets and motion priors to improve movement quality, robustness, and generalization. Projects such as NVIDIA KIMODO also show the value of scaling high-quality motion data for downstream humanoid motion generation and control. This made me wonder whether ordinary videos could become a low-cost source of motion data for humanoid systems. There is already a massive amount of human motion available in online videos. If useful motion can be extracted reliably, it may help expand humanoid motion datasets beyond traditional mocap pipelines. For this experiment, I focused on: • Foot contact stability • Reduced foot sliding • Natural balance and movement dynamics • Consistency across different motion styles The long-term idea is: Video → Motion Data → Motion Models → Humanoid Control For anyone interested in testing their own clips, I made a public demo available here: huggingface demo I'd love to hear thoughts from people working on humanoid robotics, motion generation, imitation learning, or robot locomotion. submitted by /u/AIMoCap [link] [Kommentare]

Suddenly i have my hands on a BRTIRUS0707A with HC1 controller (firmware HC-QC-RX-7.8.07-master-F5.2.1). RemoteMonitor queries and basic commands (stop/start) work fine over TCP port 9760. Trying to get remote joint control working via AddRCC but hitting a wall. The pendant's "long distance command" instruction references www.hc-system.com.HCRemoteCommand::\[HID:100\] as the data source — but every AddRCC packet sent to that dsID gets zero response, RemoteCmdLen stays 0, robot doesn't move. Tried every dsID variant and payload format from the official comms protocol manual (BRT-C-RC-HC1-TI1-V1.1). The network settings on the pendant only offer "take photos" or "modbus" as port purposes — no remote command/HCRemoteCommand option anywhere. Questions: Is HCRemoteCommand locked behind a license or a specific firmware option on HC1 controllers? Does anyone know the correct pendant configuration to actually expose this service? Any experience with Borunte/Huacheng remote teaching appreciated. Thanks in advance submitted by /u/tru0ne [link] [Kommentare]

Hey guys We are a group of people working on QDD actuators and we want to know the demand for these and required specifications. Too blunt of a sentence but yeah, we are trying to build low cost QDD actuators ( < 30k INR, 300USD ) with good reliability, integration and support. Based in India. We are trying to do market validation. ​ Keeping everything aside, if you're working in any company or a lab anywhere in the world which uses QDDs (preferred to be in India). Please let us know what are the required specs and how many can we expect an entity to need/order per year. submitted by /u/VisualDry7848 [link] [Kommentare]

Final-year mechatronics student, building small differential-drive robots with ROS 2. Bringing up micro-ROS on a new MCU keeps costing me a lot of time — toolchain, the agent, transport/baud config, memory limits, then the cmd_vel → PWM and encoder → odometry glue. By the time /odom and /imu publish cleanly, a weekend's gone. For people doing this regularly: Have you settled on a repeatable workflow that makes bring-up painless, or do you just eat the cost each time? On ESP32-S3 / RP2040 / STM32 — which transport do you actually use (Wi-Fi/UDP vs. serial), and how reliable is it on a moving robot (reconnection, dropouts)? Trying to learn how more experienced folks structure this so it stops being a weekend sink. submitted by /u/UnderstandingFit8261 [link] [Kommentare]

Need help with my servos. Using DS3240 MG servo motors. Getting weird jitter sometimes, sometimes not. Sounds very scratchy. Power supply is definitely strong enough. Happens with and without load. Signal wires seem far enough from noise sources. The motors have stalled once when the arms of the two collided, and I'm thinking that the gears got damaged because of that. Although I think it's unlikely because these motors are designed to be able to hold a max load of 40kg submitted by /u/YengaJaf [link] [Kommentare]

Hi everyone, I made an open-source Ultimaker Cura plugin that generates KUKA KRL (.src) code directly from the slicer, allowing you to send your files straight to a KRC2 controller. All your favorite Cura settings are translated directly into the robot code, completely eliminating the need for expensive software like RoboDK, Grasshopper, or SprutCAM. You just slice directly in Cura and go straight to the robot. I wanted to keep this project open-source so anyone in the community can use it for free. https://github.com/nikoladim123/CuraToKRC2 Enjoy! submitted by /u/Unlucky_Resident_237 [link] [Kommentare]

Hello! I am eyeing to compete in a maze runner competition. I did some research and it seems that micromouses are the best for those. Could I get recommendations/list of electronic parts to build a fast and reliable micromouse robot? Like what mircocontroller should I use or what wheels should I get or what sensors are the fastest in reacting? Oh, last thing, do have information on where I can but them? Thank you!!! submitted by /u/Big_Criticism_3517 [link] [Kommentare]

So we spent the better part of 4 months with our arm's motion and control stack running clean in sim. like flawless. every trajectory, every edge case we could script, green. a fair chunk of that code was AI-assisted. we'd describe the behavior we wanted, it gave us something that looked right, simulated right, and passed review. nobody on the team would say they fully wrote it, but it worked, so who cared. then we put it on the physical arm with a real payload and it drifted. not a crash, nothing dramatic. the end effector just slowly ended up a few mm off where the sim swore it would be, and it got worse under heavier load. once you add the real latency and the sensor noise the sim was too clean to ever reproduce, the behavior wasn't the behavior we tested. it was close. close is the problem. what actually rattled me is that reading the code would never have caught this. it's all locally plausible. each block makes sense on its own. the gap only exists where the generated logic meets real timing and a real load, and a simulator that passes everything is exactly where that gap hides. then the worse thought. we've shipped smaller motion changes the same way for a while, sim-pass and call it done, never put a real-hardware check in front of them because sim was green and we trusted it. i don't actually know those were fine. i just know they didn't fail loud. so for the people running real arms here, what's actually in your loop between sim-pass and trusting it on the hardware? is any of that automated for you, or is it still someone standing there watching the real thing move submitted by /u/executivegtm-47 [link] [Kommentare]