1
00:00:00,830 --> 00:00:01,820
Hello, welcome back.

2
00:00:02,450 --> 00:00:11,420
So in this lesson, we going to reexamine our autonomous vehicle case study again and show the various

3
00:00:11,420 --> 00:00:14,330
ways in which we could achieve what we want to achieve.

4
00:00:15,050 --> 00:00:20,580
OK, so this diagram over here shows how we would do this in a busy wait system.

5
00:00:21,260 --> 00:00:29,090
This is the the most popular we we ride to a firmware where we just have our function and then we do

6
00:00:29,090 --> 00:00:33,110
an if condition and then we wait for that if condition to be met.

7
00:00:33,110 --> 00:00:36,560
Once it is met, we move on to the next state.

8
00:00:37,100 --> 00:00:41,330
Over here, what we have is check the light assets or status.

9
00:00:43,230 --> 00:00:52,560
So check if it is ready, then read the data and then go on to check the the what you call it, the

10
00:00:52,560 --> 00:00:56,370
radar sensor or if that is ready with the data.

11
00:00:57,190 --> 00:01:03,850
And then come on to check the camera status, if it is ready, gets the data and then we come back to

12
00:01:03,850 --> 00:01:08,590
the top, check Leida, check radar, check camera and then to the top.

13
00:01:09,010 --> 00:01:16,840
OK, so what would happiness in an autonomous vehicle where things need to meet deadlines and everything

14
00:01:16,840 --> 00:01:21,040
has to be precisely derived at a precise time?

15
00:01:21,520 --> 00:01:22,480
It could be that.

16
00:01:23,570 --> 00:01:27,230
When you check in the camera, Senso studies.

17
00:01:28,280 --> 00:01:35,330
And then computing the parameters, because you've just you've now got in all the states of the three

18
00:01:35,330 --> 00:01:41,700
sensors and you are taking actions such as turn left, it could be that by the time you reach here and

19
00:01:41,720 --> 00:01:47,030
you are ready to take left based on the information you collected from here, here and here, the data

20
00:01:47,030 --> 00:01:48,560
here may have changed.

21
00:01:50,000 --> 00:01:54,410
So you would end up in a car situation?

22
00:01:54,440 --> 00:01:59,780
It could be fatal, it could be dangerous to rely on a system such as this because you first check,

23
00:01:59,780 --> 00:02:05,600
you check you and check you and then you think, OK, you know, the perfect state of all sensors.

24
00:02:05,810 --> 00:02:13,010
So now you are ready to increase their speed or turn left back because it's arranged this way.

25
00:02:13,700 --> 00:02:17,750
And you check this some time ago, the states may have changed.

26
00:02:18,350 --> 00:02:20,860
So this could lead to a problem.

27
00:02:21,350 --> 00:02:22,790
This is the busy wait system.

28
00:02:23,000 --> 00:02:27,890
We wait over here until it is ready and then we check this, wait until it's ready.

29
00:02:28,100 --> 00:02:30,500
And then after that, OK, we know the light.

30
00:02:30,500 --> 00:02:31,040
Our status.

31
00:02:31,040 --> 00:02:32,600
Is this the radar status?

32
00:02:32,600 --> 00:02:33,860
Is this the camera status?

33
00:02:33,860 --> 00:02:35,960
Is this therefore increased the speed?

34
00:02:36,560 --> 00:02:37,070
OK.

35
00:02:37,920 --> 00:02:44,010
So this is simple, this the standard way that people often write code sequential code like this.

36
00:02:44,190 --> 00:02:50,940
Now, let's see another way that this could be arranged using what is known as the the interrupt service

37
00:02:50,940 --> 00:02:51,420
routine.

38
00:02:51,450 --> 00:02:52,290
So over here.

39
00:02:53,530 --> 00:02:59,140
We have just our main function, all of this, you can think of all of this in a while, while one was

40
00:02:59,140 --> 00:03:00,250
single main function.

41
00:03:00,900 --> 00:03:04,380
OK, now let's see this other arrangement over here.

42
00:03:04,390 --> 00:03:05,620
We have our main function.

43
00:03:05,650 --> 00:03:13,050
We're saying take action only in our main function, but read into the light us.

44
00:03:13,060 --> 00:03:14,950
That is the read us.

45
00:03:14,950 --> 00:03:15,850
That is in the camera.

46
00:03:15,940 --> 00:03:19,570
That is we're doing it in a separate threat known as background threats.

47
00:03:20,740 --> 00:03:23,800
And our main function, we only see saying take action.

48
00:03:24,780 --> 00:03:26,110
So what does this mean?

49
00:03:26,160 --> 00:03:33,300
What is this background threat one with this background threat can be can be designed is by using timers.

50
00:03:34,020 --> 00:03:40,490
Our microcontrollers allow us to use our time is to create periodic interrupts.

51
00:03:41,160 --> 00:03:43,440
And what this means is that periodically.

52
00:03:44,480 --> 00:03:51,020
The process is going to be interrupted and then a particular block of code will be executed.

53
00:03:52,610 --> 00:04:01,280
And we use our time is to decide to decide to disappear out of frequency, so this I saw here starts

54
00:04:01,310 --> 00:04:03,350
for interrupt service routine.

55
00:04:04,570 --> 00:04:12,940
So we can see, OK, time are one, we want you to execute this block of code every.

56
00:04:14,050 --> 00:04:15,220
Twenty milliseconds.

57
00:04:16,670 --> 00:04:18,590
And then we can see Temotu.

58
00:04:19,710 --> 00:04:22,380
We want you to execute this other block of code.

59
00:04:23,600 --> 00:04:29,240
Every 20 milliseconds or every 30 milliseconds, because we are using different hardware timers, we

60
00:04:29,240 --> 00:04:35,840
can decide on the frequency at which each interruption, OK, and we can see timer three should should

61
00:04:35,840 --> 00:04:37,970
give us, I guess, our three.

62
00:04:37,970 --> 00:04:41,330
We want you to execute this block of code known as cameras.

63
00:04:41,360 --> 00:04:48,350
That is when you to execute this every twenty five milliseconds so we can initialize hardware timers

64
00:04:48,650 --> 00:04:52,180
to create these interrupts periodically.

65
00:04:52,460 --> 00:04:57,530
And then when it occurs periodically, there is a particular function known as the interest service

66
00:04:57,530 --> 00:05:02,480
routine for each time we place our block of code there and then it'll be executed.

67
00:05:03,500 --> 00:05:10,070
So what is going to happen is if we say this should occur every 20 milliseconds, what would happen

68
00:05:10,070 --> 00:05:14,240
is every 20 milliseconds, the the Processo.

69
00:05:15,480 --> 00:05:19,740
Is going to pass the main function and then execute the content in this block of code.

70
00:05:20,720 --> 00:05:27,680
And once that is done, it's going to resume executing the main function, if this wants period, Protarchus,

71
00:05:27,830 --> 00:05:31,450
is going to pass and then execute once it's done.

72
00:05:31,760 --> 00:05:36,970
So the main function essentially ends up with a very low priority.

73
00:05:37,340 --> 00:05:37,720
Right.

74
00:05:38,090 --> 00:05:44,570
So what would happen is when we have these multiple interrupt service routines, we are allowed to assign

75
00:05:44,570 --> 00:05:52,700
them priority levels as well, such that we know we have let's see if we have this once period to be

76
00:05:52,940 --> 00:05:56,950
every 20 milliseconds and this one's period to be every 40 milliseconds.

77
00:05:57,140 --> 00:06:03,680
We know they're going to collide eventually to collide, because when this one executes its first period

78
00:06:03,890 --> 00:06:11,030
and the next period of this is plus another 20 milliseconds, which will occur at a forty millisecond

79
00:06:11,300 --> 00:06:17,340
timestamp, that will be the first execution of this one whose period is every 40 milliseconds.

80
00:06:17,690 --> 00:06:24,470
So in a situation where to interrupt service routines end up with the same period, how do we decide

81
00:06:24,470 --> 00:06:25,670
who gets to execute?

82
00:06:26,270 --> 00:06:33,050
Because of this, we are allowed to assign them priorities so we can assign this a higher priority than

83
00:06:33,050 --> 00:06:38,370
this one, such that in such a situation, those with a higher priority execute.

84
00:06:39,050 --> 00:06:39,480
Right.

85
00:06:39,680 --> 00:06:41,030
So these ones here.

86
00:06:41,970 --> 00:06:45,700
We have the foreground threat and the Bhagwat threat, right?

87
00:06:45,750 --> 00:06:51,240
Another thing I should point out is there is also a debate based debate on which should be considered

88
00:06:51,240 --> 00:06:53,880
a foreground threat and a background threat.

89
00:06:54,720 --> 00:06:57,180
OK, an H over here.

90
00:06:59,040 --> 00:07:01,290
There's a debate on which should be considered.

91
00:07:02,450 --> 00:07:07,100
The foreground thread in the background thread, what are the main function should be the foreground,

92
00:07:07,490 --> 00:07:13,400
foreground thread of the background thread I have just chosen, it's makes sense to me that the ones

93
00:07:13,400 --> 00:07:18,870
in the back to interrupt service routines in the background, while whilst the main function, of course,

94
00:07:18,950 --> 00:07:21,000
would deal with it all the time, is in the foreground.

95
00:07:21,260 --> 00:07:25,790
So if you see this with this written us background in this as foreground, don't get alarmed.

96
00:07:26,390 --> 00:07:32,810
OK, so this method here, we have our main function and we have had where time is generating interest

97
00:07:32,810 --> 00:07:33,340
for us.

98
00:07:33,500 --> 00:07:41,180
So it is the second way we can you know, we can deal with our autonomous vehicle case study.

99
00:07:42,140 --> 00:07:42,600
Right.

100
00:07:43,100 --> 00:07:48,710
So we know that Dobi coalitions, there will be, of course, the main function will be will be staffed

101
00:07:48,800 --> 00:07:49,940
from process processing time.

102
00:07:50,090 --> 00:07:56,780
Of course, every time the main function wants to do something, then one of them would have the period.

103
00:07:57,710 --> 00:08:02,900
So the incorrupt would OK and the main function would have to stop and then let them deal with it.

104
00:08:03,140 --> 00:08:06,690
So this is a compromise is better than the first one is a compromise.

105
00:08:07,160 --> 00:08:09,320
Now, let's see our ARTUS.

106
00:08:09,450 --> 00:08:11,270
So let's see what we've done.

107
00:08:11,270 --> 00:08:13,100
We showed a busy wait system.

108
00:08:14,570 --> 00:08:17,210
We should interrupt service routine system.

109
00:08:17,400 --> 00:08:23,210
Now we are showing the ATA system, the realtime operating system to in the realtime operating system

110
00:08:23,210 --> 00:08:23,870
solution.

111
00:08:24,920 --> 00:08:33,770
We have each of the blocks in their own threads, we have each of them in their own thread or tasks

112
00:08:33,980 --> 00:08:40,610
such that we take an action only in task one and then in task to we only dealing with a lighter sense

113
00:08:40,610 --> 00:08:46,660
or task three, only dealing with a radar sensor task for only dealing with a camera essential.

114
00:08:47,150 --> 00:08:51,850
So all of them are occurring based on the scheduling algorithm.

115
00:08:51,860 --> 00:08:55,330
All of them are occurring independent of each other.

116
00:08:55,700 --> 00:08:58,040
If we want, we can also pass the data.

117
00:08:58,220 --> 00:09:00,760
Obviously we would need to pass the data between them.

118
00:09:00,980 --> 00:09:07,910
They are tools that allows us to pass the data between these threats or these tasks in an efficient

119
00:09:08,090 --> 00:09:09,350
and safe way.

120
00:09:10,350 --> 00:09:15,600
So this is the the the Real-Time operating system solution, and with this, if we are using a simple

121
00:09:15,600 --> 00:09:16,860
Round-Robin solution.

122
00:09:17,950 --> 00:09:24,820
Then we could we could find a good enough time, slice them, make them OK.

123
00:09:25,030 --> 00:09:27,790
Almost as if they were parallel.

124
00:09:29,210 --> 00:09:36,480
Right, such that if we see each of them should execute four, five missed this executes five Emmis,

125
00:09:36,500 --> 00:09:42,680
it saves its execution states and then restores the execution date of this five most saves and then

126
00:09:42,680 --> 00:09:43,720
restores restores.

127
00:09:43,730 --> 00:09:47,010
So by the time we come here is going to be almost as if nothing happened.

128
00:09:47,870 --> 00:09:49,610
So this is the artist's evolution.

129
00:09:49,790 --> 00:09:53,350
It's not perfectly parallel.

130
00:09:53,510 --> 00:09:54,140
That's the word.

131
00:09:54,140 --> 00:09:54,970
Sorry about that.

132
00:09:55,610 --> 00:10:00,900
But this is the solution compared to the other two solutions.

133
00:10:01,250 --> 00:10:06,530
So now you understand the artosis not perfectly parallel execution.

134
00:10:06,920 --> 00:10:13,700
It is just rapidly quick context saving and context restoration.

135
00:10:13,700 --> 00:10:17,530
We save the context of one thread where we start the context of another thread.

136
00:10:17,930 --> 00:10:24,380
So because it's this fast, we just see it as if it is parallel.

137
00:10:24,800 --> 00:10:27,470
I'm having problems with this pronunciation to the.

138
00:10:28,350 --> 00:10:34,740
And when we go to practically execute our realtime operating system, we would be counting countless

139
00:10:34,740 --> 00:10:42,060
variables and you would see that to almost have the same volume as if they've executed execute in parallel.

140
00:10:42,370 --> 00:10:50,130
OK, so this or the risk for this lesson in the next lesson, we shall we shall give an overview of

141
00:10:50,340 --> 00:10:51,120
of threats.

142
00:10:51,150 --> 00:10:57,210
We shall give a very short overview of the components that Ethelred need to have and then we shall move

143
00:10:57,210 --> 00:10:57,780
on from that.

144
00:10:57,790 --> 00:11:01,610
If you have any questions, please leave them in the questions and answers.

145
00:11:01,860 --> 00:11:04,110
If you have any feedback, just let me know.

146
00:11:04,470 --> 00:11:05,140
I'll see you later.

147
00:11:05,160 --> 00:11:05,820
Have a nice day.