The final session of the Advances in Social Robot Navigation Workshop at ICRA 2025 is happening NOW. It's been a great conference so far, with lots of great talks and debate ...
Even though there's no-one in the row in front of me, we've had 50-60 people in person or online all day:
More on the workshop later ... back to taking notes now!
Lots of great social navigation work this conference ... we are really seeing some advances. Even in the proliferation of form factors, some of which you can see above, such as the base with humanoid, looks like it will help social robotics. More and cheaper robots - and more varied form factors - should make it easier to find the right robot for the job.
Onward! Three or four more sessions of talks, and then it's the workshop ...
-the Centaur
Pictured: The room our workshop will be held in, and two robots "shaking hands".
Due to a snafu with the way the date and time were programmed into OpenReview, and having NOTHING AT ALL to do with us getting slightly fewer papers than we wanted (well, actually ....) we have extended the deadline for the Embodied AI Workshop's Call for Papers to Friday, May 23rd, AOE (Anywhere on Earth):
Please submit your 2-page extended abstracts on embodied AI, especially related to this year's themes of Embodied AI Solutions, Advances in Simulation, Generative Methods for Embodied AI, and Foundation Models for Embodied AI!
SO! I'm at ICRA, the big robotics conference (okay, okay, ONE of the big robotics conferences, the others being IROS and RSS) and I would be remiss if I didn't point out that our workshop, "Advances in Social Robot Navigation: Planning, HRI and Beyond" will be held this Friday, May 23rd!
Building on our successful series of workshops at ICRA'22, IROS'23, and RSS'24, as well as the Social Navigation Symposium, the AISRN workshop aims to investigate key aspects that make robot navigation more acceptable, legible, and social. It's been a great year for social navigation at ICRA; come join us!
Hey folks, I have been neck deep in preparations for a couple of workshops - the Advances in Social Robot Navigation one I already mentioned, coming up next week, but also the Embodied AI Workshop #6!
The Embodied AI workshop brings together researchers from computer vision, language, graphics, and robotics to share and discuss the latest advances in embodied intelligent agents. EAI 2025’s overaching theme is Real-World Applications: creating embodied AI solutions that are deployed in real-world environments, ideally in the service of real-world tasks. Embodied AI agents are maturing, and the community should promote work that transfers this research out of simulation and laboratory environments into real-world settings.
So, yes, it's late and i'm tired, but i couldn't just leave it at that, because the above quote is so good. I ran across this from George Bernard Shaw in a book on mentoring (which I can't access now, due to cat wrangling) and snapped that picture to send to my wife. In case it's hard to read, the quote goes:
The single biggest problem with communication is the illusion that it has taken place.
This was a great quote to send to my wife because our first vow is communication, yet we have observed problems with communication a lot. Often, when the two of us think we are on the same page, frequently we have each communicated to each other something different using similar-sounding language.
I was struck by how hard it is to get this right, even conceptually, when I was skimming The Geometry of Meaning, a book I recently acquired at a used bookstore, which talks about something called something like a "semantic transfer function" (again, I can't look up the precise wording right now as I am cat wrangling). But the basic idea presented is that you can define a function describing how the meaning that is said by one person is transformed into the meaning that is heard by another.
If you pay attention to how communication fails, it becomes clear how idealized - how ultimately wrongheaded - it is. Because you may have some idea in your head, but you had some reason to communicate it as a speech act, and something you wanted to accomplish inside the hearer's head - but there's no guaranteed that what you said is what you meant, and much less whether what was heard was what was said, or whether the interpretation matched what was heard, much less said or meant.
But even if they took your meaning - even if the semantic transfer function worked perfectly to deliver a message, there is no guarantee that that the information that is delivered will cause the appropriate cognitive move in the hearer's brain. Perhaps we're all familiar with the frustration of trying to communicate an inconveniently true fact to someone who stubbornly won't absorb it because it's politically inconvenient for them, but the matter is worse if your speech was designed to prompt some action - as Loki and one of the kittens just found out, when he tried to communicate "stop messing with me, you're half my size, you little putz" as a speech act to get the kitten to leave him alone. It had the opposite effect, and the kitten knocked itself onto the floor when it tried to engage a sixteen-pound ball of fur and muscle.
So what does that have to do with drainage?
My wife and I have had a number of miscommunications about the cats recently, ones where we realized that we were using the same words to talk about different things, and didn't end up doing things the way each other wanted. But it isn't just us. The cats stayed indoors mostly today, because workmen came by to work on a drainage project. I went out to sync up with the foreman about adding a bit to the next phase of work, and he offhandedly said, "sure, now that we're finished with the front."
"But wait," I said. "What about the drains in the front?"
"What drains in the front?" he asked.
We stared at each other blankly for a moment, then walked around the house. It rapidly became clear that even though we had used the same words to talk about the same job related to the same problem - excess water tearing through the mulch - we had meant two completely different things by it: I had meant fixing the clogged drains of the downspout of the gutter that were the source of the water, and he had took that to mean fixing the clogged drains where that water flowed out into the rest of the yard. A rainstorm soon started, and we were able to both look at the problem directly and agree what needed to be fixed. (The below picture was from later in the night, from another drain that was clogged and in need of repair).
It turns out the things that I wanted fixed - the things that had prompted me to get the job done in the first place - were so trivial that he threw them into the job at no extra cost. And the things that the foreman had focused on fixing, which also needed to be fixed but didn't seem that important from the outside, were actually huge jobs indicative of a major mis-step on the original installation of the drainage system.
We resolved it, but it took us repeatedly syncing up, listening for issues as we spoke, and checking back with each other - in both directions - when things didn't sound quite right for us to first notice and then resolve the problem. Which is why I found it so apropos to come across that Shaw quote (which I can look up now that the cats have settled down, it's in The Coaching Habit) as it illustrated everything me and my wife had been noticing about this very problem.
Just because you've said the words doesn't mean they were heard. And just because they're said back to you correctly doesn't mean that the hearer actually heard you. If you spoke to prompt action, then it's important to check back in with the actor and make sure that they're doing what you wanted them to - and even if they're not, it's important to figure out whether the difference is their problem - or is on your end, because you haven't actually understood what was involved in what you asked them to do.
So, yeah. The biggest problem with communication is the illusion that it has taken place - so rather than trust the illusion in your mind, take some time to verify the facts on the ground.
-the Centaur
Pictured: "Shaw!", obstreperous cats, and a malfunctioning drain.
Recently Internet guru Seth Godin blogged about “Halfway Projects”: you can get value from eating half of a pear, but half a canoe is worth less than no canoe at all. I like that. It’s a great metaphor for project management, where quitting a project just before the finish line doesn’t deliver any of its value—but leaves you with all of the costs.
Now, I misremembered Godin’s example a bit - what he actually said was “half a pear might deliver 85% of its value”. But the principle is sound: half a battery charge might let you do 85% of your work … but half a parachute is definitely worth less than no parachute at all, because it might encourage you to take risks that you shouldn’t.
For project management, though, the idea helps explain my long-running idea “work just a little bit harder than you want to.” Often, when working on a project, we get exhausted, and decide to give up - but working just a little bit harder can take us over the finish line. Our instinct to save us effort can actually thwart the work we need to do to achieve success.
For example, recently I was working on a machine learning project that just wasn’t working. We’d spent enormous effort on getting the learning system up and running, without good learning results to show for it, and the arbitrarily imposed deadline was coming up to show something impressive, or the project would be axed.
But, if you know anything about machine learning, you know most of the effort goes into data preparation. We had to modify the system to log its data, massage it into a format that was useful for learning, and spend further coding effort to speed it up so it was useful for development (taking the data load from 36 hours to 36 seconds!).
The point is, we only got the data running in mid-February, and were trying to compress months of experimentation into just ten days. Finally, as the deadline approached, I got philosophical: we’d done all the work we needed to do to start learning, and my recommendation was that the team keep working on it, with or without me.
But … I didn’t stop there.
Before the final presentation, I spent time cleaning up the code, checking things in, and getting a few of the most promising programs ready to collect “baselines” - long runs of the system set up for comparisons. And the next morning, I reviewed those baselines to present a report to the team about which one was most promising.
Long story short, one of the simplest models that we tried was actually sort of kinda working. Once I realized we had a scaling issue in the output, a simple tweak made the system get even better. I spent another hour tweaking the graphs to put the human input and the system results onto the same graph, and the good results leapt out into sharp relief.
I could have just decided that the system was a failure - but then I wouldn’t have done that extra work, making it a self-fulfilling prophecy. I call this the “Sunken Cost Fallacy Fallacy”. For those not familiar, the “Sunken Cost Fallacy” kicks in when you keep doing something that isn’t working because of the effort you’ve spent, even though you have a better option.
But you can’t “decide” that something is a better option because you’re a Decisive Decider™. It actually has to be a better option, or what you’re doing is simply throwing away the effort that you’ve spent to date because you want to throw your weight around. No, if you suspect a cost is sunken, there’s no substitute for doing your due diligence - is the project working?
If it isn’t, sure, then quit. But often, that little bit of extra work can unlock the solution to the problem. During my presentation, the team asked natural about the simple model that turned out to be the most successful - and those questions made me realize it could be improved. Over the weekend, I applied those fixes - taking merely good to excellent.
Last week, as of Thursday night, I was pretty down on the possibility of success for our project. But I did my due diligence anyway, and by Friday morning, I had a working solution. By Friday afternoon, all the team knew it – and by Sunday evening, I was composing an email outlining our machine learning “recipe” that we can build on going forward.
Quitting just before the finish line wastes all the effort you spent on the project. Before you quit, work a little bit harder than you want to and do your due diligence to check whether it is working. If it isn’t, you can stop with no regrets; if it is, you will have not just saved the value of your project - you will have saved yourself from shooting yourself in the foot.
-The Centaur
Pictured: The project team. Three-quarters of them want to try a new direction, but the old seasoned hand isn't quite so sure.
Long day. But I had yet another victory with "push it just a little bit farther" combined with "nailing down the carpet", applying them together to successfully complete a data loader for my latest machine learning project. It was quite the mess at first, with loose wires and dangling bits all over the place, and while the high level concept of what I wanted to do was clear, some of the next steps were elusive.
But "nailing down the carpet" means methodically going through a project and eliminating everything that can trip you up - formatting files, turning on the linter, resolving lint issues, refactoring code, and, sometimes, just moving code to its proper place. And when I was done with that, my data loader class was practically empty, just waiting for a suggestion from ChatGPT to flesh it out.
I had to adapt that code to my use case, of course, but I successfully loaded my data (into a Colab which was now a third of its former size thanks to my aggressive moves of code into reusable libraries) and managed even to cut the proposed loader to half its size, again due to the reusable libraries I had just built. The code worked in Colab. And I wanted to check it all in - but the unit tests suggested by ChatGPT no longer passed after all my code changes. It was late and I was tired, so I decided, yeah, time to hang it up.
But I was so close. And so, I decided to "work a little bit harder," and fix the unit test. Once I dug into it, I realized the problem was the synthetic data that the generative AI had proposed in the unit test, so I replaced that with real data, using the librarized code I'd just refactored. And then I realized the data was too big, so I used ChatGPT to write, on the fly, some code to squeeze the data down to size as test data.
That extra work took less than an hour - maybe less than thirty minutes. But it meant I was able to package up a report to my team and toss it over the virtual cube wall, confident that I had a clear picture of the data they were sending me and a clear set of tools to deal with it. And my next step, after a couple of minor refactors, is to finish the data loader so it can look at sequences of frames - something that we strongly suspect is needed to solve this machine learning problem.
So, once that's done tomorrow ... it's on to learning.
Don't jinx it, Francis.
-the Centaur
Pictured: Loki, being very comfortable in the Captain's chair. And so my point, and I guess I had one, is that by pushing it a little bit farther, almost past my comfort zone, I in turn made things so much more stable that I am actually more relaxed and calm than I was when I was planning to turn in early. So I find the tools that I'm developing - "nail down the carpet", "sharpen your saw", "work a little bit harder", "clear the decks", "find the price and pay it", and "be gentle with yourself" - continue to reap greater and greater rewards.
...but I'm still going to try to get at least one thing done before I go to bed.
Because, even though it's been a rough few years, and sometimes I want to give up ...
I still believe you just need to work slightly harder than you want to in order to really get things done, and if you do, you'll often find that your efforts are more greatly rewarded than you might have imagined.
I'll go further: if you work just a little bit less than you need to, it's often a net negative: you expend effort without reaching the goal, so all you're left with is the cost. But if you put that slight extra effort in, right when you think you want to give up, that's when everything can flip from negative to positive.
We often think in terms of a simple linear model of effort to results - we do a little work to get a little reward, and we're often taught in economics class that there's a law of diminishing returns, so if we do even more work, we get proportionally less reward.
But that little bit of extra effort right when you want to give up flips that script: it doesn't give you a little bit of extra reward, approaching zero the more effort you put in; because it can turn a loss into a win, it effectively has an almost infinite relative payoff.
So: Don't give up. Because, when you feel you want to ... that's when you're close to victory.
-the Centaur
Pictured: Pound cake, deep learning, and art practice.