1 00:00:02,490 --> 00:00:06,249 [Music] 2 00:00:09,920 --> 00:00:14,880 Well, welcome back everybody. Uh just a 3 00:00:12,400 --> 00:00:17,920 quick reminder for all those sitting in 4 00:00:14,880 --> 00:00:21,760 the uh the mask zone, masks must be 5 00:00:17,920 --> 00:00:24,320 worn. And now it is my privilege to 6 00:00:21,760 --> 00:00:28,000 present the next presentation by David 7 00:00:24,320 --> 00:00:30,400 Kohl's on an EV trip planner for 8 00:00:28,000 --> 00:00:33,400 Australia. Big round of applause, 9 00:00:30,400 --> 00:00:33,400 please. 10 00:00:36,719 --> 00:00:41,040 Hi everyone. Um, yes, I'm David Coohl's 11 00:00:39,360 --> 00:00:44,719 talking about an EV trip planner for 12 00:00:41,040 --> 00:00:46,800 Australia and Aotero New Zealand. Uh, 13 00:00:44,719 --> 00:00:48,480 it's called Tripler 14 00:00:46,800 --> 00:00:52,719 and we'll, uh, learn a bit more about 15 00:00:48,480 --> 00:00:54,960 why and what today. Uh so here's a photo 16 00:00:52,719 --> 00:00:57,840 of me with more hair at another great 17 00:00:54,960 --> 00:01:00,719 community event uh the Melbourne Rubé uh 18 00:00:57,840 --> 00:01:03,840 bike ride earlier in the year. Um I also 19 00:01:00,719 --> 00:01:06,320 currently have the uh privilege to head 20 00:01:03,840 --> 00:01:09,360 up data platform and products group at 21 00:01:06,320 --> 00:01:11,200 my um whose mission is to help more 22 00:01:09,360 --> 00:01:13,680 Australian and New Zealand businesses 23 00:01:11,200 --> 00:01:15,760 start, survive and succeed. Uh in my 24 00:01:13,680 --> 00:01:17,360 previous role at Thoughtworks, I also 25 00:01:15,760 --> 00:01:19,040 co-authored a book, Effective Machine 26 00:01:17,360 --> 00:01:20,560 Learning Teams, uh with some of my 27 00:01:19,040 --> 00:01:22,240 colleagues. And so some of the 28 00:01:20,560 --> 00:01:24,960 approaches to building an app with data 29 00:01:22,240 --> 00:01:28,479 and AI um uh that I'll discuss today are 30 00:01:24,960 --> 00:01:30,799 also covered in EMLT. 31 00:01:28,479 --> 00:01:34,079 So our journey today we'll start with 32 00:01:30,799 --> 00:01:35,840 some context around EV adoption around 33 00:01:34,079 --> 00:01:38,479 challenges with trip planning why it 34 00:01:35,840 --> 00:01:40,640 might be an important problem to solve 35 00:01:38,479 --> 00:01:42,640 uh and then to be able to make more 36 00:01:40,640 --> 00:01:45,439 progress continue on our journey to find 37 00:01:42,640 --> 00:01:47,759 the problem more precisely then I'll 38 00:01:45,439 --> 00:01:50,399 take a long and winding road through the 39 00:01:47,759 --> 00:01:53,040 build phases uh the challenges that I 40 00:01:50,399 --> 00:01:54,960 encountered how I worked around those um 41 00:01:53,040 --> 00:01:57,119 I do hope we'll be making good time 42 00:01:54,960 --> 00:01:59,200 nonetheless so no one will need to ask 43 00:01:57,119 --> 00:02:01,759 are we there yet until we reach the 44 00:01:59,200 --> 00:02:03,360 demo. Um and from there I'll share 45 00:02:01,759 --> 00:02:06,000 briefly what I learned through the whole 46 00:02:03,360 --> 00:02:08,080 process which was a lot of fun overall. 47 00:02:06,000 --> 00:02:10,720 Uh and then think about directions this 48 00:02:08,080 --> 00:02:13,599 could go next. Um and for our journeys 49 00:02:10,720 --> 00:02:15,120 tomorrow and the next day along the way 50 00:02:13,599 --> 00:02:16,319 if you look out to the left and right of 51 00:02:15,120 --> 00:02:18,080 the vehicle you'll see a lot of 52 00:02:16,319 --> 00:02:20,560 interesting Python libraries and 53 00:02:18,080 --> 00:02:22,720 services uh that you might want to 54 00:02:20,560 --> 00:02:25,280 explore in your own projects or in your 55 00:02:22,720 --> 00:02:27,920 professional capacity. 56 00:02:25,280 --> 00:02:30,879 So some context if we think about 57 00:02:27,920 --> 00:02:34,319 sustainable transport um it's going to 58 00:02:30,879 --> 00:02:36,800 be imperative to address walking cycling 59 00:02:34,319 --> 00:02:38,400 active modes public transport to improve 60 00:02:36,800 --> 00:02:40,000 the sustainability of our transport 61 00:02:38,400 --> 00:02:42,000 system. 62 00:02:40,000 --> 00:02:44,239 But battery electric vehicles can also 63 00:02:42,000 --> 00:02:47,280 play a large role given that they 64 00:02:44,239 --> 00:02:49,440 represent uh an 80% greenhouse gas 65 00:02:47,280 --> 00:02:52,319 reduction over internal combustion 66 00:02:49,440 --> 00:02:55,120 engine or ICE vehicles. 67 00:02:52,319 --> 00:02:56,959 And when it comes to EV adoption, um 68 00:02:55,120 --> 00:02:59,680 there's a challenge. A lot of the 69 00:02:56,959 --> 00:03:01,519 driving will be done locally. Um and a 70 00:02:59,680 --> 00:03:03,920 challenge there is to provide charging 71 00:03:01,519 --> 00:03:06,000 options for EVs that are accessible 72 00:03:03,920 --> 00:03:09,599 close to home uh for people who may not 73 00:03:06,000 --> 00:03:11,760 be able to charge an EV at their home. 74 00:03:09,599 --> 00:03:13,360 But it's also very important to solve uh 75 00:03:11,760 --> 00:03:15,599 for road trips because these are a 76 00:03:13,360 --> 00:03:18,080 factor that drive adoption and purchase 77 00:03:15,599 --> 00:03:20,800 decisions around vehicles. And these are 78 00:03:18,080 --> 00:03:23,360 the most demanding uh use cases for EVs 79 00:03:20,800 --> 00:03:25,200 in Australia at the moment. So this is 80 00:03:23,360 --> 00:03:27,840 where I'll focus today in terms of the 81 00:03:25,200 --> 00:03:31,440 context. And who doesn't love a good 82 00:03:27,840 --> 00:03:33,200 road trip? Um here I am many years ago 83 00:03:31,440 --> 00:03:35,200 um about as far as it's possible to get 84 00:03:33,200 --> 00:03:37,680 from N Melbourne on a road trip in 85 00:03:35,200 --> 00:03:39,680 Australia on the land of the Bayungu 86 00:03:37,680 --> 00:03:42,319 people. Um in a vehicle that wasn't an 87 00:03:39,680 --> 00:03:43,840 EV uh but it did have pop-up headlights. 88 00:03:42,319 --> 00:03:45,840 So I think that still counts as pretty 89 00:03:43,840 --> 00:03:47,440 cool. 90 00:03:45,840 --> 00:03:49,280 And when we think about road trips and 91 00:03:47,440 --> 00:03:50,959 EVs, like the term that probably comes 92 00:03:49,280 --> 00:03:54,319 to mind for most people is range 93 00:03:50,959 --> 00:03:56,480 anxiety. Uh but the reality is that EVs 94 00:03:54,319 --> 00:04:00,560 for sale today have an average range of 95 00:03:56,480 --> 00:04:03,040 450 km. Uh and the best top out at over 96 00:04:00,560 --> 00:04:04,959 700 km. 97 00:04:03,040 --> 00:04:08,239 Along with apps that can plan the whole 98 00:04:04,959 --> 00:04:10,000 trip for you, a road trip in an EV now 99 00:04:08,239 --> 00:04:12,720 looks a lot like a road trip in an 100 00:04:10,000 --> 00:04:15,519 internal combustion engine. um that 101 00:04:12,720 --> 00:04:18,079 similar travel time, similar stop times, 102 00:04:15,519 --> 00:04:20,560 presuming you want to take some breaks 103 00:04:18,079 --> 00:04:22,479 uh and not just uh speed down the 104 00:04:20,560 --> 00:04:24,720 highway um with no regard for the land 105 00:04:22,479 --> 00:04:28,960 you're traveling over 106 00:04:24,720 --> 00:04:31,280 until you hit an inoperable charger 107 00:04:28,960 --> 00:04:34,000 uh as I did on my first road trip and 108 00:04:31,280 --> 00:04:35,759 then another inoperable charger. And so 109 00:04:34,000 --> 00:04:37,919 your range profile starts to look a 110 00:04:35,759 --> 00:04:40,639 little bit different. um you have longer 111 00:04:37,919 --> 00:04:42,479 stops at slower charges, more weight 112 00:04:40,639 --> 00:04:44,880 times, and you're charging at a less 113 00:04:42,479 --> 00:04:46,639 efficient point on the EV's battery. So, 114 00:04:44,880 --> 00:04:48,320 in general, we're not using the 115 00:04:46,639 --> 00:04:51,680 infrastructure as efficiently as we 116 00:04:48,320 --> 00:04:53,600 could. And this isn't limited to me. Uh 117 00:04:51,680 --> 00:04:56,080 the majority of drivers have found an 118 00:04:53,600 --> 00:04:58,000 issue with an operable charger on EV 119 00:04:56,080 --> 00:05:00,400 road trips. 120 00:04:58,000 --> 00:05:03,199 So, range anxiety doesn't capture the 121 00:05:00,400 --> 00:05:06,080 problem very well. In fact, it's charger 122 00:05:03,199 --> 00:05:08,960 anxiety. Um, and the conversation 123 00:05:06,080 --> 00:05:10,880 earlier this year that defined charger 124 00:05:08,960 --> 00:05:13,440 anxiety as the question of whether you 125 00:05:10,880 --> 00:05:16,240 can find somewhere reliable to recharge 126 00:05:13,440 --> 00:05:18,000 when you're away from home. And they've 127 00:05:16,240 --> 00:05:19,919 noted that Australia's public charges 128 00:05:18,000 --> 00:05:22,240 are not common enough or common enough 129 00:05:19,919 --> 00:05:23,919 or reliable enough to give drivers that 130 00:05:22,240 --> 00:05:25,520 confidence. 131 00:05:23,919 --> 00:05:27,600 I should say this doesn't mean you 132 00:05:25,520 --> 00:05:29,919 shouldn't think about EV road trips. All 133 00:05:27,600 --> 00:05:33,280 of these places from Eden to the Alps to 134 00:05:29,919 --> 00:05:34,960 Kangaroo Island are accessible in EVs. 135 00:05:33,280 --> 00:05:37,440 um with maybe just a little bit more 136 00:05:34,960 --> 00:05:39,280 planning. So what is it that we should 137 00:05:37,440 --> 00:05:41,520 do about it? 138 00:05:39,280 --> 00:05:44,639 The Australian government has advice as 139 00:05:41,520 --> 00:05:46,880 we saw earlier that some uh EV planning 140 00:05:44,639 --> 00:05:49,520 apps can plan the whole trip for you. 141 00:05:46,880 --> 00:05:51,759 But having alternate EV charging options 142 00:05:49,520 --> 00:05:53,440 is a smart move. 143 00:05:51,759 --> 00:05:55,360 Of course, we're also building out 144 00:05:53,440 --> 00:05:57,680 infrastructure in terms of the actual 145 00:05:55,360 --> 00:06:00,479 charges uh that we need to make road 146 00:05:57,680 --> 00:06:02,560 trips more feasible uh in the physical 147 00:06:00,479 --> 00:06:04,720 sense and in the digital sense as well 148 00:06:02,560 --> 00:06:06,720 where EV council and others are driving 149 00:06:04,720 --> 00:06:10,080 initiatives to report on charger 150 00:06:06,720 --> 00:06:12,880 availability uh and reliability. 151 00:06:10,080 --> 00:06:14,960 In this mix, I thought why not both? Why 152 00:06:12,880 --> 00:06:16,960 not build an app as a piece of our 153 00:06:14,960 --> 00:06:19,680 digital infrastructure that can provide 154 00:06:16,960 --> 00:06:23,039 that resilient trip planning advice to 155 00:06:19,680 --> 00:06:24,960 support adoption of EVs? And this, as I 156 00:06:23,039 --> 00:06:27,360 said, doesn't just benefit the drivers, 157 00:06:24,960 --> 00:06:30,160 but of the the users of the app, but it 158 00:06:27,360 --> 00:06:31,520 benefits all EV drivers in in that it 159 00:06:30,160 --> 00:06:34,960 enables us to use our existing 160 00:06:31,520 --> 00:06:37,680 infrastructure more efficiently. 161 00:06:34,960 --> 00:06:40,000 So that all sounds good um from a 162 00:06:37,680 --> 00:06:42,080 hindsight perspective, but moving 163 00:06:40,000 --> 00:06:44,000 forward in time as I'm constrained to 164 00:06:42,080 --> 00:06:45,600 do, I had to think a little bit more 165 00:06:44,000 --> 00:06:48,720 about what was the actual problem that 166 00:06:45,600 --> 00:06:50,080 I'd encountered on the road trip and how 167 00:06:48,720 --> 00:06:52,880 could I frame it in a way that was 168 00:06:50,080 --> 00:06:55,360 amendable to a digital solution driven 169 00:06:52,880 --> 00:06:57,280 by data and AI. 170 00:06:55,360 --> 00:06:59,280 And in that regard, I thought about 171 00:06:57,280 --> 00:07:02,240 these apps that can plan the whole trip 172 00:06:59,280 --> 00:07:03,919 for you. And in my thinking led me to 173 00:07:02,240 --> 00:07:06,080 conclude that these are based on a 174 00:07:03,919 --> 00:07:09,440 philosophy of optimal plans. There is 175 00:07:06,080 --> 00:07:13,280 one best solution for a road trip. Um 176 00:07:09,440 --> 00:07:15,360 and that small changes uh to the plan uh 177 00:07:13,280 --> 00:07:20,000 would make a small difference to the 178 00:07:15,360 --> 00:07:21,680 outcome. So I guess thinking about range 179 00:07:20,000 --> 00:07:23,680 anxiety, there are a range of factors 180 00:07:21,680 --> 00:07:25,599 that affect uh the distance that 181 00:07:23,680 --> 00:07:26,880 electric vehicle can travel on a charge. 182 00:07:25,599 --> 00:07:28,720 they're much more susceptible to 183 00:07:26,880 --> 00:07:31,280 headwinds, uh, adverse weather 184 00:07:28,720 --> 00:07:33,680 conditions and so on. And so it would be 185 00:07:31,280 --> 00:07:34,960 nice to understand whether any of those 186 00:07:33,680 --> 00:07:37,599 small changes might make a big 187 00:07:34,960 --> 00:07:39,599 difference to the plan. They also assume 188 00:07:37,599 --> 00:07:41,199 that the data is accurate, that the 189 00:07:39,599 --> 00:07:44,400 status of any charger you might choose 190 00:07:41,199 --> 00:07:46,560 to visit at planning time is the status 191 00:07:44,400 --> 00:07:48,560 uh that you will find when you arrive. 192 00:07:46,560 --> 00:07:51,440 Uh, and also assume that you can execute 193 00:07:48,560 --> 00:07:53,759 that plan pretty perfectly. Um, and I 194 00:07:51,440 --> 00:07:55,759 might say that uh in a nod to Lily 195 00:07:53,759 --> 00:07:57,599 Ryan's talk tomorrow morning, like these 196 00:07:55,759 --> 00:07:59,919 might be some falsehoods we would 197 00:07:57,599 --> 00:08:01,919 believe about reality with a perspective 198 00:07:59,919 --> 00:08:04,080 of abundance as most of the trip 199 00:08:01,919 --> 00:08:07,599 planners come from more mature markets 200 00:08:04,080 --> 00:08:10,400 uh with more dense charging networks. 201 00:08:07,599 --> 00:08:12,960 Instead, I wanted to frame up a planner 202 00:08:10,400 --> 00:08:14,479 that was about resilient plans. Um, I 203 00:08:12,960 --> 00:08:17,039 wanted resilience. I wanted multiple 204 00:08:14,479 --> 00:08:18,800 good enough solutions. If it might take 205 00:08:17,039 --> 00:08:20,400 20 minutes longer over 8 hours of 206 00:08:18,800 --> 00:08:23,680 driving, that's much better than having 207 00:08:20,400 --> 00:08:25,919 that 8 hours turn into 16 hours. That, 208 00:08:23,680 --> 00:08:28,000 as I said, the small changes can make a 209 00:08:25,919 --> 00:08:30,080 big difference. Um, if we wanted to 210 00:08:28,000 --> 00:08:32,719 understand how decisions on the day 211 00:08:30,080 --> 00:08:34,240 might impact uh where we stopped, uh, 212 00:08:32,719 --> 00:08:37,200 then I'd really like to be able to play 213 00:08:34,240 --> 00:08:39,200 around with different scenarios and see, 214 00:08:37,200 --> 00:08:41,200 uh, the impact of small changes in an 215 00:08:39,200 --> 00:08:44,399 interactive way. 216 00:08:41,200 --> 00:08:46,560 I'd also assume that data is unreliable. 217 00:08:44,399 --> 00:08:48,560 I've had both false positives and false 218 00:08:46,560 --> 00:08:51,200 negatives um when it comes to the status 219 00:08:48,560 --> 00:08:53,279 of charges um in our digital 220 00:08:51,200 --> 00:08:55,920 infrastructure arriving in reality to 221 00:08:53,279 --> 00:08:58,160 find uh that it doesn't always match up 222 00:08:55,920 --> 00:09:00,000 and of course that execution would 223 00:08:58,160 --> 00:09:04,240 always be variable from road works or 224 00:09:00,000 --> 00:09:06,800 delays um through to major environmental 225 00:09:04,240 --> 00:09:09,120 impacts in our Australian landscape such 226 00:09:06,800 --> 00:09:11,279 as floods or I mean we might remember 227 00:09:09,120 --> 00:09:14,480 the the pictures of traffic tailbacks in 228 00:09:11,279 --> 00:09:16,160 the 2020 bushfires and indeed I had 229 00:09:14,480 --> 00:09:18,160 friends in Western Australia whose EV 230 00:09:16,160 --> 00:09:21,279 planning was affected by bushfires this 231 00:09:18,160 --> 00:09:22,640 summer. So the we need to we need to 232 00:09:21,279 --> 00:09:25,200 consider all of these factors to make 233 00:09:22,640 --> 00:09:28,240 our trip planning more reliable. 234 00:09:25,200 --> 00:09:29,839 And this is what I might say again if we 235 00:09:28,240 --> 00:09:31,440 think about falsehoods about reality. 236 00:09:29,839 --> 00:09:33,920 Let's take a defensive approach to 237 00:09:31,440 --> 00:09:37,080 reality and assume um scarcity rather 238 00:09:33,920 --> 00:09:37,080 than abundance. 239 00:09:37,120 --> 00:09:42,640 So with that in mind um I set myself a 240 00:09:41,040 --> 00:09:44,560 task to build an app to solve these 241 00:09:42,640 --> 00:09:47,519 problems. um and deliver a more 242 00:09:44,560 --> 00:09:50,480 resilient experience. 243 00:09:47,519 --> 00:09:54,080 And I wanted it to be a product. And as 244 00:09:50,480 --> 00:09:56,959 we know, products need to be desirable, 245 00:09:54,080 --> 00:10:00,000 feasible, and viable. And when it comes 246 00:09:56,959 --> 00:10:02,240 to building products with data and AI, 247 00:10:00,000 --> 00:10:04,720 that tends to map that to the fact that 248 00:10:02,240 --> 00:10:08,000 there's a user need um a problem that we 249 00:10:04,720 --> 00:10:10,959 can solve. Um in that case I treated 250 00:10:08,000 --> 00:10:12,880 myself as the main user. Um which was 251 00:10:10,959 --> 00:10:15,920 very convenient for asking did it solve 252 00:10:12,880 --> 00:10:18,720 my needs. But we also need an analytical 253 00:10:15,920 --> 00:10:23,040 technique. Um and so this might be uh 254 00:10:18,720 --> 00:10:25,680 anything from uh moving averages uh to 255 00:10:23,040 --> 00:10:27,680 deep learning solutions or generative AI 256 00:10:25,680 --> 00:10:29,200 um or in this case uh operations 257 00:10:27,680 --> 00:10:32,160 research techniques. So we need a 258 00:10:29,200 --> 00:10:34,079 technique um that's been developed and 259 00:10:32,160 --> 00:10:37,920 deployed in the field before um that 260 00:10:34,079 --> 00:10:39,519 makes solving this problem feasible. 261 00:10:37,920 --> 00:10:42,480 And then to make it viable or make it 262 00:10:39,519 --> 00:10:45,680 economic, we need access to data that we 263 00:10:42,480 --> 00:10:47,680 can curate in a way that's economical uh 264 00:10:45,680 --> 00:10:50,240 for this solution uh and in a commercial 265 00:10:47,680 --> 00:10:53,839 environment which this isn't. Um that's 266 00:10:50,240 --> 00:10:56,000 also um economically competitive uh into 267 00:10:53,839 --> 00:11:00,480 the future as well and that enables us 268 00:10:56,000 --> 00:11:01,680 to solve for enough use cases. So in and 269 00:11:00,480 --> 00:11:03,600 these are sort of like some of the 270 00:11:01,680 --> 00:11:05,279 considerations that that we tackle from 271 00:11:03,600 --> 00:11:07,920 a product perspective in in effective 272 00:11:05,279 --> 00:11:10,399 machine learning teams as well. 273 00:11:07,920 --> 00:11:12,320 And so taking that lens and asking can 274 00:11:10,399 --> 00:11:14,160 we build it I also wanted to reduce the 275 00:11:12,320 --> 00:11:16,160 risk um that I would get something 276 00:11:14,160 --> 00:11:17,519 useful out of this process u you know if 277 00:11:16,160 --> 00:11:19,680 we're doing this in our professional 278 00:11:17,519 --> 00:11:21,680 capacities the risk might be hundreds of 279 00:11:19,680 --> 00:11:23,519 thousands of dollars uh that's that's at 280 00:11:21,680 --> 00:11:25,120 stake. In this case it was a few 281 00:11:23,519 --> 00:11:28,720 weekends but I still didn't want to 282 00:11:25,120 --> 00:11:30,560 waste my weekends. So I took a phased 283 00:11:28,720 --> 00:11:33,680 approach to building. The first was to 284 00:11:30,560 --> 00:11:36,560 test uh that this technique uh was 285 00:11:33,680 --> 00:11:38,240 feasible to use to to uh develop 286 00:11:36,560 --> 00:11:40,480 resilient trip plans. And so I called 287 00:11:38,240 --> 00:11:42,640 that a a proof of concept. We'll dive 288 00:11:40,480 --> 00:11:44,079 into each of these stages um over the 289 00:11:42,640 --> 00:11:47,440 next few slides. This is where the the 290 00:11:44,079 --> 00:11:52,240 road gets a bit long and winding. 291 00:11:47,440 --> 00:11:54,399 Uh the second was uh to uh uh 292 00:11:52,240 --> 00:11:56,000 demonstrate the riskiest assumption uh 293 00:11:54,399 --> 00:11:57,839 that it could be built with real world 294 00:11:56,000 --> 00:11:59,680 data. So we could solve trip planning 295 00:11:57,839 --> 00:12:01,760 for enough cases not just the simple one 296 00:11:59,680 --> 00:12:03,279 where we've tested the algorithm uh but 297 00:12:01,760 --> 00:12:06,079 can we get real world data and solve it 298 00:12:03,279 --> 00:12:07,760 for real world data. The third was the 299 00:12:06,079 --> 00:12:09,200 user experience or the user need like 300 00:12:07,760 --> 00:12:10,880 could I deliver an interactive 301 00:12:09,200 --> 00:12:12,639 experience that I'd imagined which is 302 00:12:10,880 --> 00:12:15,200 also different to existing trip planning 303 00:12:12,639 --> 00:12:17,680 apps which often require a full repl 304 00:12:15,200 --> 00:12:21,200 should you change something. With those 305 00:12:17,680 --> 00:12:23,680 elements demonstrated um I could uh then 306 00:12:21,200 --> 00:12:26,240 go on to build what I called MVP. It was 307 00:12:23,680 --> 00:12:27,920 initially for just Victorian data. Um 308 00:12:26,240 --> 00:12:30,720 again keeping it simple but it was very 309 00:12:27,920 --> 00:12:32,720 easy to extend it to Australia data. Uh, 310 00:12:30,720 --> 00:12:34,560 and now more recently, as I test drove 311 00:12:32,720 --> 00:12:37,519 this talk with an MYOB audience that 312 00:12:34,560 --> 00:12:39,839 included people from AOT, New Zealand, I 313 00:12:37,519 --> 00:12:40,880 wanted to also include New Zealand road 314 00:12:39,839 --> 00:12:42,480 trips, even though they don't 315 00:12:40,880 --> 00:12:44,320 necessarily suffer from the same problem 316 00:12:42,480 --> 00:12:45,680 of scarcity. 317 00:12:44,320 --> 00:12:47,680 From that point, there's lots of 318 00:12:45,680 --> 00:12:49,680 different directions you could go, uh, 319 00:12:47,680 --> 00:12:50,880 incremental improvements. Um, and so 320 00:12:49,680 --> 00:12:53,680 there's a few things that I've got 321 00:12:50,880 --> 00:12:55,760 bubbling away in the background. 322 00:12:53,680 --> 00:12:58,000 So starting with the really simple trip 323 00:12:55,760 --> 00:13:00,079 concept, I wanted to boil this down as 324 00:12:58,000 --> 00:13:01,440 is often a good idea with data and AI 325 00:13:00,079 --> 00:13:04,000 initiatives. Boil it down to the 326 00:13:01,440 --> 00:13:05,440 simplest thing that can demonstrate um 327 00:13:04,000 --> 00:13:07,760 what you're what you're trying to prove. 328 00:13:05,440 --> 00:13:09,360 The simplest experiment. So simplest 329 00:13:07,760 --> 00:13:11,920 model of a trip I could come up with. We 330 00:13:09,360 --> 00:13:13,600 have a destination and then we have a 331 00:13:11,920 --> 00:13:15,519 route to that destination. Again, this 332 00:13:13,600 --> 00:13:17,440 is an Australian talk. Excuse my 333 00:13:15,519 --> 00:13:18,959 pronunciation. We have a route to that 334 00:13:17,440 --> 00:13:22,079 destination that has charges on the 335 00:13:18,959 --> 00:13:24,880 route um with or maybe close to the 336 00:13:22,079 --> 00:13:26,720 route. We could simplify that into just 337 00:13:24,880 --> 00:13:28,880 an array of distances. So we have a 338 00:13:26,720 --> 00:13:30,639 distance from first from start point to 339 00:13:28,880 --> 00:13:32,800 first charger and every intermediate 340 00:13:30,639 --> 00:13:34,880 point along the way 341 00:13:32,800 --> 00:13:36,639 at each of those charges. We also have a 342 00:13:34,880 --> 00:13:38,240 value for the power of that charger. So 343 00:13:36,639 --> 00:13:40,560 that determines how quickly the vehicle 344 00:13:38,240 --> 00:13:42,399 charges and how attractive it is to stop 345 00:13:40,560 --> 00:13:44,000 at that charger. 346 00:13:42,399 --> 00:13:46,480 And then we have a vehicle that has a 347 00:13:44,000 --> 00:13:48,160 range. So this is the simplest trip I 348 00:13:46,480 --> 00:13:51,200 could come up with and this is what I 349 00:13:48,160 --> 00:13:53,519 used uh to test the feasibility of 350 00:13:51,200 --> 00:13:56,720 discrete optimization. 351 00:13:53,519 --> 00:13:58,880 And this this is the AI technique that I 352 00:13:56,720 --> 00:14:00,959 chose. Other trip planners uh use 353 00:13:58,880 --> 00:14:03,519 different techniques. Um but discreet 354 00:14:00,959 --> 00:14:06,160 optimization has four elements. The 355 00:14:03,519 --> 00:14:08,720 first is an objective. And this is what 356 00:14:06,160 --> 00:14:10,800 we want to minimize or maximize. Um and 357 00:14:08,720 --> 00:14:13,040 so in this case, the objective I chose 358 00:14:10,800 --> 00:14:15,600 was to minimize trip time. With that 359 00:14:13,040 --> 00:14:17,519 fixed trip um and assumption of fixed 360 00:14:15,600 --> 00:14:19,120 speed, there's no variation in travel 361 00:14:17,519 --> 00:14:21,360 time, but it's the stop time that 362 00:14:19,120 --> 00:14:23,519 varies. So we're trying to uh minimize 363 00:14:21,360 --> 00:14:25,199 the sum of all the stops which is which 364 00:14:23,519 --> 00:14:27,279 has a variable component and a fixed 365 00:14:25,199 --> 00:14:29,680 component. 366 00:14:27,279 --> 00:14:31,040 Then we the second element is variables 367 00:14:29,680 --> 00:14:32,560 and these are the things that are going 368 00:14:31,040 --> 00:14:35,760 to inform our plan. They're going to 369 00:14:32,560 --> 00:14:37,279 tell us what to do. Uh and the m the the 370 00:14:35,760 --> 00:14:39,600 most important one is how much do we 371 00:14:37,279 --> 00:14:42,480 fill and at which charges do we fill the 372 00:14:39,600 --> 00:14:45,680 car uh to reach our destination. 373 00:14:42,480 --> 00:14:48,160 To add to that um I also added an 374 00:14:45,680 --> 00:14:49,920 arrival charge which helps us with the 375 00:14:48,160 --> 00:14:52,720 third element which is we add 376 00:14:49,920 --> 00:14:54,320 constraints to model reality. Uh and so 377 00:14:52,720 --> 00:14:56,880 the reality of driving an electric 378 00:14:54,320 --> 00:14:59,120 vehicle is what you put in you use up as 379 00:14:56,880 --> 00:15:00,560 you drive to the next location. And so 380 00:14:59,120 --> 00:15:03,360 this is the main constraint that we 381 00:15:00,560 --> 00:15:05,680 model. Um we also can't put more than 382 00:15:03,360 --> 00:15:08,320 100% state of charge into the battery or 383 00:15:05,680 --> 00:15:10,160 drain it less than 0%. So these are our 384 00:15:08,320 --> 00:15:12,880 reality constraints that reflect what 385 00:15:10,160 --> 00:15:15,279 it's like to drive an EV. And then what 386 00:15:12,880 --> 00:15:17,279 makes discrete optimization um and 387 00:15:15,279 --> 00:15:18,959 operations research techniques like 388 00:15:17,279 --> 00:15:21,120 really flexible for modeling business 389 00:15:18,959 --> 00:15:23,839 problems is that we can add other 390 00:15:21,120 --> 00:15:25,680 constraints that um reflect the scenario 391 00:15:23,839 --> 00:15:27,440 that we're trying to achieve. And so 392 00:15:25,680 --> 00:15:30,000 this is where I could actually build in 393 00:15:27,440 --> 00:15:31,920 the resilience constraints. Um we should 394 00:15:30,000 --> 00:15:33,440 have backup options as per the federal 395 00:15:31,920 --> 00:15:36,079 government advice. I could build in 396 00:15:33,440 --> 00:15:37,760 those constraints into the trip plan. So 397 00:15:36,079 --> 00:15:39,680 we can require that when we charge at 398 00:15:37,760 --> 00:15:41,440 each charger that we have enough charge 399 00:15:39,680 --> 00:15:43,519 to get not just to the next one but the 400 00:15:41,440 --> 00:15:45,360 one after that or even end charges 401 00:15:43,519 --> 00:15:47,199 further down the line. Alternatively 402 00:15:45,360 --> 00:15:49,279 that we can return to a previous charger 403 00:15:47,199 --> 00:15:51,519 on the trip. Um we can also do things 404 00:15:49,279 --> 00:15:54,079 like uh require a minimum state of 405 00:15:51,519 --> 00:15:56,000 charge or a destination arrival state of 406 00:15:54,079 --> 00:15:58,880 charge. But most important was knowing 407 00:15:56,000 --> 00:16:01,600 that if I were to skip any charger um 408 00:15:58,880 --> 00:16:03,680 you still have options to recharge uh at 409 00:16:01,600 --> 00:16:06,240 the next one on the line. 410 00:16:03,680 --> 00:16:08,160 So then putting this all together using 411 00:16:06,240 --> 00:16:10,560 a bunch of Python libraries. Um here 412 00:16:08,160 --> 00:16:13,199 we're still in the notebooks phase uh 413 00:16:10,560 --> 00:16:15,680 but using Google's o tools and mapplot 414 00:16:13,199 --> 00:16:18,480 lib uh to visualize. Uh then we can see 415 00:16:15,680 --> 00:16:20,160 some different plans and these plans are 416 00:16:18,480 --> 00:16:22,320 um differentiated by the constraints 417 00:16:20,160 --> 00:16:24,320 that we put on them. The first one uh we 418 00:16:22,320 --> 00:16:25,519 just want to arrive with 20% of charge. 419 00:16:24,320 --> 00:16:27,440 The other one we actually want to be 420 00:16:25,519 --> 00:16:29,120 able to get to the next plus one charger 421 00:16:27,440 --> 00:16:32,000 at every point. So they have different 422 00:16:29,120 --> 00:16:33,759 plans um and different arrival times. uh 423 00:16:32,000 --> 00:16:37,680 but we can see that this is uh this is a 424 00:16:33,759 --> 00:16:39,199 feasible technique uh because if uh we 425 00:16:37,680 --> 00:16:41,279 do actually have a faulty charger we can 426 00:16:39,199 --> 00:16:43,600 simulate that too and validate that the 427 00:16:41,279 --> 00:16:45,519 plan is recoverable from that point um 428 00:16:43,600 --> 00:16:48,720 if we have the resilience constraints 429 00:16:45,519 --> 00:16:50,399 may not be the case if we don't these um 430 00:16:48,720 --> 00:16:51,600 looked a little bit like ripples I 431 00:16:50,399 --> 00:16:53,920 thought and so that's where the name 432 00:16:51,600 --> 00:16:56,800 triplet came from 433 00:16:53,920 --> 00:16:59,040 so PC is validated on to the next stage 434 00:16:56,800 --> 00:17:00,800 real world data 435 00:16:59,040 --> 00:17:02,639 it was actually pretty easy to take a 436 00:17:00,800 --> 00:17:06,079 trip in this case from Melbourne to 437 00:17:02,639 --> 00:17:10,079 Forest in the Otways, I think. Um, uh, 438 00:17:06,079 --> 00:17:11,760 using a variety of, uh, services and 439 00:17:10,079 --> 00:17:13,839 find the charges that were close to that 440 00:17:11,760 --> 00:17:16,400 route, uh, and project them to the 441 00:17:13,839 --> 00:17:19,679 nearest point on the charge on on the on 442 00:17:16,400 --> 00:17:22,720 the route. And so that used open route 443 00:17:19,679 --> 00:17:25,439 service, it used open charge map uh, and 444 00:17:22,720 --> 00:17:27,039 it used shapely to do the geometry. So 445 00:17:25,439 --> 00:17:28,559 now we've actually taken some real world 446 00:17:27,039 --> 00:17:30,640 data and we've compressed it into our 447 00:17:28,559 --> 00:17:33,200 simplified representation of the trip. 448 00:17:30,640 --> 00:17:34,720 It's looking good so far. We can we can 449 00:17:33,200 --> 00:17:37,679 build that array of distances and 450 00:17:34,720 --> 00:17:40,880 charger powers until we start to 451 00:17:37,679 --> 00:17:42,640 discover real world edge cases. 452 00:17:40,880 --> 00:17:44,880 The first of those is illustrated by 453 00:17:42,640 --> 00:17:47,760 Shell Cooh's Express Taylor's Lakes, 454 00:17:44,880 --> 00:17:50,559 which is a 350 kW charger you may want 455 00:17:47,760 --> 00:17:52,240 to stop at if you are heading uh uh west 456 00:17:50,559 --> 00:17:54,960 or north of Melbourne on the Western or 457 00:17:52,240 --> 00:17:56,080 the Calder Highways. Um we can't assume 458 00:17:54,960 --> 00:17:57,440 that it's on the route because it's 459 00:17:56,080 --> 00:17:58,880 actually a few kilometers off the route 460 00:17:57,440 --> 00:18:01,520 and that might be significant for 461 00:17:58,880 --> 00:18:02,880 planning. Um, and the next simplest 462 00:18:01,520 --> 00:18:04,640 thing I thought was, can we just assume 463 00:18:02,880 --> 00:18:06,559 that we go in a straight line as the 464 00:18:04,640 --> 00:18:08,720 crow flies to and from the projection 465 00:18:06,559 --> 00:18:10,160 point on the route? Um, that's also not 466 00:18:08,720 --> 00:18:11,840 feasible in this case because obviously 467 00:18:10,160 --> 00:18:14,000 you're going to branch off the highway 468 00:18:11,840 --> 00:18:16,240 before getting to the charger and branch 469 00:18:14,000 --> 00:18:19,440 back onto the highway or merge back on 470 00:18:16,240 --> 00:18:21,120 after the charger. So, um, we can't 471 00:18:19,440 --> 00:18:23,360 actually accommodate this edge case with 472 00:18:21,120 --> 00:18:25,280 our simple model of reality. And it's 473 00:18:23,360 --> 00:18:28,080 probably a lot more common than just 474 00:18:25,280 --> 00:18:29,440 Shell, Cooh's Express, Taylor's Lakes. 475 00:18:28,080 --> 00:18:31,120 So, could we do something a little bit 476 00:18:29,440 --> 00:18:32,480 more complicated? Should we, as as 477 00:18:31,120 --> 00:18:34,559 software engineers, I'm sure we all love 478 00:18:32,480 --> 00:18:36,640 the idea of branching and merging. Um, 479 00:18:34,559 --> 00:18:39,039 could we update that simple trip model 480 00:18:36,640 --> 00:18:41,440 to include branches uh and and merging 481 00:18:39,039 --> 00:18:43,520 back on? Uh, this makes it slower 482 00:18:41,440 --> 00:18:46,320 because it requires an additional API 483 00:18:43,520 --> 00:18:50,559 call to the routing endpoint from open 484 00:18:46,320 --> 00:18:53,200 route service. Um, but it also we also 485 00:18:50,559 --> 00:18:55,120 find the issue of AOL foody Altona North 486 00:18:53,200 --> 00:18:56,720 and Hobson's Bay Civic Center that 487 00:18:55,120 --> 00:18:58,080 they're both on the same branch. which 488 00:18:56,720 --> 00:19:00,640 of those charges are we going to stop 489 00:18:58,080 --> 00:19:03,360 at? How do we model that as part of our 490 00:19:00,640 --> 00:19:04,960 um simple model of a trip? We could add 491 00:19:03,360 --> 00:19:06,960 extra constraints. We could say we only 492 00:19:04,960 --> 00:19:09,039 stop at one charger on that branch. Um 493 00:19:06,960 --> 00:19:11,200 and in fact, I went down that uh dead 494 00:19:09,039 --> 00:19:13,600 end a little way before deciding that 495 00:19:11,200 --> 00:19:17,200 we're getting too complicated. We've got 496 00:19:13,600 --> 00:19:19,120 rules and um processing in there just 497 00:19:17,200 --> 00:19:21,440 for the sake of a model of reality that 498 00:19:19,120 --> 00:19:23,039 doesn't actually fit. So it was time to 499 00:19:21,440 --> 00:19:25,840 take so and and so at this point the 500 00:19:23,039 --> 00:19:29,120 rat's unresolved but it was time to take 501 00:19:25,840 --> 00:19:31,280 the red pill and use another service 502 00:19:29,120 --> 00:19:32,960 from open route service which is matrix 503 00:19:31,280 --> 00:19:37,200 which gives you pair-wise distances 504 00:19:32,960 --> 00:19:39,840 between uh uh different points uh uh 505 00:19:37,200 --> 00:19:42,320 distances and travel times as well. So 506 00:19:39,840 --> 00:19:45,280 this has the data that we need to feed 507 00:19:42,320 --> 00:19:47,919 into our optimization algorithm uh and 508 00:19:45,280 --> 00:19:50,240 it's a single API call very fast. it did 509 00:19:47,919 --> 00:19:52,080 require the base constraints that model 510 00:19:50,240 --> 00:19:54,400 reality to be updated. So instead of 511 00:19:52,080 --> 00:19:56,400 just going from one charger to the next, 512 00:19:54,400 --> 00:19:59,120 we actually choose which legs between 513 00:19:56,400 --> 00:20:01,360 which cells in that matrix, we hop 514 00:19:59,120 --> 00:20:03,600 across to get from the start to the 515 00:20:01,360 --> 00:20:06,000 origin. So we've updated our model of 516 00:20:03,600 --> 00:20:08,080 reality, but it's a much better fit. Um, 517 00:20:06,000 --> 00:20:10,640 and we can actually plan trips using 518 00:20:08,080 --> 00:20:13,840 real world data in this case. So rat's 519 00:20:10,640 --> 00:20:17,120 validated. It's on to prototyping. Uh, 520 00:20:13,840 --> 00:20:19,760 here I went back to a single trip. Um, 521 00:20:17,120 --> 00:20:21,919 and because uh from Mildura to Malakuda 522 00:20:19,760 --> 00:20:23,840 via Melbourne, I just wanted to validate 523 00:20:21,919 --> 00:20:26,240 the interactivity. And so here you can 524 00:20:23,840 --> 00:20:28,080 see uh we can slide the range up and 525 00:20:26,240 --> 00:20:29,919 down and we can toggle on and off 526 00:20:28,080 --> 00:20:32,080 resilience constraints and we can see 527 00:20:29,919 --> 00:20:34,640 the trip plan updating in real time. It 528 00:20:32,080 --> 00:20:39,360 wasn't fancy at this point. Um I used 529 00:20:34,640 --> 00:20:42,080 Streamllet um which is a library and uh 530 00:20:39,360 --> 00:20:45,360 related services um that allow you to 531 00:20:42,080 --> 00:20:46,799 write pure Python apps uh which then can 532 00:20:45,360 --> 00:20:49,600 be delivered into the browser in an 533 00:20:46,799 --> 00:20:51,679 interactive way. So this was great. The 534 00:20:49,600 --> 00:20:54,559 prototype worked really well. Um I could 535 00:20:51,679 --> 00:20:56,640 yeah a long road trip over a,000k with 536 00:20:54,559 --> 00:20:58,640 over 50 charges along the way. Uh the 537 00:20:56,640 --> 00:21:00,000 interactive planning worked well. I 538 00:20:58,640 --> 00:21:02,960 could distribute it to people via 539 00:21:00,000 --> 00:21:04,240 Streamlit Community Cloud. Um, and but I 540 00:21:02,960 --> 00:21:06,559 also found some other things that to 541 00:21:04,240 --> 00:21:08,640 help with the interactivity. So, uh, 542 00:21:06,559 --> 00:21:10,720 pre-selecting which charges you're most 543 00:21:08,640 --> 00:21:12,880 likely to stop at along the route as you 544 00:21:10,720 --> 00:21:15,120 go through Melbourne, for instance, 545 00:21:12,880 --> 00:21:16,400 there are something much more than half 546 00:21:15,120 --> 00:21:17,919 the charges on the route are in the 547 00:21:16,400 --> 00:21:19,120 Melbourne metropolitan area, but you're 548 00:21:17,919 --> 00:21:21,679 probably only going to stop at one or 549 00:21:19,120 --> 00:21:23,200 two of those max as you go through. So, 550 00:21:21,679 --> 00:21:25,520 there was another discrete optimization 551 00:21:23,200 --> 00:21:27,280 problem to pre-select charges. Uh, 552 00:21:25,520 --> 00:21:29,360 variable precision, so we don't always 553 00:21:27,280 --> 00:21:32,640 need one percentage point of charge. it 554 00:21:29,360 --> 00:21:34,159 degrades to 10 percentage points um to 555 00:21:32,640 --> 00:21:36,480 when the charge when the number of 556 00:21:34,159 --> 00:21:38,080 charges gets bigger. 557 00:21:36,480 --> 00:21:39,520 Uh and yeah, and I could improve the 558 00:21:38,080 --> 00:21:40,960 visualization over those ripples. I 559 00:21:39,520 --> 00:21:43,120 thought they were kind of cute at first 560 00:21:40,960 --> 00:21:44,799 uh but a bar chart worked far better. So 561 00:21:43,120 --> 00:21:47,120 that's still online at 562 00:21:44,799 --> 00:21:50,799 triplerite.stream.app, 563 00:21:47,120 --> 00:21:53,600 but from there UX validated. 564 00:21:50,799 --> 00:21:55,120 The issue in real world testing would be 565 00:21:53,600 --> 00:21:59,039 whether anyone actually wanted to drive 566 00:21:55,120 --> 00:22:01,919 this route. We needed um 567 00:21:59,039 --> 00:22:04,080 Thank you. We needed uh some uh we 568 00:22:01,919 --> 00:22:06,640 needed some additional 569 00:22:04,080 --> 00:22:11,919 uh additional testing. 570 00:22:06,640 --> 00:22:14,000 So that takes us to the uh MVP. 571 00:22:11,919 --> 00:22:18,840 Uh and has anyone got a favorite road 572 00:22:14,000 --> 00:22:18,840 trip we should test out? Shout out 573 00:22:19,600 --> 00:22:23,840 to 574 00:22:21,280 --> 00:22:26,840 Warnable. Melbourne to Warnable. 575 00:22:23,840 --> 00:22:26,840 Awesome. 576 00:22:27,600 --> 00:22:33,280 Oops. There we go. So, Melbourne to 577 00:22:30,480 --> 00:22:34,799 Wool. 578 00:22:33,280 --> 00:22:36,960 I'm not even I'm not spelling correctly, 579 00:22:34,799 --> 00:22:39,960 but at least you'll get to see an error 580 00:22:36,960 --> 00:22:39,960 message. 581 00:22:40,880 --> 00:22:44,559 And so, there's the trip from Melbourne 582 00:22:42,400 --> 00:22:47,120 to Warnable. 583 00:22:44,559 --> 00:22:49,440 Uh, and we can see charge of 584 00:22:47,120 --> 00:22:53,679 pre-selection auto magic in here, which 585 00:22:49,440 --> 00:22:55,280 is hidden by default. um uh with the 586 00:22:53,679 --> 00:22:57,840 range that we've got, we don't actually 587 00:22:55,280 --> 00:23:00,720 need to charge. Uh but if we decreased 588 00:22:57,840 --> 00:23:03,280 the range significantly or added more 589 00:23:00,720 --> 00:23:05,919 resilience constraints, here we we can't 590 00:23:03,280 --> 00:23:07,840 actually cross the gap between charges, 591 00:23:05,919 --> 00:23:10,080 but we can see different trip plans come 592 00:23:07,840 --> 00:23:12,640 up. And something that I also wanted to 593 00:23:10,080 --> 00:23:15,679 do every time I travel is learn more 594 00:23:12,640 --> 00:23:18,080 about uh the indigenous uh owners of the 595 00:23:15,679 --> 00:23:22,159 lands that we visit. And so using a 596 00:23:18,080 --> 00:23:25,360 service called uh native lands digital 597 00:23:22,159 --> 00:23:27,120 um we're able to um find each of the 598 00:23:25,360 --> 00:23:29,600 indigenous lands that we visit along our 599 00:23:27,120 --> 00:23:31,200 trip. So then we can also launch 600 00:23:29,600 --> 00:23:33,679 directions. It's not a direction app, 601 00:23:31,200 --> 00:23:36,559 it's a planning app. Uh and so launch 602 00:23:33,679 --> 00:23:38,880 directions to complete our trip. So I 603 00:23:36,559 --> 00:23:41,440 think I've got to keep moving uh to 604 00:23:38,880 --> 00:23:42,960 ensure we do make good time. Those are 605 00:23:41,440 --> 00:23:45,600 the things we saw in the demo. You can 606 00:23:42,960 --> 00:23:49,039 visit it there. Um, I may actually test 607 00:23:45,600 --> 00:23:51,120 whether my API rate limits um whether my 608 00:23:49,039 --> 00:23:52,640 app is resilient to API rate limits at 609 00:23:51,120 --> 00:23:54,799 Open Root Service if everyone tests it 610 00:23:52,640 --> 00:23:56,880 today. What I learned was, as you saw 611 00:23:54,799 --> 00:23:58,240 the error message, I had a cactus. I 612 00:23:56,880 --> 00:24:00,320 could have fun with the Australian 613 00:23:58,240 --> 00:24:01,679 nature of the app. Um, cactus is 614 00:24:00,320 --> 00:24:04,559 obviously Australian's thing for 615 00:24:01,679 --> 00:24:06,480 something that's broken. Um, uh, on the 616 00:24:04,559 --> 00:24:08,320 alternative things that worked well, I 617 00:24:06,480 --> 00:24:10,559 could say she's Apple's mate. But the 618 00:24:08,320 --> 00:24:11,919 the default flow of the app was that 619 00:24:10,559 --> 00:24:14,080 things should just work and it would 620 00:24:11,919 --> 00:24:16,480 only call out when things didn't work. 621 00:24:14,080 --> 00:24:18,480 So it's been useful to plan trips. Other 622 00:24:16,480 --> 00:24:20,480 people have used it. Uh but still not 623 00:24:18,480 --> 00:24:23,200 many people use it. And there's a huge 624 00:24:20,480 --> 00:24:25,200 range of uh Python libraries and 625 00:24:23,200 --> 00:24:27,919 services that I was able to learn about. 626 00:24:25,200 --> 00:24:29,760 No vibe coding required. Just really um 627 00:24:27,919 --> 00:24:31,600 productive programming programming 628 00:24:29,760 --> 00:24:33,600 environment with well well-designed 629 00:24:31,600 --> 00:24:35,679 abstractions. 630 00:24:33,600 --> 00:24:38,240 What's next? Uh so I talked about 631 00:24:35,679 --> 00:24:39,679 incremental improvements. Uh so we don't 632 00:24:38,240 --> 00:24:41,760 actually have to limit ourselves to 633 00:24:39,679 --> 00:24:44,080 100%. Uh we can extend the model of 634 00:24:41,760 --> 00:24:45,600 reality again because any wall socket 635 00:24:44,080 --> 00:24:47,600 could be used to trickle charge an 636 00:24:45,600 --> 00:24:49,520 electric vehicle. So there's an option 637 00:24:47,600 --> 00:24:51,360 to trickle charge in plans where there's 638 00:24:49,520 --> 00:24:53,520 a big gap between charges. 639 00:24:51,360 --> 00:24:55,279 Alternatively, um we don't have to take 640 00:24:53,520 --> 00:24:57,200 the direct route from navigation. We 641 00:24:55,279 --> 00:24:59,520 could hop between charges uh that have 642 00:24:57,200 --> 00:25:01,039 enough range for us to reach if we're if 643 00:24:59,520 --> 00:25:03,279 we're traveling across more remote 644 00:25:01,039 --> 00:25:04,880 areas. Um, and we might also want to 645 00:25:03,279 --> 00:25:08,240 consider more detailed factors like 646 00:25:04,880 --> 00:25:10,000 elevation. As you go up, an EV uses uh 647 00:25:08,240 --> 00:25:11,679 turns energy into gravitational 648 00:25:10,000 --> 00:25:14,400 potential energy, but you get it back on 649 00:25:11,679 --> 00:25:16,880 the down as well. 650 00:25:14,400 --> 00:25:18,640 So, the other thing we could ask about 651 00:25:16,880 --> 00:25:20,480 what's so bad about stopping when we're 652 00:25:18,640 --> 00:25:23,120 charging. Uh, so we can actually make 653 00:25:20,480 --> 00:25:24,960 the recharge experience better um using 654 00:25:23,120 --> 00:25:27,440 a similar kind of approach. And so, this 655 00:25:24,960 --> 00:25:30,640 is Tripler's little sibling stopler. 656 00:25:27,440 --> 00:25:32,080 when we um stop somewhere in rural town, 657 00:25:30,640 --> 00:25:35,039 we like to get a pie and check out the 658 00:25:32,080 --> 00:25:38,480 op shop. Um so what's the what's the 659 00:25:35,039 --> 00:25:39,440 reachable area? Uh 660 00:25:38,480 --> 00:25:40,400 sorry, 661 00:25:39,440 --> 00:25:42,559 big things. 662 00:25:40,400 --> 00:25:44,480 Big things. Yes, big things as well. 663 00:25:42,559 --> 00:25:46,720 Great idea. So I would hope that big 664 00:25:44,480 --> 00:25:49,760 things would come up in the interesting 665 00:25:46,720 --> 00:25:52,000 selection of tricker flicker photos from 666 00:25:49,760 --> 00:25:53,679 the location. Um, but I have to do a 667 00:25:52,000 --> 00:25:55,440 little bit of tuning of Flickr's 668 00:25:53,679 --> 00:25:57,200 interestingness parameter, but it should 669 00:25:55,440 --> 00:26:00,400 definitely prioritize for big things as 670 00:25:57,200 --> 00:26:02,159 well as pies and ops. So, yeah. So, you 671 00:26:00,400 --> 00:26:03,840 know, we can think about the the the 672 00:26:02,159 --> 00:26:06,640 trip experience being quite different in 673 00:26:03,840 --> 00:26:08,480 an EV and making that feature rather 674 00:26:06,640 --> 00:26:10,799 than a bug. 675 00:26:08,480 --> 00:26:12,880 So, where might I go from here? Um, it's 676 00:26:10,799 --> 00:26:14,240 obviously a hobby project. Um, there's a 677 00:26:12,880 --> 00:26:16,640 bunch of things I could do to improve 678 00:26:14,240 --> 00:26:18,720 the usability and to solve technical 679 00:26:16,640 --> 00:26:20,960 limitations. uh like the charger 680 00:26:18,720 --> 00:26:23,120 selection is also required so that we 681 00:26:20,960 --> 00:26:26,720 have less than 50 points going to open 682 00:26:23,120 --> 00:26:29,279 route services matrix solver um there 683 00:26:26,720 --> 00:26:31,120 may be ways to explore a scaled uh 684 00:26:29,279 --> 00:26:32,880 deployment model of this do I release it 685 00:26:31,120 --> 00:26:36,240 open source there's a bunch of other 686 00:26:32,880 --> 00:26:38,400 apps that exist in the EV ecosystem um 687 00:26:36,240 --> 00:26:40,159 the services that I used uh other trip 688 00:26:38,400 --> 00:26:42,159 planners the charge point operators 689 00:26:40,159 --> 00:26:43,760 themselves and the vehicle manufacturers 690 00:26:42,159 --> 00:26:45,840 might all have an interest in having 691 00:26:43,760 --> 00:26:48,799 some kind of this this some part of this 692 00:26:45,840 --> 00:26:51,039 experience or it could indeed be a new 693 00:26:48,799 --> 00:26:53,360 standalone planner. 694 00:26:51,039 --> 00:26:56,240 I think it also fits into the one final 695 00:26:53,360 --> 00:26:58,720 thing I wanted to say was it fits into 696 00:26:56,240 --> 00:27:01,679 uh like a bigger picture of how do we 697 00:26:58,720 --> 00:27:04,320 most efficiently and most um 698 00:27:01,679 --> 00:27:08,559 responsively develop electrification 699 00:27:04,320 --> 00:27:10,480 infrastructure. Um and so we have I the 700 00:27:08,559 --> 00:27:13,919 way I see it we have three quite related 701 00:27:10,480 --> 00:27:17,039 problems. Um uh route planning is what I 702 00:27:13,919 --> 00:27:18,960 tackled with tripler but prior to that 703 00:27:17,039 --> 00:27:20,720 um I'd actually tackled the network 704 00:27:18,960 --> 00:27:24,240 planning problem. So where should we put 705 00:27:20,720 --> 00:27:26,880 charges to enable more trips um uh at at 706 00:27:24,240 --> 00:27:28,559 the lowest cost with scarce resources? 707 00:27:26,880 --> 00:27:31,200 Where do we deploy them to to get the 708 00:27:28,559 --> 00:27:33,120 best benefit? On another corner of the 709 00:27:31,200 --> 00:27:35,440 triangle we also have fleet planning 710 00:27:33,120 --> 00:27:37,120 like what type of EVs should we have um 711 00:27:35,440 --> 00:27:39,760 either as individuals or as 712 00:27:37,120 --> 00:27:41,200 organizations that manage logistics. So 713 00:27:39,760 --> 00:27:42,799 yeah, maybe watch this space, maybe 714 00:27:41,200 --> 00:27:44,720 there's something coming there. And of 715 00:27:42,799 --> 00:27:47,279 course in between we have integrated 716 00:27:44,720 --> 00:27:48,559 planning as well. So networks for roots, 717 00:27:47,279 --> 00:27:50,720 roots for fleets and fleets for 718 00:27:48,559 --> 00:27:54,000 networks. Um and all of these techniques 719 00:27:50,720 --> 00:27:57,039 are amenable to um operations research, 720 00:27:54,000 --> 00:28:00,399 discrete optimization, digital twins. Um 721 00:27:57,039 --> 00:28:03,840 provided we have access to good data 722 00:28:00,399 --> 00:28:06,720 or our network resilience improved 723 00:28:03,840 --> 00:28:08,640 sufficiently that charger anxiety is no 724 00:28:06,720 --> 00:28:10,320 longer a thing. Um, and we don't need 725 00:28:08,640 --> 00:28:13,679 trip planning. Uh, we just get in the 726 00:28:10,320 --> 00:28:15,200 car and drive. So, thank you all. Um, 727 00:28:13,679 --> 00:28:17,039 time to stop and recharge. And yeah, you 728 00:28:15,200 --> 00:28:19,120 can find more details on my blog, 729 00:28:17,039 --> 00:28:21,679 safetydave.net. Um, if you're interested 730 00:28:19,120 --> 00:28:25,080 in all the gory details. 731 00:28:21,679 --> 00:28:25,080 Thank you, David. 732 00:28:28,320 --> 00:28:33,279 I'm afraid there's no time for 733 00:28:29,919 --> 00:28:33,760 questions, but you do get the coveted 734 00:28:33,279 --> 00:28:35,120 award. 735 00:28:33,760 --> 00:28:37,600 Thank you, Mike. 736 00:28:35,120 --> 00:28:41,799 It's wonderful. Yeah, you can find me 737 00:28:37,600 --> 00:28:41,799 afterwards for questions if you like.