I am working in a research group in Germany, not that well known but in general good output. I have one colleague who does nothing in his PhD. He does not want to work, or he is not able to do any good research, his level is super bad. Plus He doesn’t even care about that. To wrap it up, he is just here for the money. Since he doesn’t want to work or he can’t really do anything good, instead what he does is “paper fishing”, he searches for people in the group doing some good research, and asks that they put his name on the paper. In this case he has something to cover up for him when the professor asks him about his progress. As long as his name is on the paper, progress is checked and funding is renewed. But he actually does nothing. I know this is very unprofessional and unethical. But people tell me it’s normal in academia. Professors all the time put names of their friends and this is how it works in academia. What are your thoughts of this behaviour? submitted by /u/impressivestatus21 [link] [Kommentare]
ROS Intern – CNDE Lab, IIT Madras Position - Robotics Operating System (ROS) Intern Organization - Centre for Nondestructive Evaluation (CNDE), IIT Madras Location - IIT Madras, Chennai, India Duration 3–6 Months (extendable based on performance) About the Role CNDE Lab, IIT Madras is seeking a motivated and enthusiastic ROS Intern to support the development of robotic systems, autonomous navigation solutions, perception pipelines, and AI-driven applications. The intern will work closely with researchers and engineers on cutting-edge robotics projects involving ROS/ROS2, computer vision, sensor integration, and robotic automation. Key Responsibilities - Develop, test, and maintain ROS/ROS2 packages and nodes. - Integrate sensors such as LiDAR, RGB-D cameras, IMUs, and other robotic peripherals. - Implement robotic navigation, localization, and mapping algorithms. - Develop communication interfaces between hardware and software systems. - Assist in simulation and testing using Gazebo, RViz, Isaac Sim, or similar platforms. - Debug and optimize robotic software for real-world deployment. - Participate in system integration, testing, and documentation activities. - Collaborate with researchers on robotics, AI, and automation projects. Required Skills Programming - Strong knowledge of Python. - Good understanding of C++ programming. - Experience with Linux (Ubuntu) environment. Robotics - Familiarity with ROS/ROS2 concepts, including nodes, topics, services, actions, and launch files. - Understanding of robotic kinematics, localization, navigation, and sensor integration. - Knowledge of Git and version control systems. CAD & Design - Experience with Fusion 360 for basic mechanical design, robot assembly, and component modeling. Preferred Skills - Experience with Computer Vision using OpenCV. - Knowledge of SLAM, Navigation Stack, MoveIt, or robotic manipulation. - Experience with simulation environments such as Gazebo or Isaac Sim. - Familiarity with AI/ML applications in robotics. - Experience working with robotic arms, mobile robots, or autonomous systems. Eligibility - Undergraduate, postgraduate, or recent graduates in: - Robotics - Computer Science - Mechanical Engineering - Electronics Engineering - Artificial Intelligence - Related disciplines What You Will Gain - Hands-on experience with advanced robotics research. - Exposure to real-world robotic systems and deployments. - Mentorship from researchers and engineers at IIT Madras. - Opportunity to contribute to innovative robotics and AI projects. Application Process Interested candidates should send their updated resume along with a brief statement of interest to: Email: msalamdata@gmail.com submitted by /u/Independent_Loss_593 [link] [Kommentare]
Following up on the on-demand comparison from a couple weeks back - pulled spot/ interruptible pricing this time since that's where the real savings conversation actually lives for anyone running checkpointed training or batch jobs. Checked: June 2026. Spot/interruptible tier, single GPU. ~ H100 80GB -Spot/Interruptible RunPod :- $1.80-$2.40/hr , Community spot, can terminate without notice. Vast.ai :- $1.47-$2.00/hr (low end seen as low as $1.03/hr in thinner markets) wide range, host-dependent. AWS (P5, spot) :- technically available, $2.50-$3.10/hr extremely limited, frequently unavailable at any price. ~ A100 80GB - Spot/Interruptible RunPod :- community spot as low as $0.20-0.40/hr (high variance) , reliability drops fast at this end. Vast.ai:- $0.67/hr typical, lower with thinner-reliability hosts, marketplace bidding, varies by host score. AWS (P4d, spot) :- ~$1.00-1.50/hr more consistently available than P5 spot. What stood out: The spot discount vs on-demand is real - 40-60% off on H100, sometimes more on A100 - but the spread between providers on spot is much wider than on-demand. You're not comparing apples to apples, you're comparing apples to "whatever fell off the truck this hour." AWS spot for H100 (P5) is more of a theoretical price point than a practical one right now - availability is thin enough that "checked the price" and "could actually get one" are two different questions. Vast.ai's floor prices look incredible until you check host reliability scores. The $0.67/hr A100 and the $1.50/hr A100 are not the same product even though they're listed the same way. This tier only makes sense if your job checkpoints well - anything customer-facing or latency-sensitive, spot isn't worth the risk regardless of price. Not selling anything, just tracking this for my own training runs and figured others here are doing the same math. Anyone actually running production batch jobs on spot right now? Curious what interruption rates you're actually seeing vs what's advertised. submitted by /u/Shot-Calligrapher166 [link] [Kommentare]
Been chewing on this for a while and I honestly can't tell if it's genuinely open or if I'm just not googling the right terms, so I'll throw it out here. There's a paper by Roynard that put words to something I'd been vaguely bothered by for a while. He calls it a category error, the idea being that pretty much every memory system applies the same persistence model to everything it stores, usually some kind of decay, no matter what the thing actually is. Which is fine for some throwaway message, but it gets weird when the same treatment gets applied to something you've actually validated and would want to stick around and get corrected if it turns out wrong. So you end up storing very different kinds of information under the same rules, even though how much you should trust them or how long they should live is completely different, and I don't think many people are treating that difference as a real property of the memory. That kind of lines up with the thing that keeps biting me once an agent's been running a while, which is that the system doesn't really have any idea how it came to know something in the first place. Something it actually observed, something it inferred a few steps back, and something it just made up all get written down more or less the same way and come back out later at the same confidence, and because none of it is marked as one kind or another, the agent doesn't really have a way to notice when it's wrong. So something stale or hallucinated can resurface later and it looks basically the same as something solid. Timestamps help a little, but they don't tell you what actually backed a belief, and they don't do much when whatever supported it turns out to be wrong and you'd want the agent to walk that back. What bugs me is that this feels like it should already map onto stuff people worked out decades ago. Belief revision (AGM and everything after it) is basically about updating a set of beliefs without it going inconsistent, but I've never really seen it bolted onto an agent's memory at any serious scale. Truth maintenance systems (JTMS/ATMS) are almost exactly this, since the whole point is tracking justifications and retracting conclusions when their premises disappear, and yet they seem basically absent from the agent stacks I've looked at. Calibration work is more about confidence on outputs than about the support behind things you've already stored as they age. And the smarter retrieval stuff, like HippoRAG or the temporal knowledge graph systems (Zep, Graphiti), makes retrieval better but still kind of treats memory as things to find rather than claims that have a support status attached. The closest thing I've found to what I'm describing is Hindsight, which actually splits memory into separate networks and has real conflict-resolution policies, but even there contradictions get surfaced when you query rather than reconciled up front, and corrections don't really propagate to the beliefs that depended on them. A recent paper gets at the human side of it pretty well, The Missing Knowledge Layer in AI. Their framing is that language sort of collapses uncertainty, so when a model states a guess, an inference, and an actual recollection all at the same surface confidence, the person on the other end can't really tell which one they're reacting to, which felt like the same problem I'm describing just viewed from the user's side instead of from inside the memory. What I actually want, at the end of all this, is a small set of primitives for it. Some reasonably clean way to assert something, say what supports it, note that two things contradict, supersede one with another, retract it when it falls apart, with the epistemic status being an actual property of the thing instead of something I bolt on after the fact. Belief revision and TMS feel like the right ancestors, but neither was really built for noisy, high-volume, LLM-generated memory, so a lot of my time just goes into trying to figure out what the right primitives even are. So for anyone who's actually shipped long-horizon agents, I'm curious whether anyone types their memory by epistemic status (observed, inferred, asserted, retracted) instead of just storing flat text plus embeddings, whether anyone's gotten classical belief revision or a TMS to hold up as the actual live memory layer rather than falling over on scale and noise, and whether handling contradictions at write time is even worth the latency or if most people just eat the inconsistency and sort it out at read time. And honestly, if this is already a solved thing and I'm just reinventing some old formalism with extra steps, I'd genuinely appreciate someone pointing me at it so I can go read. But if it's actually underexplored then I'm a little surprised, because it really looks like one of the things that quietly wrecks agents once they've been running longer than a week. submitted by /u/Bright-Fun-1638 [link] [Kommentare]
Every quadruped project, from research labs to Boston Dynamics, starts in the same place: a working simulation. Getting there is the slow part. Dozens of joints, the right dependencies, a launchable scene, all configured before you can train a single gait. I skipped it with one prompt to Drift: empty project to a four-legged robot standing in MuJoCo. submitted by /u/airwarmedd [link] [Kommentare]
I’m attending the Automate Show in Chicago and tested the teleoperation solution on display at the Universal Robots booth. When it comes to physical intelligence, data collection is a critical component. Today the industry uses a variety of acquisition methods including VR systems and optical motion capture. Teleoperation remains a highly practical approach for data collection thanks to its reliability and intuitiveness. What do you think? submitted by /u/No_Challenge_3410 [link] [Kommentare]
Do you guys get a miccai grants result? I do not receive any mail. Don’t I accept? submitted by /u/CrazyIndependent7436 [link] [Kommentare]
not sure if this is the right flair 😕 I had put this post up on r/gradadmissions but i feel like I'd get a better demographic that knows the field better here submitted by /u/Proud_Imagination_94 [link] [Kommentare]
I designed and built this 16-DOF humanoid robot using low-cost servos and fully 3D-printed parts. I’m currently working on the bipedal walking system and developing the locomotion algorithms based on the robot’s forward and inverse kinematics. I’ll be sharing more updates soon! Here’s a short video showing the development process so far: https://vt.tiktok.com/ZSCJJAqr6/ submitted by /u/RoboDIYer [link] [Kommentare]
With the release of meta-reviews, ECCV sent out a google form for dissatisfied authors to submit an appeal for the following reasons: Policy errors, e.g., reviewers or Area Chairs applied a policy that does not exist, or reviewers or Area Chairs applied policies that are not applicable for the contribution type of the paper; Clerical errors, e.g., it is clear from the meta-review that an Area Chair intended to accept a paper but the paper was rejected; and Obvious and major misunderstandings on the side of the reviewers or Area Chairs (historically, these are extremely rare). Is anyone considering submitting an appeal? I was rejected with 6/4/3 final scores on criteria that policy and AC/Reviewer guidelines explicitly state my contribution type should not be penalized for. Also, according to their policies, if they were to use the criteria in their decision, they have to explicitly disagree with the declared contribution type and state so in the meta review (all three reviewers agreed with the declared contribution type and the AC does not mention changing the paper's type.) submitted by /u/Muted-Ad4511 [link] [Kommentare]
It seems that everyone around is building robots these days. Overcoming my laziness, I decided to also build my own small robodog, and I'm sharing the result of this project, which took me quite a bit of trials and errors during long evenings. All parts were designed from scratch. Everything that is plastic was 3D printed. Everything that isn't plastic was sourced from generic stores - there are no custom CNC orders here. The main SBC is a Radxa Zero 3W running Ubuntu 24.04 with ROS 2 Jazzy. The servos are powered by a Sunflower PCA9685 driver board. There are two separate power rails: 5V for the Radxa and 6-7V for the servos. The trotting gait is shown in the video. I'm currently using an inverse kinematics algorithm, but my long-term plans include Tensor Lite and trained neural networks for skills. The project is still ongoing - I have so many things to try and learn. But it is solid enough as a good foundation for future iterations. submitted by /u/Consistent_Chance_97 [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]
I've been working through the internals of LLM inference and writing up what I learn as an open, in-progress handbook. Just wrapped another chapter on GPU execution and memory internals: why a GPU sits mostly idle during inference, how the memory hierarchy gates throughput, and where the real bottlenecks live. Added mermaid diagrams for the architecture pieces so the flow is easier to follow than a wall of text. It's a personal learning project, still growing chapter by chapter. I'd value feedback or corrections from anyone who's run inference in production, where my mental model breaks down is exactly what I want to find. Issues and PRs welcome. github.com/harshuljain13/llm-inference-at-scale submitted by /u/YouFirst295 [link] [Kommentare]
