Re. infrastructure integration: it's always a cost-benefit analysis. I've worked at a robotics company where we integrated with doors and elevators. Doors was really easy, cost almost nothing, and didn't come with any regulations. Elevators, on the other hand, was a length process, required certified elevator technicians, and cost a lot of money. On the other hand, adding a manipulator to open manual doors is very difficult and costly (per robot), but adding a button-pusher for elevator buttons is not.
The post mentions several times how it's both costly for adopter to add infrastructure to support robots but also how other forces can make that infra already there e.g. how it costs money to install wifi in a warehouse but handheld scanners led to wifi being in them anyway (which was great for the robots too).
This reminded me of a quote about the future of automated driving (paraphrasing):
"We currently consider the following to be distinct and very different modes of transportation:
- car
- elevator
- train
At some point, those will all converge into a vehicle that can travel on roads (like a car), with other vehicles (like a train) and bring you up to a building floor (live an elevator)."
This seemed somewhat true to me until I considered two things:
1. The smart phone did something similar with a phone, television, computer etc
2. There is a scene in the movie Minority Report that does exactly what the author of the original quote described. [0]
The combination of another convergence device AND a fictional visual of what that convergent device would like really hammered home what the future might look like.
the problem with the "car-like-a-train" thing is that trains have really high capacity because their crossings are managed and they do not decouple/couple at high frequencies, but more importantly the people to space ratio is significantly higher, particularly since standees take up very little room. when you consider that cars need a whole engine for four seated people the general end result is that "cars-like-a-train" combines the worst of both worlds.
I don’t think the second part (about length of the train) is accurate at all. Yes, a train made of pods roughly car sized would be longer, but only roughly 3x. If you look at the duty cycle of say BART rail, you could fit a lot more than 3x trains on it. The rail is empty most of the time.
In a rail network you are only as good as your most congested pipe. BART is a pretty good example of this, because while the outer legs are relatively infrequent, they all converge on the Transbay tube at a combined 2.5 minute frequency, which is about the safe braking distance with some buffer for a train of that size and weight. Longer convoys would require even more braking distance, and already trains cannot rely on the AV technologies of cars because the braking distance is beyond line of sight.
You could run more trains only between the suburban branches but there isn't a whole lot of demand for that.
Coupling / decoupling at high frequencies would be a challenge for sure - but seems achievable in a world of fully autonomous vehicles that can communicate.
Right now to ensure absolute safety trains are mechanically coupled, which can't be done while moving, and takes a few minutes to do safely.
I believe most AV convoys propose virtual coupling to get around this, but the failure scenario where something in the convoy comes to a sudden stop and the other things in the convoy don't, is pretty gnarly. Modern trains have a bunch of mandated safety measures in their mechanical coupling to prevent nasty things like jackknifing, or even worse, telescoping https://en.wikipedia.org/wiki/Telescoping_(rail_cars)
This is speculation but I wonder if you could have cars couple with "cat whiskers" that are mechanical but not load bearing. so you don't need to rely on wireless comms for coordination
I’m not sure what load bearing means in this context.
Generally speaking mechanical coupling takes a while because you really, really do not want an errant car to detach during its journey. In the worst possible case scenario, a rear carriage has decoupled from a train and then the following one has crashed into said carriage. https://localtvkstu.wordpress.com/2013/11/05/crews-respond-t...
What kind of furniture lets the robot vacuum under it and around its legs in the place it typically goes? What apartments and homes are large enough to have a robot-width distance between walls, corners and everything that is on the floor? How much do you think Ligne Roset sofas cost? And at $1,000/sqft, surely a lidar can be cheap in comparison. You're kind of proving my point of how off the mark iRobot is.
> What kind of furniture lets the robot vacuum under it and around its legs in the place it typically goes? What apartments and homes are large enough to have a robot-width distance between walls, corners and everything that is on the floor?
This isn't actually a problem.
If the robot vacuum cleaner is 10cm high, any furniture where the gap below it is <9cm the robot will detect with its bump sensor and avoid. Any furniture where the gap is >11cm high, the robot will clean under no problem. The only problem is furniture with a gap in the 9-11cm range. For that you can either buy a different sized robot, or raise or lower the furniture.
Of course you'll have to avoid leaving trailing cables on the floor - but that makes your home neater anyway, so no problem.
You can buy a Lidar robot if you want, of course - the classic random-driving-around Roomba is very much a product of its time.
Too often I've heard: why make a robot open doors with it manipulator, just install a door opener on the door!
Fits the bill here exactly: making a better robot helps you scale. Only relatively recently that robots opening doors became a reasonable thing to ask fo, but not much robots yet that do this at scale I think.
The true answer is that it is hard, and requies very carefull analysis.
Putting a “door opener” on the robot is sometimes at no extra marginal cost. (Because it already has a manipulator to fullfill its job.) Sometimes it would make the robot cost prohibitive, and the correct solution is to use automatic doors. Depends on how many doors there are and how many robots, and what kind of robot and what kind of door.
Then again even if the correct solution in a particular situation is to add door opening manipulators on the robots very likely you would only want to support a few different kinds of handles. Imagine the complications of trying to support all door handles from baroque brass levers through modern spherical knobs to dogged doors the kind you find on a warship.
I’m not aware of any. If a particular problem domain would require the robots to use door handles I would identify that as a big risk to the project. Not impossible to solve, but a significant problem.
This is solid advice, particularly #4 is the reason I have started building my own bots. I do have one question though, how to design the production pipeline such that it is easy to iterate on the bot design with minimal disruption?
While I agree with the other reply's "it depends" questions, at a high level there is one thing that I think applies pretty much whatever scope you're working on, with a few sub-points:
- Find robust parts for the non-innovative aspects of your system (eg motor drivers)
- ...with a standard interface (PWM/PPM, RS485, CAN, Ethernet, whatever)
- ...hide that interface behind a simple software interface so that if you do have to swap to a different bus type you can do so mostly transparently
- ...and don't reinvent the wheel if you don't have to.
Once you have a set of proven parts with well-defined simple interfaces you can start treating those like Lego and mix and match to your heart's content.
Rapid iteration at the component level would obviously require custom components, and maybe vertical integration, which clearly conflicts with point #1 about riding existing supply chains. But you can still iterate parts of the design that you more or less "have" to customize, such as the body material, axis geometries, and dozens of other factors I can't think of off the top of my head. The collected data can both be used to improve training and as input into the design iterations.
I think part of the design craft is to ensure rapid prototyping and at the same time making sure that manufacturing is scalable. My question is more on how to hit the sweet spot where prototyping is fast and at the same time production pipeline changes are cost effective.
Where does one get part-level information to qualify a supply chain as "juicy"?
Otherwise the first advice looks like a 1st-world solution that independent 3rd-world developers can't deploy. Could early-stage companies even expect this from their investor/connectors?
Digikey has 32,000 in stock and your search filters yielded 100’s of nearly identical components from different manufacturers. This could mean using 4 pole switches when you only need 3 because toggles are typically 1,2, or 4 pole.
Digikey is sadly very expensive. It’s good for prototype. Or expensive industrial equipment. But for consumer goods one needs to go to China and source really cheap components optimized for large volume manufacturing.
- tear down a mass produced product that has approximately the right size of part that you're looking for and see what you can find. If you're super lucky there'll be a generic part number on the item that you can use to do some research with. If you're less lucky, take some measurements (dimensions, RPM, torque, voltage, current, wavelength, whatever) and start looking around to see if there are manufacturers making generic versions of that part.
That's true, but grandparent's advice is a good way to pick standardized parts. If there are 4 versions of a switch with identical footprint on digikey, you can be pretty sure that you'll also be able to source it from Taobao or LCSC or something.
Re. infrastructure integration: it's always a cost-benefit analysis. I've worked at a robotics company where we integrated with doors and elevators. Doors was really easy, cost almost nothing, and didn't come with any regulations. Elevators, on the other hand, was a length process, required certified elevator technicians, and cost a lot of money. On the other hand, adding a manipulator to open manual doors is very difficult and costly (per robot), but adding a button-pusher for elevator buttons is not.
The post mentions several times how it's both costly for adopter to add infrastructure to support robots but also how other forces can make that infra already there e.g. how it costs money to install wifi in a warehouse but handheld scanners led to wifi being in them anyway (which was great for the robots too).
This reminded me of a quote about the future of automated driving (paraphrasing):
"We currently consider the following to be distinct and very different modes of transportation:
- car
- elevator
- train
At some point, those will all converge into a vehicle that can travel on roads (like a car), with other vehicles (like a train) and bring you up to a building floor (live an elevator)."
This seemed somewhat true to me until I considered two things:
1. The smart phone did something similar with a phone, television, computer etc
2. There is a scene in the movie Minority Report that does exactly what the author of the original quote described. [0]
The combination of another convergence device AND a fictional visual of what that convergent device would like really hammered home what the future might look like.
0 - https://www.youtube.com/watch?v=Vrxyr1CjiSM
the problem with the "car-like-a-train" thing is that trains have really high capacity because their crossings are managed and they do not decouple/couple at high frequencies, but more importantly the people to space ratio is significantly higher, particularly since standees take up very little room. when you consider that cars need a whole engine for four seated people the general end result is that "cars-like-a-train" combines the worst of both worlds.
I don’t think the second part (about length of the train) is accurate at all. Yes, a train made of pods roughly car sized would be longer, but only roughly 3x. If you look at the duty cycle of say BART rail, you could fit a lot more than 3x trains on it. The rail is empty most of the time.
In a rail network you are only as good as your most congested pipe. BART is a pretty good example of this, because while the outer legs are relatively infrequent, they all converge on the Transbay tube at a combined 2.5 minute frequency, which is about the safe braking distance with some buffer for a train of that size and weight. Longer convoys would require even more braking distance, and already trains cannot rely on the AV technologies of cars because the braking distance is beyond line of sight.
You could run more trains only between the suburban branches but there isn't a whole lot of demand for that.
Coupling / decoupling at high frequencies would be a challenge for sure - but seems achievable in a world of fully autonomous vehicles that can communicate.
Right now to ensure absolute safety trains are mechanically coupled, which can't be done while moving, and takes a few minutes to do safely.
I believe most AV convoys propose virtual coupling to get around this, but the failure scenario where something in the convoy comes to a sudden stop and the other things in the convoy don't, is pretty gnarly. Modern trains have a bunch of mandated safety measures in their mechanical coupling to prevent nasty things like jackknifing, or even worse, telescoping https://en.wikipedia.org/wiki/Telescoping_(rail_cars)
This is speculation but I wonder if you could have cars couple with "cat whiskers" that are mechanical but not load bearing. so you don't need to rely on wireless comms for coordination
I’m not sure what load bearing means in this context.
Generally speaking mechanical coupling takes a while because you really, really do not want an errant car to detach during its journey. In the worst possible case scenario, a rear carriage has decoupled from a train and then the following one has crashed into said carriage. https://localtvkstu.wordpress.com/2013/11/05/crews-respond-t...
> If we are asking a customer or end-user to do something they wouldn’t naturally do already we are making it harder for them to use our product…
The iRobot product line barely works without rearranging and adapting all of your furniture and floor space.
Yes but you are not asking them to also buy a 10k USD lidar scanner to map their homes.
The core of the argument is: you're already selling an expensive robot, don't force your customers to buy a second expensive thing.
What kind of furniture lets the robot vacuum under it and around its legs in the place it typically goes? What apartments and homes are large enough to have a robot-width distance between walls, corners and everything that is on the floor? How much do you think Ligne Roset sofas cost? And at $1,000/sqft, surely a lidar can be cheap in comparison. You're kind of proving my point of how off the mark iRobot is.
> What kind of furniture lets the robot vacuum under it and around its legs in the place it typically goes? What apartments and homes are large enough to have a robot-width distance between walls, corners and everything that is on the floor?
This isn't actually a problem.
If the robot vacuum cleaner is 10cm high, any furniture where the gap below it is <9cm the robot will detect with its bump sensor and avoid. Any furniture where the gap is >11cm high, the robot will clean under no problem. The only problem is furniture with a gap in the 9-11cm range. For that you can either buy a different sized robot, or raise or lower the furniture.
Of course you'll have to avoid leaving trailing cables on the floor - but that makes your home neater anyway, so no problem.
You can buy a Lidar robot if you want, of course - the classic random-driving-around Roomba is very much a product of its time.
I have a coffee table my vaccum robot goes under. It also manages to go under the sink in the bathroom.
Some good advice here!
Too often I've heard: why make a robot open doors with it manipulator, just install a door opener on the door! Fits the bill here exactly: making a better robot helps you scale. Only relatively recently that robots opening doors became a reasonable thing to ask fo, but not much robots yet that do this at scale I think.
The true answer is that it is hard, and requies very carefull analysis.
Putting a “door opener” on the robot is sometimes at no extra marginal cost. (Because it already has a manipulator to fullfill its job.) Sometimes it would make the robot cost prohibitive, and the correct solution is to use automatic doors. Depends on how many doors there are and how many robots, and what kind of robot and what kind of door.
Then again even if the correct solution in a particular situation is to add door opening manipulators on the robots very likely you would only want to support a few different kinds of handles. Imagine the complications of trying to support all door handles from baroque brass levers through modern spherical knobs to dogged doors the kind you find on a warship.
Outside of research labs and Boston Dynamics, can you point me to any robots with door openers?
I’m not aware of any. If a particular problem domain would require the robots to use door handles I would identify that as a big risk to the project. Not impossible to solve, but a significant problem.
This is solid advice, particularly #4 is the reason I have started building my own bots. I do have one question though, how to design the production pipeline such that it is easy to iterate on the bot design with minimal disruption?
While I agree with the other reply's "it depends" questions, at a high level there is one thing that I think applies pretty much whatever scope you're working on, with a few sub-points:
- Find robust parts for the non-innovative aspects of your system (eg motor drivers)
- ...with a standard interface (PWM/PPM, RS485, CAN, Ethernet, whatever)
- ...hide that interface behind a simple software interface so that if you do have to swap to a different bus type you can do so mostly transparently
- ...and don't reinvent the wheel if you don't have to.
Once you have a set of proven parts with well-defined simple interfaces you can start treating those like Lego and mix and match to your heart's content.
Rapid iteration at the component level would obviously require custom components, and maybe vertical integration, which clearly conflicts with point #1 about riding existing supply chains. But you can still iterate parts of the design that you more or less "have" to customize, such as the body material, axis geometries, and dozens of other factors I can't think of off the top of my head. The collected data can both be used to improve training and as input into the design iterations.
It depends.
What scale are you operating at, what sort of things do you want to iterate on, and how minimal does minimal disruption need to be? :)
I think part of the design craft is to ensure rapid prototyping and at the same time making sure that manufacturing is scalable. My question is more on how to hit the sweet spot where prototyping is fast and at the same time production pipeline changes are cost effective.
Where does one get part-level information to qualify a supply chain as "juicy"?
Otherwise the first advice looks like a 1st-world solution that independent 3rd-world developers can't deploy. Could early-stage companies even expect this from their investor/connectors?
Digikey has 32,000 in stock and your search filters yielded 100’s of nearly identical components from different manufacturers. This could mean using 4 pole switches when you only need 3 because toggles are typically 1,2, or 4 pole.
Digikey is sadly very expensive. It’s good for prototype. Or expensive industrial equipment. But for consumer goods one needs to go to China and source really cheap components optimized for large volume manufacturing.
As a first cut, here's two ideas:
- AliExpress/Alibaba/Taobao instead of Digikey
- tear down a mass produced product that has approximately the right size of part that you're looking for and see what you can find. If you're super lucky there'll be a generic part number on the item that you can use to do some research with. If you're less lucky, take some measurements (dimensions, RPM, torque, voltage, current, wavelength, whatever) and start looking around to see if there are manufacturers making generic versions of that part.
That's true, but grandparent's advice is a good way to pick standardized parts. If there are 4 versions of a switch with identical footprint on digikey, you can be pretty sure that you'll also be able to source it from Taobao or LCSC or something.
Are there any good blogs, communities, or Discords to get more into robotics? Specifically outdoor applications?
[flagged]