Never trust an atom, they make up everything. ?
Never trust an atom, they make up everything. ?
Regularization is a fundamental concept in Machine Learning (#ML) and is generally used with activation functions. It is the key technique that help with overfitting.
Overfitting is when an algorithm or model ‘fits’ the training data too well – it seems to good to be true. Essentially overfitting is when a model being trained, learns the noise in the data instead of ignoring it. If we allow overfitting, then the network only uses (or is more heavily influenced) by a subset of the input (the larger peaks), and doesn’t factor in all the input.
The worry there being that outside of the training data, it might not work as well for ‘real world’ data. For example the model represented by the green line in the image below (credit: Wikipedia), follows the sample data too closely and seems too good. On the other hand, the model represented by the black line, which is better.
Regularization helps with overfitting (artificially) penalizing the weights in the neural network. These weights are represented as peaks, and this reduces the peaks in the data. This ensure that the higher weights (peaks) don’t overshadow the rest of the data, and hence getting it to overfit. This diffusion of the weight vectors is sometimes also called weight decay.
Although there are a few regularization techniques for preventing overfitting (outlined below), these days in Deep Learning, L1 and L2 regression techniques are more favored over the others.
Between L1 and L2 regularization, many say that L2 is preferred, but I think it depends on the problem statement. Say in a network, if a weight has a large magnitude, L2 regularization shrink the weight more than L1 and will better. Conversely, if the weight is small then L1 shrinks the weight more than L2 – and is better as it tends to concentrate the weight in fewer but more important connections in the network.
In closing, the key aspect to appreciate – the small weights (peaks) in a regularized network essentially means that as our input changes randomly (i.e. noise), it doesn’t have a huge impact to the network and its output. So this makes it difficult for the network to learn the noise and respond to that. Conversely, in an unregularized networks, that has higher weights (peaks), small random changes to those weights can have a larger impact to the behavior of the network and the information it carries.
Some time ago, I talked about my Tesla Model 3 “keyfob” which essentially uses a Amazon IoT button to call some of Tesla API’s and “talk” to the car. This for me, is cool as it allows my daughter to unlock, and lock the car at home. And of course it is a bit geeky, and allowing one to play with more things. 🙂
Since publishing this, I was surprised how many of you ping me asking on details on how they can did this for themselves. Given the level of interest, I thought I will document this and outline the steps here. I do have to warn you, that this would be a little long – it entails getting a IoT Button configured, and then the code deployed. Before you get started, and if you aren’t techy, I would recommend to go through the post completely, so you get a sense of what is needed.
At a high level, below are the steps that you need to go through to get this working. And this might seem cumbersome and a lot but it is not that difficult. Also if you prefer you can follow the official AWS documentation online here.
Of course you need to get a IoT Button; I got the AWS IoT Button (2nd Generation) which is what I would recommend.
Open AWS home page and login with your amazon.com credentials. Of course if you don’t have a Amazon.com account, then you want to click in sign up on the top right corner, to get this started.
After I login, I see something similar to the screenshot below. Your exact view might differ a little.
I recommend to change the region to one closer to you. To do this, click on the region on the top right corner and choose a region that is physically closest to you. In the longer run this would help with latency issues between you clicking the button and the car responding. For example in my case, Oregon makes most sense.
Once you have a AWS account setup, login to the AWS IoT console or on the AWS page in the previous step, scroll down to IoT Core as shown in the screenshot below.
Next step would be to register your IoT button – which of course means you physically have the button with you. The best way to register is to follow the instructions here. I don’t see much sense in trying to replicate that here.
Once you have registered a button (it doesn’t matter what you call it) – it will show up similar to the screenshot below. I only have one device listed.
Next, we need to create and activate a certificate for the device. Without this, the button won’t work. The certificate (which is a X.509 certificate) protects the communication between the button and AWS.
For most people, the one-click certification creation that AWS has, is probably the way to go. To get to this, on the AWS IoT console, click on Secure and then choose Certificates on the left if not already selected as shown below. I already have a certificate that you can see in the screenshot below.
If you need to create a certificate, click on the Create button on the top right corner, and choose one of the options shown in the image below. In most cases you would want to use the One-click certificate option.
NOTE: Once you create a Certificate, you get three files (these are the keys) that you need to download and keep safe. The certificate itself can be downloaded anytime, but the private and the public keys CANNOT be retrieved again after you close this page. It is IMPORTANT that you download these and save them in a safe place.
Once you have these downloaded then click on Activate on the bottom. And you should see a different certificate number than what you are seeing here. And don’t worry I have long deleted what you are seeing on this screen. 🙂
You can also see these in the developer guide on AWS documentation.
Next step is go back to the AWS IoT Console page and click on Policies under Security. This is used to create a IoT policy that you will need to attach to the certificate. Once you have a policy created, then it will look something like the screenshot below.
To create a policy, click on Create (or you might be prompted automatically if you don’t have one). On the create screen, in the Name you can enter anything that you prefer. I would suggest naming this something that you can remember and differentiate if you will have more than one button. In my case I named it as the same thing as my device.
After this is created this you will see the policies listed as shown below. You can see the new one we just created with “WhateverNameYouWillRecognize“. You can also see these and more details on the developer documentation – Create a AWS IoT Policy.
Next step is to attach the policy that is just created to the certificate created earlier. To do that, click on Secure and Certificates on the left, and then click on the three dots (called ellipses) on the top right of the Certificate you created earlier. From the new menu that you get, choose “Attach Policy” as shown below.
From the resulting menu, select the policy that you had created earlier and select Attach. Using a sensible name that you would recognize would be helpful. You can also see these details on the developer documentation.
Next step is to attach the certificate to the IoT device (or thing). A device must have a certificate, a private key and a root CA certificate to authenticate with AWS. Amazon also recommends to attach a device certificate to the device – this probably isn’t helpful right now, but might be in the future if you start playing with this more.
To do this, select the certificate under Security on the left, and same as the previous step, by click on the three dots on the top right corner, select “Attach thing”.
And from the next screen select the IoT button that you registered earlier, and select “Attach”.
To validate that everything is setup correctly – the certificate needs to be associated with a policy, and a thing (the IoT button in our case). So on the Certificates menu on the left, select your certificate by clicking on it (not the three dots this time – but rather the name). You will see a new screen that shows the details of the certificate as shown below.
And on the new menu on the left, if you click on Policies you should see the policy you created, and the Things should have the IoT button you created earlier.
Once all of this is done the next step is to configure the device. You can see more detailed steps on this on the developer guide here.
At last we are starting to get the interesting part – a lot of what we were doing until now, was getting the button configured and ready.
Now that you have a IoT button configured and registered, the next step is to deploy some code. For this you need to setup a Lambda function using the AWS Lambda Console.
When you login, click on Create Function. On the Create function screen, choose the Blueprints option as shown below. You can see some of these in the developer documentation here.
On the Blueprints search box (which says Filters by tags), type in “button” (without quotes) and press enter. You should see an option called “iot-button-email” as shown below, select that and click configure on the bottom right corner.
On the next screen that says “Basic information”, enter the details as shown below. The names should be meaningful for you to remember. Roles can be reused across other areas, for now you can use a simple name something like “unlockCar” or “unlockCarSomeName” if you have more than one vehicle. The policy template should already be populated and you shouldn’t need to do anything else.
For the 2nd half – AWS IoT Trigger, select the IoT type as “IoT Button” and enter your device serial number as outlined in the screenshot below.
It won’t hurt to download these certificate and keys in addition to the ones created separately and save them in different folders. And for the Lambda function code, it doesn’t matter on the template code as we will be deleting it all. At this point that will be read-only and you won’t be able to modify anything – as shown in the screen shot below.
And finally scrolling down more, you will see the environment variables. Here is where you need to specify your Tesla credentials to it to be able to use create the token and call the Tesla API. For that you need the following two variables: TESLA_EMAIL and TESLA_PASS. These case sensitive so you need to enter them as is. And then finally click on Create function.
Once you create a function, you will see something like the screen below. In my case the function is called “unlockSquirty” which is what you are seeing. This is divided in to two parts – when on the Configuration page. The top part is the designer that visually shows you what inputs are the triggers that execute the function, and then what it outputs to on the right hand side. And below the designer is the editor where one can edit the code inline or upload a zip file with the code.
In the function code section, on the first drop down in the left (Code entry type) select upload a .zip file.
And on the next screen upload the function package that you can download from here.
And scroll down and in the Basic settings, change the timeout to 1 minute. We run thus asynchronously and adding a little buffer would be better. You can leave all the other settings at their default. If your network might be iffy you can make this 2 mins.
Once you have entered all of this, click on Save on the top right corner and then publish new version. Finally once it is published you will be able to see the code show up as shown in the screenshot below.
Again, a single click will unlock the car, a double-click would lock it, and a long press (holding it for 2-3 seconds) would open the charge port door.
And here is the code:
var tjs = require('teslajs');
var username = process.env.TESLA_EMAIL;
var password = process.env.TESLA_PASS;
exports.handler = (event, context, callback) =>
var token = JSON.stringify(result.authToken);
var options =
console.log("Vehicle " + vehicle.vin + " is: " + vehicle.state);
var options =
if(event.clickType == "SINGLE")
console.log("Single click, attempting to UNLOCK");
console.log("Doors are now UNLOCKED");
else if(event.clickType == "DOUBLE")
console.log("Double click, attempting to LOCK");
console.log("Doors are now LOCKED");
else if(event.clickType == "LONG")
console.log("Long click, attempting to CHARGE PORT");
console.log("Charge port is now OPEN");
Tonight, I was a large download by the car, and saw that it was a .ssq file. The file name is consistent with the firmware naming convention, but I am not sure on what it is. The file itself is 5.11 GB, and in my case its name starts with “NA”. I am guessing, this might be the maps its updating.
Below are a couple of screenshots showing this. I am trying to make sense of the binary file, but not making much headway.
Curious, anyone has any ideas?
Update: I found out what .ssq files are; read up more here.
Neural Networks, today, help in a great set of tasks, that until very recently wasn’t possible at all – be it from computer vision, to medical diagnosis, to speech translation and forms a key cornerstone to a lot of ‘magic’ that Machine Learning and AI offers today.
I did blog about Neural Network types (and MarI/O) sometime back; I surely cannot take credit for creating these three cheat sheets but they are awesome and hope you get to use and enjoy them too.
My command prompt history is quite long, and a lot over time is not essentially garbage. I was looking at a way to clean it out. Most of the solutions online I found were not correct – I don’t know if things changed over time, but the latest version of Windows I am on (Windows 10 Pro 1803), it did not work.
So, here are two ways that you can do this. One is using the registry editor (RegEdit), and the other is running a simple script that you can either copy and paste from below or you can download and run it.
If you are going to be using RegEdit, and living dangerously then Press WinKey + R and type “regedit” (without quotes) and press enter to get the Registry Editor going as shown below.
And on the new Windows navigate to the following key: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU and delete that. You can right click on the key name and choose delete.
It is important to double check because if you miss it, or delete something else, there is no recovery. (Why do you think I was saying, you like to live dangerously). See the screenshot below.
NOTE: It is always recommended to backup the registry before doing this, so at least you could restore it back to the state. To backup select File -> Export.
A better way, and less dangerous would be to run the following script in a elevated command prompt (i.e. a Admin command prompt) which will do the same thing, but more safer. You can just copy the command from below and paste it. Or alternatively you can download this simple script and run it locally (also from a elevated command prompt).
reg delete "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU" /f
I don’t know how to get to debug / dev mode on a Tesla, but did come across this old post, on how someone was in a test drive, which did have this mode.
Now this is quite old, so a lot has changed, but am impressed that a lot of the components and foundational architecture was setup. I am particularly impressed how each cell in the battery pack and report its state. The BMS that you see is the Battery Management System – that firmware is separate from the car’s firmware.
You can see more photos and geek out online here.
And of course if you really want to geek out, then check out su-tesla, where Hemera has really has gone to party. I don’t know how to do this, and I have a lot of respect for Hemera to do this – she has a lot of guts. Also not sure what the wife would think about it and kick me out. Maybe. 🙂
And finally, from a more (relatively) recent update, the AutoPilot has a tremendous amount of data. As reported here, and you can see on the video below, the volume of data is massive, and quite interesting. For example, what decides there are 4 virtual lanes? The car below is a US car (the country code 840 is a ISO 3166 code).
Beware of programmers that carry screwdrivers