WEBVTT

1
00:00:00.080 --> 00:00:05.160
<v Speaker 1>Imagine a robot gliding silently through a bustling hotel, carrying

2
00:00:05.200 --> 00:00:09.039
<v Speaker 1>a delicious meal right to your table. A chef bot

3
00:00:09.400 --> 00:00:11.119
<v Speaker 1>sounds like something from the future, right.

4
00:00:11.039 --> 00:00:11.759
<v Speaker 2>Yeah, definitely.

5
00:00:12.279 --> 00:00:14.359
<v Speaker 1>Well, today we're kind of pulling back the curtain on

6
00:00:14.480 --> 00:00:17.640
<v Speaker 1>how such an autonomous marvel is actually designed and built,

7
00:00:17.920 --> 00:00:20.839
<v Speaker 1>you know, piece by painstaking piece from the ground up.

8
00:00:20.920 --> 00:00:21.879
<v Speaker 2>That's quite a process.

9
00:00:22.000 --> 00:00:24.719
<v Speaker 1>Our journey takes us deep into the pages of learning

10
00:00:24.800 --> 00:00:29.399
<v Speaker 1>robotics using Python second edition, and our mission for this

11
00:00:29.480 --> 00:00:32.479
<v Speaker 1>deep dive is to quickly and thoroughly extract the most

12
00:00:32.479 --> 00:00:36.439
<v Speaker 1>important insights, maybe some surprising facts too, about constructing a

13
00:00:36.479 --> 00:00:39.280
<v Speaker 1>mobile robot like our chef bot. We want to give

14
00:00:39.320 --> 00:00:42.679
<v Speaker 1>you a shortcut basically to being truly well informed without

15
00:00:42.719 --> 00:00:44.200
<v Speaker 1>all the usual information overload.

16
00:00:44.240 --> 00:00:45.679
<v Speaker 2>Sounds good, It's a great source for this.

17
00:00:45.759 --> 00:00:49.119
<v Speaker 1>So let's start with the robot's abstract brain. What exactly

18
00:00:49.280 --> 00:00:52.320
<v Speaker 1>is the robot operating system or ROS and why is

19
00:00:52.359 --> 00:00:55.479
<v Speaker 1>it considered well the indispensable backbone for building something as

20
00:00:55.520 --> 00:00:57.159
<v Speaker 1>complex as our chef bot.

21
00:00:57.479 --> 00:01:00.600
<v Speaker 2>Right, So, a crucial insight here is that ROS isn't

22
00:01:01.399 --> 00:01:04.200
<v Speaker 2>a traditional operating system like you'd find on your laptop

23
00:01:04.319 --> 00:01:06.840
<v Speaker 2>like Windows are my Coska. Think of it more as

24
00:01:06.879 --> 00:01:09.959
<v Speaker 2>a meta operating system, right, a flexible framework that sits

25
00:01:10.000 --> 00:01:12.920
<v Speaker 2>on top of a conventional OS, which is typically upon

26
00:01:13.000 --> 00:01:13.599
<v Speaker 2>two Linux.

27
00:01:13.840 --> 00:01:17.040
<v Speaker 1>Ah, okay, so it needs Linux underneath it exactly.

28
00:01:17.280 --> 00:01:20.760
<v Speaker 2>It's really the software architecture that elegantly ties all the

29
00:01:20.799 --> 00:01:25.239
<v Speaker 2>complex robotic parts sensors, motors, algorithms together.

30
00:01:25.480 --> 00:01:28.920
<v Speaker 1>So it's not standalone, but it's this crucial layer that

31
00:01:29.079 --> 00:01:33.560
<v Speaker 1>streamlines actually developing the robot. What are its main advantages then?

32
00:01:34.040 --> 00:01:37.319
<v Speaker 2>Precisely? One of its biggest strengths is code reuse. This

33
00:01:37.359 --> 00:01:40.280
<v Speaker 2>has really fostered a massive global R and D community.

34
00:01:40.599 --> 00:01:44.000
<v Speaker 2>Developers share these little programs called nodes and they buttle

35
00:01:44.040 --> 00:01:44.560
<v Speaker 2>them into.

36
00:01:44.359 --> 00:01:46.519
<v Speaker 1>Packages nodes and packages okay, yeah, and it.

37
00:01:46.480 --> 00:01:48.560
<v Speaker 2>Means you rarely have to reinvent the wheel for common

38
00:01:48.599 --> 00:01:51.599
<v Speaker 2>stuff like controlling a motor or reading a specific sensor.

39
00:01:52.120 --> 00:01:56.640
<v Speaker 2>Another huge benefit is language independence. How so well you

40
00:01:56.680 --> 00:01:59.079
<v Speaker 2>can write these notes in Python C plus plus OS

41
00:01:59.359 --> 00:02:02.920
<v Speaker 2>even less, and they'll all communicate seamlessly within ROS doesn't

42
00:02:02.920 --> 00:02:04.040
<v Speaker 2>care what language they're written in.

43
00:02:04.120 --> 00:02:05.560
<v Speaker 1>That's pretty flexible, it is.

44
00:02:05.920 --> 00:02:09.280
<v Speaker 2>It also includes built in frameworks for easy testing like

45
00:02:09.400 --> 00:02:14.879
<v Speaker 2>roast tist, and critically for handling the intense computations of

46
00:02:14.919 --> 00:02:19.919
<v Speaker 2>complex robots. It offers impressive scalability plus maybe the biggest

47
00:02:19.960 --> 00:02:21.919
<v Speaker 2>draw for many, it's free and open source.

48
00:02:22.080 --> 00:02:24.080
<v Speaker 1>Ah, open source always good.

49
00:02:24.199 --> 00:02:27.039
<v Speaker 2>Yeah, under a BSD license, so its core parts can

50
00:02:27.080 --> 00:02:29.960
<v Speaker 2>even be used in commercial products. That really speeds up

51
00:02:29.960 --> 00:02:31.439
<v Speaker 2>innovation across the whole industry.

52
00:02:31.479 --> 00:02:33.439
<v Speaker 1>You know, that makes a ton of sense for getting

53
00:02:33.479 --> 00:02:37.759
<v Speaker 1>things built faster. Are there any downsides to this metaos

54
00:02:37.759 --> 00:02:39.919
<v Speaker 1>approach or is it pretty much all good?

55
00:02:40.159 --> 00:02:43.319
<v Speaker 2>Well, I mean, nothing's perfect right. While it simplifies a lot,

56
00:02:43.360 --> 00:02:45.479
<v Speaker 2>the learning curve can be a bit steep at first.

57
00:02:45.560 --> 00:02:49.159
<v Speaker 2>There's just a lot to the ecosystem, but for complex systems,

58
00:02:49.439 --> 00:02:53.759
<v Speaker 2>the advantages usually outweigh that initial hump. And to really

59
00:02:53.759 --> 00:02:58.280
<v Speaker 2>get how ROS manages this distributed control, it helps an

60
00:02:58.360 --> 00:03:00.439
<v Speaker 2>understand its organization. It's sort of structure on three.

61
00:03:00.400 --> 00:03:02.280
<v Speaker 1>Level hiyh, three levels? Tell us more about how those

62
00:03:02.280 --> 00:03:02.800
<v Speaker 1>fit together.

63
00:03:02.879 --> 00:03:05.560
<v Speaker 2>Sure, first you've got the ROS file system. This is

64
00:03:05.599 --> 00:03:08.280
<v Speaker 2>basically how all the code and configuration files are organized

65
00:03:08.280 --> 00:03:09.520
<v Speaker 2>on your computer's.

66
00:03:09.039 --> 00:03:11.080
<v Speaker 1>Disc like folders and files pretty much.

67
00:03:11.439 --> 00:03:16.240
<v Speaker 2>The fundamental units are packages which contained everything source code, libraries,

68
00:03:16.280 --> 00:03:19.960
<v Speaker 2>configuration files, you name it. Each package has a special

69
00:03:20.000 --> 00:03:23.719
<v Speaker 2>file the manifest file. It's called package dot xml, which

70
00:03:23.840 --> 00:03:26.479
<v Speaker 2>details what's in the package and what other packages it

71
00:03:26.520 --> 00:03:29.360
<v Speaker 2>depends on dependencies. Okay, right, and then you have message

72
00:03:29.400 --> 00:03:33.039
<v Speaker 2>dot MSG and service dot SRV types. These are like

73
00:03:33.080 --> 00:03:36.159
<v Speaker 2>blueprints defining the data structures for how different parts of

74
00:03:36.159 --> 00:03:38.639
<v Speaker 2>the robot will communicate, what kind of data they'll send

75
00:03:38.680 --> 00:03:39.319
<v Speaker 2>back and forth.

76
00:03:39.439 --> 00:03:42.439
<v Speaker 1>So that's the structure. What's the next level, the action part?

77
00:03:42.719 --> 00:03:46.159
<v Speaker 2>Exactly, moving from structure to action. The second level is

78
00:03:46.240 --> 00:03:49.879
<v Speaker 2>the ROS computation graph. This is the real time peer

79
00:03:49.919 --> 00:03:52.759
<v Speaker 2>to peer network where all the actual data processing happens

80
00:03:52.759 --> 00:03:53.599
<v Speaker 2>as the robot.

81
00:03:53.400 --> 00:03:54.879
<v Speaker 1>Runs peer to peer. Interesting.

82
00:03:55.080 --> 00:03:57.680
<v Speaker 2>Yeah, At his heart are the nodes. These are the

83
00:03:57.840 --> 00:04:02.400
<v Speaker 2>individual programs, the executables doing specific jobs like processing camera

84
00:04:02.439 --> 00:04:04.520
<v Speaker 2>images or deciding where to move next.

85
00:04:04.639 --> 00:04:06.800
<v Speaker 1>And how do these nodes find each other to talk?

86
00:04:07.080 --> 00:04:09.240
<v Speaker 2>Ah, that's where the ROS master comes in.

87
00:04:09.319 --> 00:04:09.599
<v Speaker 1>Yeah.

88
00:04:09.680 --> 00:04:12.599
<v Speaker 2>It acts like a central directory or maybe like a

89
00:04:12.680 --> 00:04:14.199
<v Speaker 2>DNS server for the nodes.

90
00:04:14.520 --> 00:04:15.840
<v Speaker 1>Okay, yeah, I get that analogy.

91
00:04:15.919 --> 00:04:18.519
<v Speaker 2>Without the master, nodes can't find each other to connect.

92
00:04:18.560 --> 00:04:21.120
<v Speaker 2>So it's absolutely essential for kicking things off.

93
00:04:21.079 --> 00:04:24.560
<v Speaker 1>Right, makes sense. It's crucial for that dynamic communication you

94
00:04:24.639 --> 00:04:27.519
<v Speaker 1>need in a changing environment. So once they've found each

95
00:04:27.519 --> 00:04:32.199
<v Speaker 1>other via the master. How do they actually exchange information?

96
00:04:32.600 --> 00:04:38.519
<v Speaker 2>Great question? Once connected nodes primarily communicate using ROS topics

97
00:04:38.519 --> 00:04:43.800
<v Speaker 2>and messages. Think of topics as dedicated radio channels, maybe

98
00:04:44.319 --> 00:04:48.680
<v Speaker 2>named channels for one to many communication. It's asynchronous asynchronous

99
00:04:48.720 --> 00:04:52.040
<v Speaker 2>meaning meaning a node just publishes data onto a topic

100
00:04:52.079 --> 00:04:54.160
<v Speaker 2>whenever it has data to is in, and any other

101
00:04:54.199 --> 00:04:56.759
<v Speaker 2>nodes that are subscribed to that topic will receive it eventually.

102
00:04:56.800 --> 00:04:58.240
<v Speaker 2>They don't have to be perfectly synced up.

103
00:04:58.279 --> 00:05:00.360
<v Speaker 1>Okay, so it's like broadcasting sort of.

104
00:05:00.439 --> 00:05:03.199
<v Speaker 2>Yeah, and the messages themselves are built from basic data

105
00:05:03.240 --> 00:05:06.120
<v Speaker 2>types numbers, text, true false values. A raise of those

106
00:05:06.720 --> 00:05:07.839
<v Speaker 2>keeps things standardized.

107
00:05:07.959 --> 00:05:10.240
<v Speaker 1>And what if you need a direct question and answer,

108
00:05:10.480 --> 00:05:12.399
<v Speaker 1>not just broadcasting for that.

109
00:05:12.360 --> 00:05:16.800
<v Speaker 2>You use services that's for synchronous request reply interactions. One

110
00:05:16.879 --> 00:05:20.000
<v Speaker 2>node sends a request, waits and gets a direct reply

111
00:05:20.079 --> 00:05:21.040
<v Speaker 2>back from another node.

112
00:05:21.120 --> 00:05:22.319
<v Speaker 1>Got it, request reply.

113
00:05:23.079 --> 00:05:26.199
<v Speaker 2>And finally there's something called bags. These are really useful.

114
00:05:26.399 --> 00:05:29.319
<v Speaker 2>They're a file format for recording and then replaying all

115
00:05:29.319 --> 00:05:32.680
<v Speaker 2>the data that went across ROS topics. Great for debugging

116
00:05:32.720 --> 00:05:34.680
<v Speaker 2>or testing offline without the actual robot.

117
00:05:34.879 --> 00:05:38.639
<v Speaker 1>Oh cool, like flight recorders for robots kind of yeah, And.

118
00:05:38.600 --> 00:05:41.000
<v Speaker 2>The third level is simply the ROS community level. This

119
00:05:41.079 --> 00:05:46.120
<v Speaker 2>isn't software, it's the ecosystem around ROS, things like ROS distributions,

120
00:05:46.120 --> 00:05:49.439
<v Speaker 2>specific versions like ROS Kinetic, which the book uses, online

121
00:05:49.480 --> 00:05:54.040
<v Speaker 2>code repositories like GitHub, the huge ROS wiki for documentation,

122
00:05:54.240 --> 00:05:58.160
<v Speaker 2>mailing lists, and ROS answers, which is basically stack overflow

123
00:05:58.279 --> 00:06:01.079
<v Speaker 2>just for ROS questions. So a big network, a huge,

124
00:06:01.199 --> 00:06:04.560
<v Speaker 2>vibrant and really helpful network. It's key to ros's success.

125
00:06:04.720 --> 00:06:06.920
<v Speaker 1>Okay, so we've laid out the digital foundation, the software

126
00:06:07.079 --> 00:06:09.839
<v Speaker 1>brain using ROS. But like you said, a brain needs

127
00:06:09.839 --> 00:06:13.000
<v Speaker 1>a body. So how do we connect this abstract intelligence

128
00:06:13.120 --> 00:06:17.120
<v Speaker 1>to a physical robot, something that can actually move through

129
00:06:17.120 --> 00:06:18.319
<v Speaker 1>a hotel carrying stuff?

130
00:06:18.680 --> 00:06:22.040
<v Speaker 2>Right the physical side. The very first step really in

131
00:06:22.079 --> 00:06:25.319
<v Speaker 2>building the physical robot is understanding how it's going to move.

132
00:06:25.879 --> 00:06:29.639
<v Speaker 2>It's fundamental movement principles. Our chef bot uses a differential

133
00:06:29.720 --> 00:06:30.360
<v Speaker 2>drive system.

134
00:06:30.480 --> 00:06:32.839
<v Speaker 1>Differential drive what's that exactly?

135
00:06:32.920 --> 00:06:35.240
<v Speaker 2>It's a really common and cost effective way to steer.

136
00:06:35.680 --> 00:06:39.079
<v Speaker 2>Think of like a classic roomba vacuum. It has two

137
00:06:39.160 --> 00:06:41.720
<v Speaker 2>main wheels on the same axis, and each one is

138
00:06:41.800 --> 00:06:43.480
<v Speaker 2>driven by its own separate motor.

139
00:06:43.759 --> 00:06:45.439
<v Speaker 1>Okay, two main drive wheels.

140
00:06:45.199 --> 00:06:48.040
<v Speaker 2>Yeah, controlled independently yeah, then it usually has one or

141
00:06:48.079 --> 00:06:50.199
<v Speaker 2>more passive caster wheels just for balance.

142
00:06:50.439 --> 00:06:54.279
<v Speaker 1>Simple enough, two wheels a castor. But I've heard terms

143
00:06:54.399 --> 00:06:58.199
<v Speaker 1>like non holonomic thrown around with these kinds of robots.

144
00:06:58.240 --> 00:07:00.000
<v Speaker 1>What does that mean for how chef bought moves?

145
00:07:00.199 --> 00:07:03.480
<v Speaker 2>Ah? Yeah, that's the key concept. Differential drive robots are

146
00:07:03.560 --> 00:07:06.759
<v Speaker 2>non holonomic systems. Think about your car for a second.

147
00:07:07.199 --> 00:07:10.000
<v Speaker 2>It can't just slide sideways into a parking spot, can it.

148
00:07:10.000 --> 00:07:12.600
<v Speaker 2>It has to turn his wheels and follow a curve right.

149
00:07:12.680 --> 00:07:15.120
<v Speaker 1>Yeah, parallel parking woes exactly.

150
00:07:15.600 --> 00:07:19.399
<v Speaker 2>So a non holonomic system is one whose movement is constrained.

151
00:07:20.079 --> 00:07:23.560
<v Speaker 2>It can't instantly move in any direction. Its possible motions

152
00:07:23.560 --> 00:07:26.560
<v Speaker 2>are limited, unlike say a drone, which can hover and

153
00:07:26.600 --> 00:07:29.079
<v Speaker 2>shift left, right, forward back instantly.

154
00:07:29.160 --> 00:07:31.439
<v Speaker 1>Okay, so it has movement constraints, got it.

155
00:07:31.519 --> 00:07:35.160
<v Speaker 2>And we also need to distinguish between robot kinematics and dynamics.

156
00:07:36.240 --> 00:07:39.480
<v Speaker 2>Kinematics is the math of motion without worrying about forces

157
00:07:39.560 --> 00:07:43.240
<v Speaker 2>like mass or inertia. It's purely about the geometry the

158
00:07:43.319 --> 00:07:47.279
<v Speaker 2>robot's position x Y and its orientation or heading usually

159
00:07:47.360 --> 00:07:48.120
<v Speaker 2>called yaw.

160
00:07:48.079 --> 00:07:49.720
<v Speaker 1>Just the geometry of movement right.

161
00:07:50.000 --> 00:07:53.319
<v Speaker 2>Dynamics, on the other hand does factor in forces, mass, friction,

162
00:07:53.480 --> 00:07:57.160
<v Speaker 2>motor power, acceleration, That gets much more complex. Usually, for

163
00:07:57.240 --> 00:07:59.480
<v Speaker 2>basic navigation we often start with kinematics.

164
00:07:59.519 --> 00:08:02.240
<v Speaker 1>Makes sense, start simpler, Yeah, So for.

165
00:08:02.279 --> 00:08:06.079
<v Speaker 2>Chef bot, a critical kinematics problem is forward kinematics. The

166
00:08:06.160 --> 00:08:09.399
<v Speaker 2>question is, if you know the robot's current position, and

167
00:08:09.439 --> 00:08:11.759
<v Speaker 2>you know how fast the left and right wheels are spinning,

168
00:08:12.079 --> 00:08:14.040
<v Speaker 2>can you predict where it will be a moment later?

169
00:08:14.519 --> 00:08:17.920
<v Speaker 1>Predicting the future position based on wheel speeds exactly?

170
00:08:18.160 --> 00:08:21.279
<v Speaker 2>A key concept here is the instantaneous center of curvature

171
00:08:21.680 --> 00:08:25.560
<v Speaker 2>or ICC. That's the imaginary point the robot is pivoting

172
00:08:25.600 --> 00:08:29.040
<v Speaker 2>around as it turns. Calculating this involves the wheel speeds,

173
00:08:29.040 --> 00:08:32.039
<v Speaker 2>the wheel radius, the distance between the wheels, and it

174
00:08:32.080 --> 00:08:35.159
<v Speaker 2>relies heavily on center data like from wheel encoders that

175
00:08:35.279 --> 00:08:36.919
<v Speaker 2>track how much each wheel has turned.

176
00:08:37.120 --> 00:08:40.200
<v Speaker 1>Okay, so encoders tell you wheel rotation. That feeds into

177
00:08:40.360 --> 00:08:44.559
<v Speaker 1>calculating the ICC, which helps predict motion. What about the

178
00:08:44.559 --> 00:08:45.679
<v Speaker 1>other way around, that's.

179
00:08:45.519 --> 00:08:48.679
<v Speaker 2>Inverse kinematics, the reverse problem. If you know where you

180
00:08:48.720 --> 00:08:51.200
<v Speaker 2>want the robot to go, how fast you need to

181
00:08:51.200 --> 00:08:52.600
<v Speaker 2>spin each wheel to get it there?

182
00:08:52.759 --> 00:08:55.039
<v Speaker 1>Figuring out the wheel speeds for a desired goal.

183
00:08:55.279 --> 00:08:58.279
<v Speaker 2>Right. But here's the catch. For non holonomic robots like

184
00:08:58.399 --> 00:09:01.600
<v Speaker 2>chef bot. Because of those moves and constraints we mentioned inverse,

185
00:09:01.639 --> 00:09:05.320
<v Speaker 2>kinematics doesn't always have a single direct solution. You often

186
00:09:05.360 --> 00:09:07.639
<v Speaker 2>have to plan a path made of simpler segments.

187
00:09:07.720 --> 00:09:09.960
<v Speaker 1>Ah, So it's not as simple as just pointing and

188
00:09:09.960 --> 00:09:13.879
<v Speaker 1>saying go there. It requires continuous calculation and adjustment based

189
00:09:13.919 --> 00:09:15.279
<v Speaker 1>on those constraints precisely.

190
00:09:15.720 --> 00:09:18.960
<v Speaker 2>But the good news is you can achieve complex maneuvers

191
00:09:19.000 --> 00:09:22.679
<v Speaker 2>by combining very simple fundamental actions like what you well,

192
00:09:22.799 --> 00:09:26.320
<v Speaker 2>Moving perfectly straight just means spinning both wheels at the

193
00:09:26.360 --> 00:09:30.120
<v Speaker 2>exact same speed, okay, and rotating perfectly in place means

194
00:09:30.120 --> 00:09:33.840
<v Speaker 2>spinning the wheels at the same speed, but in opposite directions.

195
00:09:33.559 --> 00:09:35.960
<v Speaker 1>Left forward, right, backward, or vice versa.

196
00:09:36.000 --> 00:09:39.679
<v Speaker 2>Exactly. By sequencing these simple moves, go straight a bit,

197
00:09:39.879 --> 00:09:42.840
<v Speaker 2>turn in place, go straight again, the chef bod can

198
00:09:42.960 --> 00:09:46.759
<v Speaker 2>navigate quite effectively through complex spaces like a hotel floor.

199
00:09:46.960 --> 00:09:49.559
<v Speaker 1>Okay, this is where the engineering gets really interesting. I

200
00:09:49.600 --> 00:09:53.480
<v Speaker 1>think applying these principles directly to the chef bod, what

201
00:09:53.519 --> 00:09:58.879
<v Speaker 1>were the specific concrete design challenges and the hardware choices

202
00:09:58.919 --> 00:10:01.840
<v Speaker 1>they had to make for this service robot, well.

203
00:10:01.720 --> 00:10:04.519
<v Speaker 2>The chef Box project had some really specific goals and

204
00:10:04.600 --> 00:10:07.519
<v Speaker 2>honestly quite aggressive ones. For the budget, it needed to

205
00:10:07.519 --> 00:10:10.600
<v Speaker 2>carry a two kilogram payload that's about four point four pounds.

206
00:10:10.440 --> 00:10:11.879
<v Speaker 1>Okay, decent load for food choice.

207
00:10:12.000 --> 00:10:14.399
<v Speaker 2>Yeah. It needed to move at a speed between point

208
00:10:14.399 --> 00:10:17.279
<v Speaker 2>twenty five and point three five meters per second. That's

209
00:10:17.320 --> 00:10:20.480
<v Speaker 2>a brisk walking pace. It needed ground clearance over three

210
00:10:20.519 --> 00:10:23.519
<v Speaker 2>centimeters to get over you know, small thresholder.

211
00:10:23.000 --> 00:10:26.080
<v Speaker 1>Bumps important in real world floors.

212
00:10:25.399 --> 00:10:29.000
<v Speaker 2>Definitely, and over an hour of continuous battery life, plus

213
00:10:29.080 --> 00:10:32.159
<v Speaker 2>of course, robust obstacle avoidance. It needed a height between

214
00:10:32.159 --> 00:10:35.200
<v Speaker 2>eighty and one hundred centimeters to be practical for interacting

215
00:10:35.200 --> 00:10:35.799
<v Speaker 2>with tables or.

216
00:10:35.840 --> 00:10:36.639
<v Speaker 1>People right height.

217
00:10:36.679 --> 00:10:40.000
<v Speaker 2>Yeah, and the real kicker a strict budget of less

218
00:10:40.000 --> 00:10:41.759
<v Speaker 2>than five hundred US dollars.

219
00:10:41.919 --> 00:10:45.559
<v Speaker 1>Wow, under five hundred dollars for a fully autonomous service robot.

220
00:10:45.720 --> 00:10:48.360
<v Speaker 1>That sounds incredibly challenging. It must have forced some really

221
00:10:48.399 --> 00:10:49.559
<v Speaker 1>clever engineering choices.

222
00:10:49.600 --> 00:10:54.480
<v Speaker 2>Absolutely, that budget constraint shapes everything. So for the mechanical design,

223
00:10:54.600 --> 00:10:57.480
<v Speaker 2>they confirmed using that differential drive system we talked about.

224
00:10:57.720 --> 00:11:00.320
<v Speaker 2>They did detailed calculations to figure out the required motor

225
00:11:00.399 --> 00:11:03.799
<v Speaker 2>rpm turns out it was about eighty rpm and then

226
00:11:03.840 --> 00:11:08.440
<v Speaker 2>necessary torque around eighteen kilogram centimeters based on the target

227
00:11:08.480 --> 00:11:13.120
<v Speaker 2>speed payload and a chosen wheel diameter of nine centimeters.

228
00:11:12.679 --> 00:11:15.759
<v Speaker 1>So physics calculations drive the motor choice directly.

229
00:11:15.960 --> 00:11:18.399
<v Speaker 2>For the chassis, they went with a multi layered architecture.

230
00:11:18.559 --> 00:11:21.320
<v Speaker 2>It's similar in concept to the popular turtle Bot two robot,

231
00:11:21.639 --> 00:11:24.320
<v Speaker 2>which provides good stability and makes it easier to organize

232
00:11:24.320 --> 00:11:27.000
<v Speaker 2>all the electronic components neatly on different levels.

233
00:11:27.039 --> 00:11:30.720
<v Speaker 1>Smart and how do they design and visualize this without

234
00:11:30.799 --> 00:11:34.200
<v Speaker 1>expensive software? Given the budget great point.

235
00:11:33.840 --> 00:11:36.440
<v Speaker 2>They leaned heavily on free and open source CAD tools.

236
00:11:36.840 --> 00:11:39.879
<v Speaker 2>They use libracad for the two D drawings needed for

237
00:11:40.159 --> 00:11:45.039
<v Speaker 2>manufacturing parts. For three D modeling, they use Blender, which

238
00:11:45.080 --> 00:11:47.440
<v Speaker 2>is amazing. It's mostly known for animation, but it's a

239
00:11:47.440 --> 00:11:51.879
<v Speaker 2>capable modeler. They even use Python scripting within Blender to

240
00:11:52.039 --> 00:11:54.360
<v Speaker 2>automate some design tasks, which is pretty slick.

241
00:11:54.480 --> 00:11:56.279
<v Speaker 1>Python scripting in Blender nice.

242
00:11:56.440 --> 00:11:59.679
<v Speaker 2>Yeah, And then they use mesh lab, another open source tool,

243
00:12:00.159 --> 00:12:02.679
<v Speaker 2>just for viewing and inspecting the three D models. It

244
00:12:02.720 --> 00:12:04.440
<v Speaker 2>shows how much you can do with free tools if

245
00:12:04.480 --> 00:12:05.440
<v Speaker 2>you know how to use them.

246
00:12:05.519 --> 00:12:08.120
<v Speaker 1>It really does. Okay, So that's the physical structure. What

247
00:12:08.159 --> 00:12:10.919
<v Speaker 1>about the electronic brain and the senses, the parts that

248
00:12:10.960 --> 00:12:13.120
<v Speaker 1>make it actually do things and perceive the world.

249
00:12:13.200 --> 00:12:17.039
<v Speaker 2>Right. The electronics they selected specific pololu DC gear motors

250
00:12:17.039 --> 00:12:20.279
<v Speaker 2>that conveniently came with built in quadrature encoders.

251
00:12:19.919 --> 00:12:22.360
<v Speaker 1>AH encoders built in Handy.

252
00:12:22.399 --> 00:12:26.080
<v Speaker 2>Very Those encoders are vital, providing data on both how

253
00:12:26.159 --> 00:12:29.279
<v Speaker 2>much each wheel has turned and in which direction, crucial

254
00:12:29.320 --> 00:12:32.799
<v Speaker 2>for tracking movement accurately. To control these motors, they used

255
00:12:32.840 --> 00:12:36.480
<v Speaker 2>to Polo duel VNH two SP thirty H bridge. That's

256
00:12:36.519 --> 00:12:39.240
<v Speaker 2>the motor driver chip. It takes simple signals direction and

257
00:12:39.279 --> 00:12:42.600
<v Speaker 2>speed and provides the actual power to the motors. Speed

258
00:12:42.679 --> 00:12:45.360
<v Speaker 2>is controlled using PWM pulsewidth.

259
00:12:44.840 --> 00:12:48.519
<v Speaker 1>Modulation PWM right, varying the pulse width to control power.

260
00:12:48.639 --> 00:12:52.279
<v Speaker 2>Exactly the brain of this low level system. The thing

261
00:12:52.320 --> 00:12:55.639
<v Speaker 2>interfacing directly with sensors and motors is the Texas Instrument's

262
00:12:55.720 --> 00:12:58.679
<v Speaker 2>TVC launch pad. It's a capable little thirty two bit

263
00:12:58.759 --> 00:12:59.960
<v Speaker 2>AIRM microcontroller.

264
00:13:00.360 --> 00:13:03.879
<v Speaker 1>The micro controller handles the immediate real time stuff precisely.

265
00:13:03.919 --> 00:13:05.639
<v Speaker 2>It acts as the central hub for all the low

266
00:13:05.720 --> 00:13:09.679
<v Speaker 2>level hardware. Now really crucial practical detail here they needed

267
00:13:09.679 --> 00:13:12.039
<v Speaker 2>a three point three volt to five volt bi directional

268
00:13:12.120 --> 00:13:14.720
<v Speaker 2>level shifter level shifter. Why because the TVC launch pad

269
00:13:14.759 --> 00:13:17.840
<v Speaker 2>runs at three point three volts, but many common robot

270
00:13:17.879 --> 00:13:20.039
<v Speaker 2>components like that motor driver and some sensors like the

271
00:13:20.120 --> 00:13:23.000
<v Speaker 2>ultrasonic ones, they need five volts if you connect them directly.

272
00:13:23.279 --> 00:13:26.720
<v Speaker 1>Zap Ah Fried components not good on a five hundred dollars.

273
00:13:26.519 --> 00:13:30.000
<v Speaker 2>Budget, definitely not so. This little level shifter board is

274
00:13:30.120 --> 00:13:33.039
<v Speaker 2>essential to let the three point three V micro controller

275
00:13:33.399 --> 00:13:35.639
<v Speaker 2>talk safely to the five ve components and vice versa.

276
00:13:36.440 --> 00:13:39.960
<v Speaker 2>It's an easy detail to overlook, but absolutely critical for

277
00:13:40.000 --> 00:13:42.919
<v Speaker 2>making the hardware actually work together without damage right.

278
00:13:43.080 --> 00:13:46.360
<v Speaker 1>Making sure everything speaks the same voltage language. Good tip.

279
00:13:46.720 --> 00:13:49.240
<v Speaker 1>What about its senses? How does it perceive the world

280
00:13:49.240 --> 00:13:49.759
<v Speaker 1>around it?

281
00:13:50.279 --> 00:13:53.840
<v Speaker 2>So for sensors, they used a few types ultrasonic sensors,

282
00:13:53.840 --> 00:13:57.799
<v Speaker 2>the common HCSR zero war four model for basic short

283
00:13:57.879 --> 00:14:01.600
<v Speaker 2>range obstacle detection like batsy sonar are these use sound waves.

284
00:14:01.679 --> 00:14:04.000
<v Speaker 1>Cheap and cheerful obstacle avoidance pretty much.

285
00:14:04.360 --> 00:14:08.320
<v Speaker 2>Then an IMU, an inertial measurement unit, specifically the MPU

286
00:14:08.360 --> 00:14:11.240
<v Speaker 2>sixty to fifty chip. This combines an accelerometer and a

287
00:14:11.320 --> 00:14:12.600
<v Speaker 2>gyroscope on one chip.

288
00:14:12.679 --> 00:14:14.039
<v Speaker 1>What is the IMU add.

289
00:14:14.039 --> 00:14:17.039
<v Speaker 2>It significantly improves the robot's estimate of its own position

290
00:14:17.120 --> 00:14:20.399
<v Speaker 2>and orientation, what we call odometry. Wheel encoders alone can

291
00:14:20.399 --> 00:14:23.759
<v Speaker 2>slip or drift, especially on turns. The IMU data helps

292
00:14:23.799 --> 00:14:26.279
<v Speaker 2>correct for those errors, giving a much more accurate picture

293
00:14:26.279 --> 00:14:27.360
<v Speaker 2>of the robot's movement.

294
00:14:27.440 --> 00:14:29.320
<v Speaker 1>Betterrodometry, got it and vision.

295
00:14:29.600 --> 00:14:32.519
<v Speaker 2>For vision, they use a three D vision sensor, either

296
00:14:32.519 --> 00:14:35.799
<v Speaker 2>a Microsoft Connect the older Xbox three sixty one is

297
00:14:35.840 --> 00:14:39.960
<v Speaker 2>popular in robotics, or an orbec Astra. These are brilliant

298
00:14:40.000 --> 00:14:42.360
<v Speaker 2>because they capture not just a regular color image, but

299
00:14:42.399 --> 00:14:45.600
<v Speaker 2>also depth information for every pixel. They output a three

300
00:14:45.679 --> 00:14:46.360
<v Speaker 2>D point.

301
00:14:46.200 --> 00:14:49.320
<v Speaker 1>Cloud depth camera, so at season three D exactly.

302
00:14:49.639 --> 00:14:51.600
<v Speaker 2>And this is a very clever choice because this depth

303
00:14:51.679 --> 00:14:54.919
<v Speaker 2>data can be processed to mimic the functionality of a

304
00:14:55.039 --> 00:14:58.159
<v Speaker 2>lid ar, a laser scanner, which is usually much much

305
00:14:58.159 --> 00:15:01.639
<v Speaker 2>more expensive. It's key for building detailed maps of the environment.

306
00:15:01.799 --> 00:15:05.039
<v Speaker 1>Ah mimicking light ar on a budget smart very smart.

307
00:15:05.120 --> 00:15:07.759
<v Speaker 2>Now, all the sensor data and the complex planning that

308
00:15:07.799 --> 00:15:10.840
<v Speaker 2>requires more computing power than a little TVC micro controller

309
00:15:10.879 --> 00:15:13.600
<v Speaker 2>can handle. So for the high level processing there's an

310
00:15:13.600 --> 00:15:15.559
<v Speaker 2>Intel NUCPC on board.

311
00:15:15.320 --> 00:15:17.759
<v Speaker 1>The small PC running the main show right.

312
00:15:17.639 --> 00:15:20.480
<v Speaker 2>Running Ubuntu and the main ROS system. It does the

313
00:15:20.519 --> 00:15:24.440
<v Speaker 2>heavy lifting navigation, mapping, decision making, and for interacting with people.

314
00:15:24.440 --> 00:15:26.960
<v Speaker 2>It has speakers and a microphone for potential voice commands

315
00:15:26.960 --> 00:15:28.000
<v Speaker 2>and Texas speech.

316
00:15:27.720 --> 00:15:30.799
<v Speaker 1>Feedback talking robot potential YEP.

317
00:15:31.320 --> 00:15:34.480
<v Speaker 2>And finally, powering all of this is a hefty twelve

318
00:15:34.559 --> 00:15:38.320
<v Speaker 2>volt ten amp hour battery, either lithium polymer or sealed

319
00:15:38.360 --> 00:15:41.240
<v Speaker 2>lead acid, depending on costs and safety trade offs to

320
00:15:41.360 --> 00:15:43.960
<v Speaker 2>meet that one hour plus runtime requirement.

321
00:15:44.039 --> 00:15:47.679
<v Speaker 1>Okay, wow, we've basically built the hardware now, selected all

322
00:15:47.720 --> 00:15:50.759
<v Speaker 1>the key parts, even designed at digitally using open source tools.

323
00:15:50.840 --> 00:15:53.399
<v Speaker 1>Now the really big challenge, right, how do we inject

324
00:15:53.440 --> 00:15:56.480
<v Speaker 1>the intelligence? How do we make this chef bot truly

325
00:15:56.519 --> 00:15:57.639
<v Speaker 1>smart and autonomous?

326
00:15:57.759 --> 00:16:00.200
<v Speaker 2>Right? This is where the software sophistication really canes comes

327
00:16:00.240 --> 00:16:03.759
<v Speaker 2>in and it raises a super important practical question. Before

328
00:16:03.840 --> 00:16:06.320
<v Speaker 2>you unleash this robot in a real hotel, how do

329
00:16:06.360 --> 00:16:10.639
<v Speaker 2>you test its brain, its algorithms, its navigation logic safely

330
00:16:10.679 --> 00:16:11.240
<v Speaker 2>and efficiently.

331
00:16:11.320 --> 00:16:13.200
<v Speaker 1>Yeah, you don't want it crashing into guests on its

332
00:16:13.200 --> 00:16:14.360
<v Speaker 1>first run exactly.

333
00:16:14.480 --> 00:16:17.440
<v Speaker 2>This is where robot simulation is absolutely indispensable. And the

334
00:16:17.480 --> 00:16:19.960
<v Speaker 2>tool of choice in the ROS world is Gazebo.

335
00:16:20.080 --> 00:16:21.799
<v Speaker 1>Gazebo heard of it? What does it do?

336
00:16:21.960 --> 00:16:25.120
<v Speaker 2>Gazebo is a powerful three D robot simulator. It lets

337
00:16:25.120 --> 00:16:27.679
<v Speaker 2>you create a virtual world, import a model of your robot,

338
00:16:27.759 --> 00:16:31.240
<v Speaker 2>and test its behavior realistically. It simulates physics, sensors, everything,

339
00:16:31.399 --> 00:16:34.279
<v Speaker 2>and critically. It integrates very tightly with ROS.

340
00:16:34.639 --> 00:16:36.240
<v Speaker 1>How does that integration work?

341
00:16:36.519 --> 00:16:39.679
<v Speaker 2>Well, You define your robots model using RDF, which is

342
00:16:39.720 --> 00:16:43.200
<v Speaker 2>an XML format ROS uses to describe robot structures. You

343
00:16:43.240 --> 00:16:47.440
<v Speaker 2>add special Gazebo tags to this RDF file to specify

344
00:16:47.559 --> 00:16:50.720
<v Speaker 2>simulation properties like how much friction the wheels have, what

345
00:16:50.799 --> 00:16:52.879
<v Speaker 2>the robot looks like visually in the simulation.

346
00:16:53.039 --> 00:16:55.360
<v Speaker 1>So you describe the robot for the simulation.

347
00:16:55.519 --> 00:17:00.480
<v Speaker 2>Yes, and then Gazebo ROS plugins handle the magic plugins

348
00:17:00.480 --> 00:17:05.720
<v Speaker 2>that simulate a differential drive, depth, cameras, imus ultrasonic sensors,

349
00:17:06.039 --> 00:17:09.720
<v Speaker 2>and these plugins publish their simulated sensor data as standard

350
00:17:09.799 --> 00:17:12.400
<v Speaker 2>ROS topics, exactly like their real hardware would.

351
00:17:12.640 --> 00:17:15.400
<v Speaker 1>WHOA, So the rest of your ROS software doesn't even

352
00:17:15.440 --> 00:17:18.039
<v Speaker 1>know if it's talking to the real robot or the simulation.

353
00:17:18.279 --> 00:17:20.559
<v Speaker 2>Pretty much, that's the beauty of it. You can develop

354
00:17:20.599 --> 00:17:24.000
<v Speaker 2>and test almost your entire software stack in simulation first.

355
00:17:23.839 --> 00:17:26.599
<v Speaker 1>So you can essentially build and test the robot virtually

356
00:17:26.640 --> 00:17:28.759
<v Speaker 1>before you even I don't know, cut the first piece

357
00:17:28.799 --> 00:17:31.119
<v Speaker 1>of metal or a solder a single connection. That must

358
00:17:31.200 --> 00:17:33.119
<v Speaker 1>be a massive time and cost saver.

359
00:17:33.240 --> 00:17:38.160
<v Speaker 2>Oh, absolutely huge. This virtual prototyping is invaluable, especially on

360
00:17:38.200 --> 00:17:41.200
<v Speaker 2>a tight budget. Now, once you move to the real hardware,

361
00:17:41.599 --> 00:17:44.119
<v Speaker 2>you need that bridge between the low level micro controller

362
00:17:44.119 --> 00:17:46.720
<v Speaker 2>and the high level ROS system. That's the job of

363
00:17:46.759 --> 00:17:49.240
<v Speaker 2>the ROS Python driver, which is part of a package

364
00:17:49.279 --> 00:17:50.160
<v Speaker 2>called chefbot.

365
00:17:50.200 --> 00:17:52.400
<v Speaker 1>Bring up the driver node. What's its role?

366
00:17:52.680 --> 00:17:56.039
<v Speaker 2>It essentially acts as the translator. Remember the TVC launch

367
00:17:56.079 --> 00:17:58.839
<v Speaker 2>pad micro controller handling the motors and basic sensors.

368
00:17:58.920 --> 00:18:00.440
<v Speaker 1>Yeah, the low level brain right.

369
00:18:00.720 --> 00:18:03.960
<v Speaker 2>This Python node runs on the main PC the nu

370
00:18:04.079 --> 00:18:07.720
<v Speaker 2>SE and communicates with the launchpad, usually over a serial

371
00:18:07.720 --> 00:18:11.200
<v Speaker 2>connection like USB. It reads the raw sensor values the

372
00:18:11.279 --> 00:18:14.119
<v Speaker 2>encoder counts the ultrasonic distance is the IMU data that

373
00:18:14.160 --> 00:18:16.599
<v Speaker 2>the launch pad sends, gets the raw data yes, and

374
00:18:16.640 --> 00:18:20.720
<v Speaker 2>then it converts that raw data into standardized ROS messages

375
00:18:20.920 --> 00:18:24.680
<v Speaker 2>and publishes them onto the appropriate ROS topics like well

376
00:18:24.720 --> 00:18:27.599
<v Speaker 2>wheel or wheel ultrasonic distance emute data.

377
00:18:27.680 --> 00:18:29.759
<v Speaker 1>So it makes the low level data available to the

378
00:18:29.759 --> 00:18:31.640
<v Speaker 1>rest of the ROS system.

379
00:18:31.240 --> 00:18:33.839
<v Speaker 2>Exactly, and it works the other way too. It subscribes

380
00:18:33.839 --> 00:18:36.960
<v Speaker 2>to high level command topics from ROS, typically receiving desired

381
00:18:37.000 --> 00:18:40.400
<v Speaker 2>linear and angular velocities, and translates those back into the

382
00:18:40.400 --> 00:18:43.599
<v Speaker 2>specific motor commands that the launch pad understands and sends

383
00:18:43.640 --> 00:18:44.920
<v Speaker 2>them down over cereal.

384
00:18:45.079 --> 00:18:48.359
<v Speaker 1>Okay, so data flows up commands full down translated by

385
00:18:48.359 --> 00:18:51.279
<v Speaker 1>this driver node. Now, once that sensor data is flowing

386
00:18:51.359 --> 00:18:54.720
<v Speaker 1>nicely within ROS, how does the chef box start to

387
00:18:55.599 --> 00:18:58.240
<v Speaker 1>understand its own movements better and make sense of its

388
00:18:58.240 --> 00:18:59.359
<v Speaker 1>surroundings For navigation?

389
00:19:00.039 --> 00:19:03.440
<v Speaker 2>That's where the core intelligence lies within the sophisticated ROS

390
00:19:03.519 --> 00:19:06.839
<v Speaker 2>navigation stack. This is a collection of ROS packages that

391
00:19:06.920 --> 00:19:09.359
<v Speaker 2>provide the algorithms for autonomous movement.

392
00:19:09.519 --> 00:19:11.480
<v Speaker 1>A navigation stack. What's in it.

393
00:19:11.839 --> 00:19:16.240
<v Speaker 2>Several key pieces. First, it performs odometry calculation. It takes

394
00:19:16.279 --> 00:19:18.680
<v Speaker 2>the raw data from the wheel encoders and the IMU

395
00:19:18.880 --> 00:19:21.279
<v Speaker 2>and fuses them together to get a much more accurate

396
00:19:21.400 --> 00:19:25.519
<v Speaker 2>estimate of the robots position and orientation change over short periods.

397
00:19:25.920 --> 00:19:27.519
<v Speaker 2>This is its local sense of movement.

398
00:19:27.640 --> 00:19:29.880
<v Speaker 1>Fusing sensors for better odometry makes sense.

399
00:19:30.119 --> 00:19:35.559
<v Speaker 2>Then there are PID controllers, PID stands, for proportional integral derivative.

400
00:19:36.119 --> 00:19:40.000
<v Speaker 2>It's a classic control loop algorithm. There's usually one PID

401
00:19:40.119 --> 00:19:41.119
<v Speaker 2>controller per wheel.

402
00:19:41.200 --> 00:19:42.400
<v Speaker 1>What do the PIDs do?

403
00:19:42.640 --> 00:19:45.599
<v Speaker 2>They take the target wheel velocities calculated by the higher

404
00:19:45.640 --> 00:19:49.599
<v Speaker 2>level navigation logic and convert them into the precise motor commands,

405
00:19:49.880 --> 00:19:53.000
<v Speaker 2>like the PWN values needed to make the wheels actually

406
00:19:53.000 --> 00:19:57.599
<v Speaker 2>spin at those target SPADs, compensating for friction load, battery

407
00:19:57.640 --> 00:20:02.119
<v Speaker 2>voltage changes, etc. They ensure the robot executes movements.

408
00:20:01.759 --> 00:20:03.720
<v Speaker 1>Accurately, fine tuning the motor commands.

409
00:20:03.799 --> 00:20:06.079
<v Speaker 2>Got it, And here's that really a genius solution for

410
00:20:06.160 --> 00:20:08.960
<v Speaker 2>mapping we touched on earlier. Yeah, using the depth camera data.

411
00:20:08.960 --> 00:20:11.680
<v Speaker 2>There's an ROS package called depth image to Laser.

412
00:20:11.400 --> 00:20:14.319
<v Speaker 1>Scan right, mimicking lighter exactly.

413
00:20:14.440 --> 00:20:16.400
<v Speaker 2>It takes the three D point cloud coming from the

414
00:20:16.519 --> 00:20:19.880
<v Speaker 2>connector astra camera, Yeah, slices it horizontally at a certain height,

415
00:20:20.200 --> 00:20:22.880
<v Speaker 2>and converts that slice into a message that looks just

416
00:20:22.960 --> 00:20:24.599
<v Speaker 2>like the two D scan data you'd get from a

417
00:20:24.599 --> 00:20:25.680
<v Speaker 2>traditional laser scanner.

418
00:20:25.720 --> 00:20:26.279
<v Speaker 1>Clever trick.

419
00:20:26.319 --> 00:20:28.680
<v Speaker 2>Why do that because many of the most mature and

420
00:20:28.799 --> 00:20:33.720
<v Speaker 2>robust algorithms for mapping and localization in ROS were originally

421
00:20:33.759 --> 00:20:37.599
<v Speaker 2>developed for and expect input from two D laser scanners.

422
00:20:38.279 --> 00:20:41.920
<v Speaker 2>This package lets the chef bot use those powerful, well

423
00:20:41.960 --> 00:20:45.240
<v Speaker 2>tested algorithms even though it only has a cheaper depth camera.

424
00:20:45.480 --> 00:20:47.960
<v Speaker 1>Okay, super smart work round. So the chef bot now

425
00:20:48.000 --> 00:20:51.319
<v Speaker 1>has better odometry, it can control ease wheels precisely, and

426
00:20:51.359 --> 00:20:54.400
<v Speaker 1>it has this fake laser scan of its immediate surroundings.

427
00:20:54.880 --> 00:20:56.960
<v Speaker 1>But how does it then figure out where it is

428
00:20:57.000 --> 00:20:59.640
<v Speaker 1>within the whole hotel, build a map of that hotel

429
00:21:00.000 --> 00:21:02.359
<v Speaker 1>and plan how to get from say, the kitchen to

430
00:21:02.599 --> 00:21:04.079
<v Speaker 1>table five, all by itself.

431
00:21:04.240 --> 00:21:06.559
<v Speaker 2>Ah, the big picture. This is where we get into

432
00:21:06.559 --> 00:21:08.759
<v Speaker 2>simultaneous localization and mapping or.

433
00:21:08.799 --> 00:21:11.279
<v Speaker 1>SLAM SLAM heard that acronym a lot.

434
00:21:11.160 --> 00:21:14.400
<v Speaker 2>Yeah, it's fundamental to mobile robotics. It tackles that classic

435
00:21:14.480 --> 00:21:17.279
<v Speaker 2>chicken and egg problem. How do you build a map

436
00:21:17.319 --> 00:21:19.039
<v Speaker 2>of a place you've never seen before if you don't

437
00:21:19.039 --> 00:21:20.680
<v Speaker 2>know exactly where you are in that place? And how

438
00:21:20.720 --> 00:21:22.200
<v Speaker 2>do you figure out where you are if you don't

439
00:21:22.200 --> 00:21:22.480
<v Speaker 2>have a.

440
00:21:22.400 --> 00:21:24.720
<v Speaker 1>Map, right, it seems impossible. How does SLAM solve it?

441
00:21:24.839 --> 00:21:28.119
<v Speaker 2>SLAM algorithms like the g mapping package, which is commonly

442
00:21:28.200 --> 00:21:30.799
<v Speaker 2>used in ROS and mentioned in the book, do both

443
00:21:30.799 --> 00:21:34.000
<v Speaker 2>things at the same time as the robot moves around

444
00:21:34.119 --> 00:21:37.240
<v Speaker 2>using its sensors like our fake laser scan and the

445
00:21:37.279 --> 00:21:41.759
<v Speaker 2>improved odometry. G mapping incrementally build a two D grid

446
00:21:41.799 --> 00:21:45.440
<v Speaker 2>map of the environment and simultaneously estimates the robot's most

447
00:21:45.519 --> 00:21:48.799
<v Speaker 2>likely position within that map. They refine each other over time.

448
00:21:49.039 --> 00:21:51.319
<v Speaker 1>Wow. So it builds the map and figures out its

449
00:21:51.359 --> 00:21:53.559
<v Speaker 1>location iteratively exactly.

450
00:21:53.759 --> 00:21:57.240
<v Speaker 2>It's a probabilistic process, constantly updating beliefs about the map

451
00:21:57.400 --> 00:21:58.319
<v Speaker 2>and the robots post.

452
00:21:58.440 --> 00:22:01.960
<v Speaker 1>So practically, how do you actually create the map for

453
00:22:02.039 --> 00:22:02.599
<v Speaker 1>the hotel?

454
00:22:02.880 --> 00:22:05.559
<v Speaker 2>Typically you'd start the g mapping node, and then you'd

455
00:22:05.599 --> 00:22:08.519
<v Speaker 2>manually drive the robot around the entire area you wanted

456
00:22:08.519 --> 00:22:11.480
<v Speaker 2>to navigate, maybe using a keyboard a joystick to send

457
00:22:11.480 --> 00:22:13.559
<v Speaker 2>simple movement commands what's called tellyoperation.

458
00:22:13.880 --> 00:22:16.039
<v Speaker 1>Drive it around the hotel lobby and hallways.

459
00:22:16.240 --> 00:22:19.119
<v Speaker 2>Right as you drive it, G mapping builds the map

460
00:22:19.160 --> 00:22:21.400
<v Speaker 2>in real time. You can usually watch this happen in

461
00:22:21.440 --> 00:22:24.039
<v Speaker 2>a visualization tool like our viz. Once you've covered the

462
00:22:24.039 --> 00:22:26.200
<v Speaker 2>whole area, you save the completed map to a file.

463
00:22:26.279 --> 00:22:29.680
<v Speaker 1>Okay, map saved, Now what does it keep using? Slam?

464
00:22:29.920 --> 00:22:32.920
<v Speaker 2>Not usually for navigation. After the map is built. Once

465
00:22:32.960 --> 00:22:35.240
<v Speaker 2>you have a static map, you switch to a pure

466
00:22:35.359 --> 00:22:40.279
<v Speaker 2>localization algorithm. The common one in ROS is AMCL, which

467
00:22:40.319 --> 00:22:44.559
<v Speaker 2>stands for Adaptive Monty Carlo Localization AMCL.

468
00:22:44.640 --> 00:22:45.200
<v Speaker 1>What does that do?

469
00:22:45.440 --> 00:22:48.680
<v Speaker 2>AMCL takes the known pre built map and the robot's

470
00:22:48.680 --> 00:22:52.880
<v Speaker 2>current sensor readings again laser scans and odometry, and uses

471
00:22:52.920 --> 00:22:55.920
<v Speaker 2>a probabilistic method called a particle filter to figure out

472
00:22:55.920 --> 00:23:00.000
<v Speaker 2>the robot's most likely current position and orientation within that map.

473
00:23:00.119 --> 00:23:02.240
<v Speaker 2>It's very robust, even if the robot gets a bit

474
00:23:02.279 --> 00:23:03.920
<v Speaker 2>lost or kidnapped temporarily.

475
00:23:04.119 --> 00:23:07.319
<v Speaker 1>So SLAM for making the map, AMCL for tracking position

476
00:23:07.359 --> 00:23:10.160
<v Speaker 1>on the existing map, like the robot's indoor GPS.

477
00:23:10.240 --> 00:23:13.680
<v Speaker 2>That's a great analogy. Yeah, highly accurate indoor GPS using

478
00:23:13.720 --> 00:23:14.559
<v Speaker 2>the map and sensors.

479
00:23:14.599 --> 00:23:18.039
<v Speaker 1>Okay, So AMCL tells the chef bot precisely where it

480
00:23:18.119 --> 00:23:20.079
<v Speaker 1>is on the map. What then tells it where to

481
00:23:20.119 --> 00:23:22.279
<v Speaker 1>go and how to get there without hitting walls or people?

482
00:23:22.599 --> 00:23:24.640
<v Speaker 2>That is the job of the main navigation planner and

483
00:23:24.720 --> 00:23:28.039
<v Speaker 2>execution node, which in ROS is typically the move based node.

484
00:23:28.079 --> 00:23:31.839
<v Speaker 2>This is really the autonomous navigation brain. Move base the brain. Yeah,

485
00:23:32.039 --> 00:23:34.920
<v Speaker 2>it brings everything together. Yeah, it takes the map from

486
00:23:34.960 --> 00:23:37.880
<v Speaker 2>the map server. It takes the robot's current precise pose

487
00:23:37.920 --> 00:23:41.640
<v Speaker 2>from AMCL and it takes a target goal location like

488
00:23:41.680 --> 00:23:43.440
<v Speaker 2>the coordinates for a table five that you.

489
00:23:43.359 --> 00:23:45.480
<v Speaker 1>Give it Matt location goal right.

490
00:23:45.920 --> 00:23:49.519
<v Speaker 2>Then move Base uses sophisticated algorithms to plan a path

491
00:23:49.559 --> 00:23:52.559
<v Speaker 2>from the current location to the goal, making sure that

492
00:23:52.599 --> 00:23:56.200
<v Speaker 2>path avoids obstacles marked on the static map and any

493
00:23:56.279 --> 00:23:59.319
<v Speaker 2>new obstacles detected by the sensors in real time like

494
00:23:59.359 --> 00:24:00.279
<v Speaker 2>a person walking by.

495
00:24:00.359 --> 00:24:02.319
<v Speaker 1>So it plans a safe path, and then.

496
00:24:02.440 --> 00:24:04.920
<v Speaker 2>And then it starts executing that path, continuously sending the

497
00:24:04.960 --> 00:24:08.160
<v Speaker 2>appropriate speed commands those target linear and angular velocity. As

498
00:24:08.200 --> 00:24:11.200
<v Speaker 2>we mentioned down towards the robots motors via the PID

499
00:24:11.319 --> 00:24:15.400
<v Speaker 2>controllers and the driver, it constantly monitors progress, replans as

500
00:24:15.440 --> 00:24:18.799
<v Speaker 2>necessary if obstacles appear, and guides the robot autonomously to

501
00:24:18.839 --> 00:24:19.119
<v Speaker 2>the goal.

502
00:24:19.279 --> 00:24:21.920
<v Speaker 1>That's incredibly complex happening under the food.

503
00:24:22.119 --> 00:24:24.519
<v Speaker 2>It really is, Yeah, but it's amazing to watch it work,

504
00:24:24.599 --> 00:24:27.400
<v Speaker 2>especially when you use our viz, that ROS visualization tool.

505
00:24:27.839 --> 00:24:30.640
<v Speaker 2>You can see the map, the robot's position, the sensor data,

506
00:24:30.720 --> 00:24:33.839
<v Speaker 2>the path it's planning, even internal things like its cost

507
00:24:33.920 --> 00:24:37.400
<v Speaker 2>maps areas it calculates it should avoid due to proximity

508
00:24:37.440 --> 00:24:40.079
<v Speaker 2>to obstacles. It gives you a fantastic window into the

509
00:24:40.160 --> 00:24:40.880
<v Speaker 2>robot's mind.

510
00:24:41.000 --> 00:24:45.200
<v Speaker 1>Our vis for visualization sounds crucial for debugging too oh essential.

511
00:24:45.920 --> 00:24:49.440
<v Speaker 2>Now, what's really remarkable here thinking about the chefbot's purpose

512
00:24:49.799 --> 00:24:51.720
<v Speaker 2>is that for a robot like this to be actually

513
00:24:51.799 --> 00:24:55.319
<v Speaker 2>useful in a real hotel, it absolutely cannot rely on

514
00:24:55.359 --> 00:24:58.079
<v Speaker 2>someone typing complex ROS commands into a terminal.

515
00:24:58.319 --> 00:25:01.240
<v Speaker 1>In no way, the hotel staff, the waiters, they need

516
00:25:01.279 --> 00:25:03.200
<v Speaker 1>something simple, click and go exactly.

517
00:25:03.440 --> 00:25:07.240
<v Speaker 2>It is an intuitive, easy to use interface a GUI.

518
00:25:06.960 --> 00:25:09.319
<v Speaker 1>Right, a robot to UI. So what's the main purpose

519
00:25:09.359 --> 00:25:11.039
<v Speaker 1>there and what sort of tools did the book use

520
00:25:11.079 --> 00:25:12.559
<v Speaker 1>to build one for chef bot?

521
00:25:12.680 --> 00:25:15.119
<v Speaker 2>Well, the main purpose is exactly what you said, create

522
00:25:15.119 --> 00:25:18.640
<v Speaker 2>a simple control panel, abstract away all that underlying ROS

523
00:25:18.680 --> 00:25:22.599
<v Speaker 2>complexity for users who aren't robotics experts. For chef Bought,

524
00:25:22.640 --> 00:25:27.160
<v Speaker 2>the developers chose QT. Yeah. Qt is a very powerful,

525
00:25:27.240 --> 00:25:31.599
<v Speaker 2>widely used framework for building cross platform graphical user interfaces,

526
00:25:32.160 --> 00:25:36.319
<v Speaker 2>and crucially it has excellent Python bindings, specifically pi qt

527
00:25:36.440 --> 00:25:37.720
<v Speaker 2>or sometimes piside.

528
00:25:37.359 --> 00:25:40.240
<v Speaker 1>So you can build a GUI using Python yep, which.

529
00:25:40.079 --> 00:25:42.640
<v Speaker 2>Fits nicely since much of ROS development can be done

530
00:25:42.680 --> 00:25:47.519
<v Speaker 2>in Python. Two this combination QT with Piqute allows for

531
00:25:47.920 --> 00:25:51.440
<v Speaker 2>really rapid development. They even used a tool called Q Designer.

532
00:25:51.519 --> 00:25:52.480
<v Speaker 1>What's QT Designer.

533
00:25:52.720 --> 00:25:55.319
<v Speaker 2>It's a visual dragon drop tool. You can literally draw

534
00:25:55.400 --> 00:26:00.400
<v Speaker 2>your GUI place buttons, labels, textboxes, sliders, arrangement how you want,

535
00:26:00.519 --> 00:26:02.720
<v Speaker 2>and it generates the basic code structure for you.

536
00:26:03.079 --> 00:26:05.200
<v Speaker 1>Oh cool, So you design the look visually.

537
00:26:05.359 --> 00:26:07.200
<v Speaker 2>Yeah, it speeds things up tremendously.

538
00:26:07.279 --> 00:26:09.480
<v Speaker 1>Okay, so you can design a look, But how do

539
00:26:09.599 --> 00:26:11.960
<v Speaker 1>those visual elements like clicking a button that says go

540
00:26:12.039 --> 00:26:15.680
<v Speaker 1>to table five actually connect to the robot's ROS actions?

541
00:26:15.720 --> 00:26:17.319
<v Speaker 1>How does the code bridge that gap?

542
00:26:17.920 --> 00:26:21.200
<v Speaker 2>That's handled by Qt's core mechanism for event handling, which

543
00:26:21.240 --> 00:26:24.200
<v Speaker 2>is called signals and slots. It's a really elegant concept.

544
00:26:24.240 --> 00:26:25.519
<v Speaker 1>Signals and slots explain.

545
00:26:25.720 --> 00:26:29.240
<v Speaker 2>Okay, So a signal is something that a GI element

546
00:26:29.279 --> 00:26:33.240
<v Speaker 2>emits when an event happens. For example, a button emits

547
00:26:33.279 --> 00:26:35.440
<v Speaker 2>a clicked signal when the user clicks it.

548
00:26:35.519 --> 00:26:37.319
<v Speaker 1>Okay, button click emits a signal.

549
00:26:37.440 --> 00:26:40.079
<v Speaker 2>Right. A slot is simply a Python function that you write.

550
00:26:40.480 --> 00:26:43.519
<v Speaker 2>You then connect a specific signal to a specific slot.

551
00:26:43.960 --> 00:26:46.920
<v Speaker 2>So you connect the buttons clicked signal to your Python function,

552
00:26:47.039 --> 00:26:50.880
<v Speaker 2>say handleg button click when the button's clicked, its signal

553
00:26:50.920 --> 00:26:54.759
<v Speaker 2>was emitted, and QT automatically calls your connected slot function.

554
00:26:55.039 --> 00:26:58.480
<v Speaker 1>Ah okay, signal triggers the function the slot exactly.

555
00:26:58.519 --> 00:27:01.200
<v Speaker 2>So you design the look in U designer, which saves

556
00:27:01.200 --> 00:27:03.319
<v Speaker 2>it as a dot UI file. You then use a

557
00:27:03.359 --> 00:27:06.519
<v Speaker 2>command line tool POK four or piside two WIC to

558
00:27:06.559 --> 00:27:09.680
<v Speaker 2>automatically convert that dot ui file into Python code that

559
00:27:09.680 --> 00:27:13.759
<v Speaker 2>creates the GUI elements. Then you take that generated Python

560
00:27:13.799 --> 00:27:16.240
<v Speaker 2>code and you add your own logic. You write the

561
00:27:16.279 --> 00:27:18.559
<v Speaker 2>slot functions that actually do things with the robot when

562
00:27:18.599 --> 00:27:19.680
<v Speaker 2>signals are emitted.

563
00:27:19.640 --> 00:27:22.279
<v Speaker 1>So visual design gets converted to code. Then you add

564
00:27:22.319 --> 00:27:25.319
<v Speaker 1>the robot control logic into those slot functions percisely.

565
00:27:25.359 --> 00:27:26.640
<v Speaker 2>It's a very abavia of workflow.

566
00:27:26.799 --> 00:27:28.640
<v Speaker 1>Okay, so let's put it all together. Then for the

567
00:27:28.720 --> 00:27:33.359
<v Speaker 1>chef bot, how does this actual user friendly GUI the

568
00:27:33.440 --> 00:27:37.119
<v Speaker 1>robotw dot PI application tell a chefbot to actually go

569
00:27:37.200 --> 00:27:37.960
<v Speaker 1>to table five?

570
00:27:38.240 --> 00:27:41.920
<v Speaker 2>Right? So, the chef bok control GUI application robot dot

571
00:27:41.960 --> 00:27:45.480
<v Speaker 2>PII is designed to be simple. It likely shows some

572
00:27:45.519 --> 00:27:48.720
<v Speaker 2>buttons maybe number to zero through nine representing home base

573
00:27:48.920 --> 00:27:51.960
<v Speaker 2>and different tables defined in the hotel map. The user

574
00:27:52.000 --> 00:27:54.799
<v Speaker 2>selects a table number, say five, and clicks a go.

575
00:27:54.839 --> 00:27:56.599
<v Speaker 1>Button click five click go yep.

576
00:27:56.960 --> 00:28:01.319
<v Speaker 2>Now, internally, that GI application is acting as action lib client.

577
00:28:01.119 --> 00:28:02.920
<v Speaker 1>Action lib another ROS thing.

578
00:28:03.000 --> 00:28:06.720
<v Speaker 2>Yeah. Action lib is a standard ROS library specifically designed

579
00:28:06.720 --> 00:28:09.799
<v Speaker 2>for handling tasks that take time to execute, might need

580
00:28:09.799 --> 00:28:11.960
<v Speaker 2>to provide feedback along the way, and might need to

581
00:28:11.960 --> 00:28:13.720
<v Speaker 2>be canceled, like navigating to a goal.

582
00:28:13.839 --> 00:28:15.839
<v Speaker 1>Perfect for robot navigation exactly.

583
00:28:16.160 --> 00:28:18.359
<v Speaker 2>So the GUI the client takes the pre defined map

584
00:28:18.400 --> 00:28:21.160
<v Speaker 2>coordinates for table five it's xy position and maybe the

585
00:28:21.160 --> 00:28:23.079
<v Speaker 2>orientation of the robot should face when it gets there,

586
00:28:23.359 --> 00:28:25.680
<v Speaker 2>bundles them up into a move based goal message and

587
00:28:25.720 --> 00:28:27.440
<v Speaker 2>sends this goal to the move based note we talked

588
00:28:27.440 --> 00:28:30.359
<v Speaker 2>about earlier. In this interaction, move base is acting as

589
00:28:30.359 --> 00:28:31.480
<v Speaker 2>the action lib server.

590
00:28:31.799 --> 00:28:34.880
<v Speaker 1>Client sends goal to server, got it, and.

591
00:28:34.880 --> 00:28:38.880
<v Speaker 2>This action lube architecture handles all the communication. The server

592
00:28:39.359 --> 00:28:43.599
<v Speaker 2>move base accepts the goal, starts executing the navigation, and

593
00:28:43.640 --> 00:28:46.880
<v Speaker 2>can send feedback periodically back to the client the guy

594
00:28:47.480 --> 00:28:49.880
<v Speaker 2>like how far along the path it is, and the

595
00:28:49.920 --> 00:28:52.319
<v Speaker 2>client can also send a cancelation request if needed.

596
00:28:52.680 --> 00:28:56.200
<v Speaker 1>Ah. That's a really robust way to manage those longer tasks.

597
00:28:56.559 --> 00:28:59.440
<v Speaker 1>So if something unexpected happens, like a big spill blocking

598
00:28:59.440 --> 00:29:02.160
<v Speaker 1>the path, the staff member can just hit cancel on

599
00:29:02.200 --> 00:29:02.680
<v Speaker 1>the GUI.

600
00:29:02.880 --> 00:29:05.799
<v Speaker 2>Precisely, the GUI would have a cancel button that sends

601
00:29:05.839 --> 00:29:08.079
<v Speaker 2>a cancel request to via action lib to move base.

602
00:29:08.599 --> 00:29:10.920
<v Speaker 2>It probably also has a home button that sends a

603
00:29:10.920 --> 00:29:13.359
<v Speaker 2>goal for the robot's pre defined charging station or a

604
00:29:13.400 --> 00:29:14.079
<v Speaker 2>base position.

605
00:29:14.279 --> 00:29:16.599
<v Speaker 1>Makes sense, simple task oriented buttons.

606
00:29:16.680 --> 00:29:19.319
<v Speaker 2>Yeah, and to make it even more useful, the GOOA

607
00:29:19.359 --> 00:29:22.839
<v Speaker 2>can also provide real time status information. It might subscribe

608
00:29:22.839 --> 00:29:25.839
<v Speaker 2>to ROS topics or parameters that report the robots current

609
00:29:25.880 --> 00:29:29.960
<v Speaker 2>battery level or its overall status like navigating, idle charging,

610
00:29:30.200 --> 00:29:31.759
<v Speaker 2>and display that directly.

611
00:29:31.359 --> 00:29:33.200
<v Speaker 1>On the screen so the staff know what it's doing

612
00:29:33.200 --> 00:29:34.079
<v Speaker 1>and if it needs charging.

613
00:29:34.599 --> 00:29:38.599
<v Speaker 2>Very practical, exactly Now, that's the user facing GI. But

614
00:29:38.680 --> 00:29:42.839
<v Speaker 2>for developers or for more detailed monitoring and debugging, ROS

615
00:29:42.920 --> 00:29:46.119
<v Speaker 2>provides another powerful QT based tool called rqt.

616
00:29:46.440 --> 00:29:47.480
<v Speaker 1>Rqt. What's that?

617
00:29:47.799 --> 00:29:53.000
<v Speaker 2>Rqt is basically a framework for hosting various GUI plugins

618
00:29:53.440 --> 00:29:56.720
<v Speaker 2>within a single window. You run rqt and then you

619
00:29:56.720 --> 00:29:59.000
<v Speaker 2>can open up different tools as panels within.

620
00:29:58.839 --> 00:29:59.960
<v Speaker 1>It, Like what kind of tool?

621
00:30:00.200 --> 00:30:02.680
<v Speaker 2>Oh, lots of useful ones. Yeah, there's an arcut console

622
00:30:02.680 --> 00:30:05.559
<v Speaker 2>plug in. Unless you see all the log messages, debug info,

623
00:30:05.640 --> 00:30:08.880
<v Speaker 2>warning error coming from all the running ROS nodes, super

624
00:30:08.880 --> 00:30:10.079
<v Speaker 2>helpful for tracking down.

625
00:30:09.960 --> 00:30:11.920
<v Speaker 1>Problems central console. Nice.

626
00:30:12.119 --> 00:30:14.079
<v Speaker 2>There's an RQ topic monitor where you can see a

627
00:30:14.119 --> 00:30:17.000
<v Speaker 2>list of all active ROS topics, inspect the data being

628
00:30:17.000 --> 00:30:19.559
<v Speaker 2>published on them in real time, even see the publishing.

629
00:30:19.240 --> 00:30:21.240
<v Speaker 1>Rate, see the raw data flow yep.

630
00:30:21.720 --> 00:30:24.559
<v Speaker 2>And maybe most relevant to navigation, there's often an integrated

631
00:30:24.680 --> 00:30:27.359
<v Speaker 2>r viz plug in sometimes called the Navigation Viewer or

632
00:30:27.400 --> 00:30:30.559
<v Speaker 2>similar that lets you embed that powerful three D visualization

633
00:30:31.000 --> 00:30:33.599
<v Speaker 2>right inside your RQ window. You can see the map,

634
00:30:33.759 --> 00:30:36.799
<v Speaker 2>the robot, the sensors, the planned path, all alongside your

635
00:30:36.839 --> 00:30:38.119
<v Speaker 2>console and topic monitors.

636
00:30:38.319 --> 00:30:41.640
<v Speaker 1>Wow. So RQT is like a developer's dashboard for the robot.

637
00:30:41.960 --> 00:30:44.839
<v Speaker 2>That's a perfect way to put it. An incredibly flexible

638
00:30:44.880 --> 00:30:49.480
<v Speaker 2>and powerful dashboard for monitoring, debugging, and interacting with the

639
00:30:49.559 --> 00:30:50.680
<v Speaker 2>running ROS system.

640
00:30:50.920 --> 00:30:54.599
<v Speaker 1>Okay, so stepping back, we've taken quite a deep dive,

641
00:30:54.640 --> 00:30:58.000
<v Speaker 1>haven't we, into this journey of creating an autonomous service robot,

642
00:30:58.000 --> 00:31:01.920
<v Speaker 1>the chefbot. We went from the foundational software the Robot

643
00:31:01.960 --> 00:31:05.559
<v Speaker 1>Operating System ROS, through the nitty gritty of mechanical and

644
00:31:05.640 --> 00:31:11.119
<v Speaker 1>electrical design into sophisticated simulation. Intelligent navigation algorithms like SLAM

645
00:31:11.160 --> 00:31:15.599
<v Speaker 1>and AMCL and finally even building a user friendly graphical interface.

646
00:31:16.039 --> 00:31:19.200
<v Speaker 1>We've really seen how all these complex engineering pieces have

647
00:31:19.279 --> 00:31:22.039
<v Speaker 1>to come together to build a functional, intelligent machine.

648
00:31:22.119 --> 00:31:24.680
<v Speaker 2>Absolutely, and stepping back even further, I think this deep

649
00:31:24.720 --> 00:31:29.680
<v Speaker 2>dive really showcases the profoundly interdisciplinary nature of modern robotics, doesn't.

650
00:31:29.759 --> 00:31:32.599
<v Speaker 1>Yep, It's not just one thing, not at all.

651
00:31:32.720 --> 00:31:36.400
<v Speaker 2>It highlights that building advanced robots isn't about expertise in

652
00:31:36.480 --> 00:31:39.559
<v Speaker 2>just one area. It's about this seamless integration of so

653
00:31:39.640 --> 00:31:45.240
<v Speaker 2>many different fields mechanical engineering, electrical engineering, software engineering, control theory, AI.

654
00:31:45.880 --> 00:31:48.880
<v Speaker 2>And what's really enabling this convergence, I think, is the

655
00:31:48.920 --> 00:31:53.960
<v Speaker 2>modularity offered by frameworks like ROS, and the incredible accessibility

656
00:31:53.960 --> 00:31:57.839
<v Speaker 2>of powerful open source tools, from the OS and ROS

657
00:31:57.880 --> 00:32:01.400
<v Speaker 2>itself to CAD software, simulators and life libraries. It means

658
00:32:01.440 --> 00:32:05.319
<v Speaker 2>creating these complex systems is genuinely more achievable now than

659
00:32:05.319 --> 00:32:10.400
<v Speaker 2>ever before for students, hobbyist startups, not just huge corporations.

660
00:32:10.559 --> 00:32:13.720
<v Speaker 1>That's a great point, democratizing robot development in a way.

661
00:32:13.519 --> 00:32:14.400
<v Speaker 2>In a very real way.

662
00:32:14.480 --> 00:32:16.799
<v Speaker 1>Yes, so let's leave our listeners with something to think about.

663
00:32:16.799 --> 00:32:19.599
<v Speaker 1>A final provocative thought maybe okay.

664
00:32:19.359 --> 00:32:22.359
<v Speaker 2>Well, consider this as robots like the chef Butt become

665
00:32:22.359 --> 00:32:26.359
<v Speaker 2>more and more commonplace, moving around us in hotels, hospitals, warehouses,

666
00:32:26.359 --> 00:32:29.359
<v Speaker 2>maybe even our homes. And as they move beyond just simple,

667
00:32:29.400 --> 00:32:33.720
<v Speaker 2>repetitive tasks towards more complex interactions, what new ethical and

668
00:32:33.759 --> 00:32:35.519
<v Speaker 2>social considerations start to emerge?

669
00:32:35.960 --> 00:32:37.279
<v Speaker 1>Yeah, that's a big one.

670
00:32:37.440 --> 00:32:40.440
<v Speaker 2>How will the transparency here maybe a lack thereof, in

671
00:32:40.480 --> 00:32:44.599
<v Speaker 2>their design and decision making processes shape our trust in them?

672
00:32:44.920 --> 00:32:47.200
<v Speaker 2>And how much will the simplicity or maybe the complexity

673
00:32:47.200 --> 00:32:49.839
<v Speaker 2>of their interfaces how we interact with them influence our

674
00:32:49.880 --> 00:32:54.559
<v Speaker 2>acceptance of these increasingly intelligent autonomous systems sharing our daily lives.

675
00:32:54.559 --> 00:32:55.319
<v Speaker 2>Something to chew on