Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Azalea Robotics (YC S24) – Baggage-handling robots for airports

news.ycombinator.com

Post reply on HN
Print view View original

41–50 of 83 posts

Re: Launch HN: Azalea Robotics (YC S24) – Baggage-handling robots for airports

#41

Post by dmillard »

AustinGrandt wrote: post #5

Previous baggage handler turned software dev here. Looks like you are targeting the bag room right now which is the best spot to start to prove the concept. It was surprising to me how manual the entire loading & sorting process was when I worked for the airlines. I'm curious if there's any roadmap eventually to get this out to the ramp itself. Most of the back injuries seemed to happen in the bin itself because you…

Thanks for the feedback!

John B was obviously aware from previous experience what a manual and injury prone process this was, but I've also been really surprised as I've dived deeper into airport operations myself.

Bagroom is definitely what we're targeting first - being indoors (usually) is a huge plus, and lets us focus on the manipulation part of the problem without going fully mobile yet.

That said, we're definitely targeting tarmac/ramp operations, particularly between a TUG/PowerStow and narrow-body bag carts. Inside the bin is much trickier but we agree it's the least ergonomic part of the job, you just can't move a massive industrial arm in and out of a plane very easily. We have it on our longer-term roadmap, though, and intend to leverage the baggage dynamics data we collect everywhere else to give us a head start on the packing and manipulation problems there, just with a different mechanism.

Cargo packing is a huge area of interest for us! Particularly around optimizing weight distribution in loaded planes, or just optimizing packing efficiency in general.

Re: Launch HN: Azalea Robotics (YC S24) – Baggage-handling robots for airports

#43

Post by dmillard »

iancmceachern wrote: post #42

As part of one of my classes in engineering school we went and toured the DIA baggage handling system, studied why and how it was such a big failure and what they did to fix it.

There have been some solid attempts in this space before - many projects take on the whole baggage system design and end up very very complex and often over budget. We're focusing on introducing tech that plays well in a larger system, particularly in "brownfield" existing processes - our bet is that recent advances in robot autonomy give us ability to handle items that weren't possible before, and therefore our units can be introduced in a more flexible way.

Re: Launch HN: Azalea Robotics (YC S24) – Baggage-handling robots for airports

#44

Post by derektank »

floren wrote: post #26
pj_mukh wrote: post #2

Super cool! You are additionally going to be saving a lot of workers from getting chronic back pains. I thought maybe y'all are going too slow, but after looking at some baggage handling videos, it seems like you're at a comparable speed already? In deployment these things are probably going to be on some kind of cart system, I presume all your algorithms can handle small changes in the XY travel plane (i.e. the robo…

> You are additionally going to be saving a lot of workers from getting chronic back pains. That'll probably be a big comfort to those who lose their jobs

It's not as though this is a profession which people spend a decade learning to perform. And it's not 2009 any more, there is demand for labor throughout the economy. I think the benefit of getting people out of physically damaging work outweighs the pain of having to find a new job in this case

Re: Launch HN: Azalea Robotics (YC S24) – Baggage-handling robots for airports

#45

Post by heytakeiteasy »

This is very cool, thank you for sharing. I work in automation and SWE for a certain 4-letter organization that delivers your mail. Pick/place is something we've rolled out using articulated and delta robots with vacuum end effectors, and it's an interesting and challenging space to be in. As in your case, bags and other amorphous shapes are always the most difficult. It's always an uphill battle to hit throughput targets due to exception cases that can stop things until a human gets involved. Ultimately, it can be a struggle to avoid overpromising and to generate ROI since automation is so costly, especially when there's no opportunity to bound the problem by influencing the inputs to your system or the output requirements (in your case, the cart being loaded). Best of luck and looking forward to seeing your new end effector.

Re: Launch HN: Azalea Robotics (YC S24) – Baggage-handling robots for airports

#48

Post by dmillard »

a_t48 wrote: post #46

This looks cool, interested to see where it goes in the future. Going to be a pest for a minute - have you considered a stack other than ROS2?

Not a pest at all and I've long been frustrated with ROS - our early demos were actually just a single C++ binary with multiple threads running for perception, control, and visualization, and I byte-packed robot control messages in our own software to avoid using ROS.

Unfortunately this breaks down in a few ways that you're probably familiar with, given that you asked this question:

- A crash in (e.g.) a third party sensor driver can bring down your whole binary, any signal catching here is awkward and you end up wanting process isolation

- Perception is, for better, or worse, easiest to prototype and try off the shelf in Python / Pytorch, so you either end up with pybind11 and driving things in Python, ONNX which is IME brittle for some of the crazier Pytorch modules, or message serialization and process isolation.

ROS/ROS2 does _way_ too much in my opinion - why does it have a build system and a ton of packages? This plus pinning OS versions are huge pain points. Unfortunately I also think many community-contributed ROS/2 packages are fairly low code-quality, with notable exceptions. Overall, I'd prefer to have ROS be a pubsub library with a few extra tools for logging and visualization.

In the end, we're currently using ROS2 for the reasons listed above and for easy prototyping, but I'd like to move to something more like FPrime, Basis, Cerulion, or Copper in the near future. I really want to grow something in-house with Zenoh or IceOryx2, but don't want to waste a lot of time on middleware, since I don't think it's what's kept the problem from being solved.

(At the end of this post I now see you're working on Basis, I apologize that I'm over-explaining to you. I'd love to chat about Basis if you have some time in the next few days!)

Re: Launch HN: Azalea Robotics (YC S24) – Baggage-handling robots for airports

#50

Post by a_t48 »

dmillard wrote: post #48
a_t48 wrote: post #46

This looks cool, interested to see where it goes in the future. Going to be a pest for a minute - have you considered a stack other than ROS2?

Not a pest at all and I've long been frustrated with ROS - our early demos were actually just a single C++ binary with multiple threads running for perception, control, and visualization, and I byte-packed robot control messages in our own software to avoid using ROS. Unfortunately this breaks down in a few ways that you're probably familiar with, given that you asked this question: - A crash in (e.g.) a third party…

I agree. :) We don't specify an OS version, we allow arbitrary process boundaries, we use plain old CMake. Our perception story isn't great, yet. We have some tooling which could make certain GPU workflows easier, but have only prototyped with ONNX w/C++.

Would love to be able to provide your middleware, we've connected on LinkedIn, let's chat.

Post reply on HN