Forem: Surya Dantuluri

Building a scalable, highly available, and portable web server

Surya Dantuluri — Mon, 07 Oct 2019 17:56:37 +0000

After over a year of development, SD2, my web server is done.

When I initially set out to build a website, I wanted it ranked #1 when you searched my name on Google. I remember seeing other students like Kevin Frans(MIT/OpenAI) and Gautam Mittal(Berkeley/Stripe) having their websites highly ranked on Google and took inspiration from that to do the same. I also wanted to automate a lot of mundane tasks to ensure that this web server is highly scalable in the event I get a lot of traffic, highly available to prevent any user from having downtime while accessing the many elements to my server, and portable if I need to move over to a different cloud service provider.

Switching between AWS, GCP, and DigitalOcean

SD2 is the new web server I've been building for nearly a year now. After going on DigitalOcean then to Google Cloud for a bit, then AWS for a longer bit, then finally back to GCP, it's been a long ride. DigitalOcean was too expensive and my Google Cloud discounts expired (which I renewed, so I went back).

I initially started with DigitalOcean since they had relatively low prices and a hackathon I've attended incentivized it using prizes, so I decided to give it a try. After nearly a year, I decided DigitalOcean was a little bit like training wheels and I needed more functionality among other things, so I moved over to GCP.

From GCP, I was able to configure a nice setup with my site, but the problem was in reverse proxying my Blog (runs on Ghost) and reverse proxying other static sites. For this hassle, I temporarily weaved in and out of using simple Github Pages (although in hindsight, this was mostly my fault)

After running some RL models and subsequently burning through hundreds of dollars an hour, I ran quickly out of credits and was nearly forced to move over to AWS.

After finding out about AWS' free tier I decided to give EC2 a chance. Using it for a couple days got me comfortable using it, although configuring the launch wizards opposed to VPC on GCP took some to get used to, but I was able to run basic NGINX instances off of it.

However, AWS has this somewhat weird structure for CPU usage available here: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-credits-baseline-concepts.html#cpu-credits. Essentially, after several days of running my entire stack, I was beginning to be throttled all the way down to nearly 5% CPU utilization, slowing all my sites to a standstill. It got so bad that any and all my sites were unusable.

This prompted me to get some more credits from GCP and continue on there for the finite future.

Note: When developing this server, I used AWS.

What I needed from a web server

Before going further, I had to outline what I wanted to do:

A NGINX server to reverse proxy websites I build
High availability of my Blog (running on Ghost)
Self hosted Analytics Engine
Self hosted storage service (both uploading and downloading)
Self hosted email server (SMTP)
Self hosted URL shortener

And all of this had to be built using Docker, to make it easily shippable to other servers in the case the one I'm using goes down or something else happens (from experience on moving from DO to GCP to AWS to GCP and in between spinning down and up servers from instance to instance)

While I was still developing this server, I was still on AWS. Here's what I did:

I initially created a AWS AMI with Docker baked in (because I couldn't find one readily available) and started playing with my newfound Docker knowledge (from using it in the workplace).

With this in place I started spinning up EC2 instances left and right, trying out Ghost images, setting up ECS, finding out what Fargate is, and trying to see how I can scale.

After several weeks I realized I didn't need ECS or Fargate or any of the "fancy" features AWS was offering, since I wasn't building a SaaS startup or anything, just a simple personal web server that fit my needs.

So I continued playing around with Docker and EC2.

But as I was setting up all these Docker containers, I was realizing there had to be some way of composing all of them.

That's when I found docker compose. It made it a lot easier to just spin up new containers if I needed to. And scalability? It had it, without even disrupting existing containers.

Running a simple

docker-compose up --scale ghost=3 -d

Seamlessly scales up.

But how are we going to:

Manage all these ports?
Reverse proxy everything without much hassle?

Initially I heard that Nginx Proxy by Jason Wilder (Azure) was a great option.

After doing a little digging, it definitely sounded like a nice option. And using it for a little while made me realize it was manually generating configuration files and it was hard to easily configure, especially with Docker compose.

That's when I found Traefik, a cloud native edge router.

This is how they describe it from their README:

Traefik (pronounced traffic) is a modern HTTP reverse proxy and load balancer that makes deploying microservices easy. Traefik integrates with your existing infrastructure components (Docker, Swarm mode, Kubernetes, Marathon, Consul, Etcd, Rancher, Amazon ECS, ...) and configures itself automatically and dynamically. Pointing Traefik at your orchestrator should be the only configuration step you need.

So it was a batteries included reverse proxy engine which fully supported Docker-compose, fitting exactly my needs.

Simply: It took whatever port that was being publically exposed by the container and proxying it to whatever domain/subdomain needed.

This was crucial to me, since either managing a bunch of services running on the machine itself or a bunch of docker containers spun up from a Docker Compose file was going to be a mess to handle.

The better part is that given that I'm running some databases and other sensitive info, I could use an internal subnet to prevent that from being publicly facing and Traefik inadvertently helped with that.

With Traefik and the configuration of my Docker Compose file, I was able to essentially use every Docker image like an app. Easily being able to download, update, and uninstall without disturbance to any other services.

I could install Netdata(gives statistics on how your site is doing) within minutes; even setup my own Overleaf/Sharelatex directly on my website, just with some small configuration changes with Traefik.

Traditionally I'd have to spend hours downloading, installing, and maintaining Redis, Mongo, MySQL, etc. databases on top of downloading, installing, and mainting the services themselves. If anything went wrong, I'd have to completely restart. On top of that, the databases would be public facing (last time FB had a MongoDB instance public facing, millions of username/passwords were leaked) and that's the last thing I want.

On the other-hand, with Traefik and Docker Compose, I'm easily able to run everything and anything I want within minutes with Docker and route every service to its intended destination with Traefik.

As I've said previously; given Docker's "portability" of shipping containers around, I could even set everything up on my old desktop and have it work seamlessly (with using Cloudflare Argo).

Traefik even has a GUI! Here's how monitor.suryad.com looks like:

So what am I running?

With the power of Traefik and Docker Compose I'm running the following:

This Blog (subscribe if you haven't yet! sdan.xyz/subscribe)
suryad.com, sd2.suryad.com (static sites)
ShareLatex (I run my own Latex server for fun)
Mongo, Redis, Postgres, MySQL (although I'm probably going to drop MySQL for SQlite soon)
URL Shortener (sdan.xyz)
A commenting server (for you to comment on my posts; don't like Disqus having you to login everytime)
Netdata to check if everything is running or if swap space RAM is being used or to see if CPU is being over-utilized

So have I accomplished what I sought out for?

Somewhat.

I'm still working on an analytics engine after both Fathom and Ackee (open sourced analytics engines) gave me mixed results, but gave me the direction that I should self host (I don't trust that Google Analytics is going to give me the correct results since so many people have adblock on).

In regards to a "Google Drive" for myself, it's at: sdan.cc (where all the images you're seeing are from) which I host from my Fastmail account (allows me to upload/download/serve files with ease)

In regards to email: I need a reliable email service. Although I trust myself, I trust Fastmail to do it for me with better features. I've come to love what features they provide and so far just stuck with them.

At the end of the day I'm more than excited and happy with what I've built with the knowledge I've accrued from my internship at Renovo and from other various sources.

So what can I as a reader use from your "plethora" of services?

Not much unfortunately. This whole setup was more of a feat to show how powerful, simple, and easy self-hosting can be. Although one day I'd like people to use my URL shortener or Latex server, at this point my low spec'd GCP instance probably isn't good enough for multiple people to join on.

However,

You can build everything listed here on your own.

Simply install https://github.com/dantuluri/setup (which coats you server with some butter to start cooking up the main part of the operation)

Then simply download https://github.com/dantuluri/sd2 and run docker-compose on this file and start traefik with this line:

sudo docker run -d -v /var/run/docker.sock:/var/run/docker.sock -v $PWD/traefik.toml:/traefik.toml -p 80:80  -l traefik.frontend.rule=Host:subdomain.yourdomain.com -l traefik.port=8080 --network proxy --name traefik traefik:1.7.12-alpine --docker

Conclusion

So suppose you have some free time and hop onto any one of my websites/services. How would you get there?

Here's a somewhat simple and packed diagram explaining that:

Here's also some fun diagrams generated by various scripts:

DAgger Explained

Surya Dantuluri — Mon, 01 Apr 2019 07:00:00 +0000

Note: LaTex does not render properly on dev.to. You can find the LaTex rich version of this post here: https://blog.suryad.com/dagger/

Note: All material from this article is adapted from Sergey Levine's CS294-112 2017/2018 class

Dataset Aggregation, more commonly referred to as DAgger is a relatively simple iterative algorithm that trains a deep deterministic policy solely dependent on the distribution of states of the original and generated dataset. [1]

Here's a simple example:

Let's say you're teaching someone to drive. In this instance, you are a human (hopefully) and your friend's name is Dave. Despite being a fellow human, Dave's incapability to drive renders him to be like a policy (\pi_{\theta}(a_t \vert o_t)). Where (\pi_{\theta}) is the parameterized policy and (a_t) is the sampled action space from (o_t), which is the observation space.

But Dave is smart, beforehand he trained for this exercise by watching some YouTube videos, which we can represent as (p_{data}(o_t)). Like the rest of us, Dave isn't perfect and he makes mistakes. In this scenario, however, Dave's mistakes can quickly add up and result in him (and consequently you) to end up in a ditch or crashing into someone else. We can represent Dave's distribution for observation as (p_{\pi_{\theta}}(o_t)). As Dave drives, his mistakes build up, eventually leading him to diverge from (p_{data}(o_t)), which is the data that Dave trained on (those YouTube videos).

From John Schulman at Berkeley Deep RL 2015. Link: http://rll.berkeley.edu/deeprlcourse-fa15/docs/2015.10.5.dagger.pdf [3]

Think of Dave as the red trajectory in the picture. You know that the blue trajectory is correct in your mind and overtime you try to tell Dave to drive like the blue policy.

So how can we help poor Dave? After Dave watches those YouTube videos initially to get some sense of how to drive, he records himself driving. After each episode of driving, we aggregate this data and add in what actions Dave should've done to get a new dataset (\mathcal{D_{\pi}}) which consists of not only ({o_1,\ldots,o_M}) but also the actions corresponding to those observations (since we filled in what actions he should've taken for those observations): ({o_1,a_1,\ldots,a_M,o_M})

Dave's trajectory is red while you know that the black trajectory is optimal. Dave creates a dataset from the red trajectory and you are tasked with filling in the actions for each observation Dave did. From CS294-112 8/28/17 by Sergey Levine. [4]

Now we aggregate the old dataset, (\mathcal{D}) with this "new" dataset, (\mathcal{D_{\pi}}) like so: (\mathcal{D} \Leftarrow \mathcal{D} \cup\mathcal{D_{\pi}})

Surely, you can aggregate the data in whatever way you want, but this is a simple way of doing it.

In that example, we essentially implemented DAgger on Dave! Overtime Dave's distributional mismatch will be nonexistent, meaning Dave will be a driving legend.

Let's translate the example above to an algorithm:

Rendered by Surya Dantuluri, adapted by Ross, Gordon, Bagnell, Levine [1], [4]

Let's go through this algorithm step by step:

We initialize the dataset (\mathcal{D}) with initial dataset.
Initialize some policy (\pi_{\theta}(a_t \vert o_t))
For N steps (Which is determined by how many times you want to iterate this algorithm. The more times you iterate this algorithm, the better (p_{\pi_{\theta}}(o_t)) will be like (p_{data}(o_t))
Now inside the for-loop, we sample a trajectory from policy (\pi_{\theta}(a_t \vert o_t))
We get the distribution of observations from (p_{\pi_{\theta}}(o_t)) which is based on expert dataset, (p_{data}(o_t))
Once we have the distribution of observations, we add in what actions the policy (\pi_{\theta}(a_t \vert o_t)) should've taken
We then aggregate the new dataset we have just created with the initial dataset
Train classifier (\pi_{\theta}(a_t \vert o_t)) on this big dataset (\mathcal{D})
Repeat this for loop as long as you want, since (\pi_{\theta}(a_t \vert o_t)) gets better overtime and asymptotically its (p_{\pi_{\theta}}(o_t)) will be like (p_{data}(o_t))

Implementation

So how can we implement DAgger in practice?

Well the algorithm is simple enough, so we'll just need to translate the psuedo-code into Python and for now we won't go over setup/etc.

This implementation does not require a human. Since DAgger is a Behavior Cloning (BC) algorithm, instead of cloning the behavior of a human, we can just run DAgger against an expert to eventually clone the performance of this expert.

This implementation is based off https://github.com/jj-zhu/jadagger. [5]

with tf.train.MonitoredSession() as sess:
sess.run(tf.global_variables_initializer())
# record return and std for plotting
save_mean = []
save_std = []
save_train_size = []
# loop for dagger alg

Here we have the initialization for the Tensorflow session we're starting. Note that I changed the normal tf.Session() to tf.train.MonitoredSession() because it comes with some benefits. Other than that we initialize some arrays we are going to use in the algorithm.

# loop for dagger alg
for i_dagger in xrange(50):
print 'DAgger iteration ', i_dagger
# train a policy by fitting the MLP
batch_size = 25
for step in range(10000):
batch_i = np.random.randint(0, obs_data.shape[0], size=batch_size)
train_step.run(feed_dict={x: obs_data[batch_i,], yhot: act_data[batch_i,]})
if (step % 1000 == 0):
print 'opmization step ', step
print 'obj value is ', loss_l2.eval(feed_dict={x:obs_data, yhot:act_data})
print 'Optimization Finished!'

Here we are setting our DAgger algorithm to iterate 50 times. Within the for-loop we start by training our policy (\pi_{\theta}(a_t \vert o_t)) to fit the MLP, which stands for Multilayer Perceptron. It's essentially a standard feedforward NN with an input, hidden, and output layer (very simple).

To put this step in other words, given this is the 1st iteration, Dave from the earlier example has just gotten some idea on how to drive by watching those YouTube videos. In later iterations, Dave, (\pi_{\theta}(a_t \vert o_t)) is essentially training on the entire dataset (\mathcal{D}). This is out-of-order, but this is step 6 in our algorithm. It doesn't matter though since all parts of the algorithm are incorporated in this implementation, in order.

use trained MLP to perform

        max_steps = env.spec.timestep_limit

        returns = []
        observations = []
        actions = []
        for i in range(num_rollouts):
            print('iter', i)
            obs = env.reset()
            done = False
            totalr = 0.
            steps = 0
            while not done:
                action = yhat.eval(feed_dict={x:obs[None, :]})
                observations.append(obs)
                actions.append(action)
                obs, r, done, _ = env.step(action)
                totalr += r
                steps += 1   
                if render:
                    env.render()
                if steps % 100 == 0: print("%i/%i" % (steps, max_steps))
                if steps &gt;= max_steps:
                    break
            returns.append(totalr)
        print('mean return', np.mean(returns))
        print('std of return', np.std(returns))

Here, we are rolling out our policy Dave (in other words (\pi_{\theta}(a_t \vert o_t))). What does policy rollout mean?

https://www.uihere.com/free-cliparts/search?q=Roly-poly&page=2

Does it have something to do with a roly poly rolling out? As you could guess, it doesn't. Rather, it's essentially our policy exploring trajectories, eventually building up a distribution of (p_{data}(o_t)). This is steps 2 and 3 in our algorithm.

# expert labeling
act_new = []
for i_label in xrange(len(observations)):
act_new.append(policy_fn(observations[i_label][None, :]))
# record training size
train_size = obs_data.shape[0]
# data aggregation
obs_data = np.concatenate((obs_data, np.array(observations)), axis=0)
act_data = np.concatenate((act_data, np.squeeze(np.array(act_new))), axis=0)
# record mean return & std
save_mean = np.append(save_mean, np.mean(returns))
save_std = np.append(save_std, np.std(returns))
save_train_size = np.append(save_train_size, train_size)

dagger_results = {'means': save_mean, 'stds': save_std, 'train_size': save_train_size,
                  'expert_mean':save_expert_mean, 'expert_std':save_expert_std}
print 'DAgger iterations finished!'

We have the last process necessary for DAgger here. Here we expertly label the distribution of (p_{data}(o_t)) with our expert policy. This is steps 4 and 5 in our algorithm.

Wasn't that fun? Hopefully you get a better idea of what DAgger is. You can find the code for this by Jia-Jie Zhu on his repo. If you have any problems, feel free to contact me at [email protected]

References

[1] A Reduction of Imitation Learning and Structured Prediction to No-Regret Online Learning, Ross, Gordon & Bagnell (2010). DAGGER algorithm [link]

[2] Deep DAgger Imitation Learning for Indoor Scene Navigation [PDF]

[3] DAGGER and Friends [PDF]

Schulman, J., 2015.

[4] CS294-112 Fa18 8/24/18 [link]

Levine, S., 2018.

[5] jadagger [link]

Zhu, J.J., 2016.

Building a Self Driving Car using Machine Learning

Surya Dantuluri — Wed, 15 Aug 2018 07:00:00 +0000

Introduction

This is a story about how a high schooler beat Georgia Tech's robotics team single handedly, not a technical deep dive. For that, here is the paper corresponding with this project https://arxiv.org/abs/1807.08233

None of this would have happened if ECX had made high-quality products.

Seriously.

It was the summer of 2013 where my mom, sisters and I went to visit a family friend in Fremont, CA. I just got a RC Car off Amazon with money I made at a small Closet Sale (my version of a garage sale, since I lived in an apartment complex). I decided to bring my brand-new RC Car to this family friend’s house since they had a road in front that led to a dead end (which meant practically no traffic). I drove it around the street for a good 15 minutes before handing along to my sisters and the other family friends. They all played around with it for a while and it was fun to watch this small car drive around at speeds close to 15 mph. Then my mom called all of us to come in for a snack. While everyone else left, I decided to play around with my car for a couple more minutes before going in. After driving it down the street and back at around 10–15 mph, the car didn’t come to a complete stop when I rotated the control knob to brake. Instead, the car came to a slow stop, almost like it was on neutral mode, which I didn’t think was possible. I was right. The motor was moving, but the car wasn’t anymore.

I spent the next hour relentlessly debugging the issue. I tried resetting the receiver, resetting the controller, even trying slowly turning the throttle knob to see if it would move, even slightly. The servo worked for sure, but the car wasn’t moving, even if the motor was running.

It took me weeks to finally get in contact with a Horizon Hobby representative to help me debug the issue. I found out 30 minutes later that something foreign to me at the time; the pinion gear, was broken.

That’s what started a 5-year career in building and modifying RC cars during the summertime starting in my 5th-grade summer.

ETG is Rolling Around

Robotics in High School

From ending a successful middle school career, I was pumped to continue my development at Monta Vista High School. I was President of the Science Olympiads club and the National Junior Honor Society at my middle school, two of the biggest organizations there. For various reasons, I moved near Monta Vista, one of the most reputable schools in Cupertino/Sunnyvale. I heard about how hard it was, but never did I think it was as hard as it was during Freshman and Sophomore year for me and many others. Anyway, as a pumped middle schooler, I joined the Robotics team and several other clubs right away, hoping for officer positions. Unfortunately, I didn’t get any and surprisingly, not even during Sophomore year (I’ll explain in another blog post). I also joined Cross Country because I was in Cross Country in 8th grade. Being on the Robotics team and in Cross Country wasn’t the easiest, but it was manageable for me.

Over time, I realized that the team culture our robotics team had was really toxic. This matched news I’ve heard about lawsuits going against this team regarding its culture in previous years. As of writing this blog post, I can’t and don’t want to explain how bad it was for everyone on the robotics team, but it was bad enough that I had to leave.

Although a lot of friends I had made did still stick with the team, what ultimately make me decide to leave was that I was realizing FIRST was more of a mechanical and hardware-based competition. I wasn’t really into the mechanical or hardware side of robotics since most of the time I didn’t have access to those systems to learn more about them (I didn’t have access to a CNC machine or 3D printer). Surely software has a role, but many FIRST teams (that I know of) seem to really doubt their Computer Vision skills (or lack thereof) or newly, Machine Learning skills. It makes more sense considering FIRST is a competition geared toward high school kids, who generally don’t have degrees or knowledge of complex/advanced CV or ML algorithms and how to implement them for fast-paced matches. Other than CV or ML, the only software I’ve seen (at Monta Vista’s Robotics Team) that needs to be done is “fine tuning control”. To this day I’m not really sure what Monta Vista’s Robotics team was doing when “fine-tuning control” since remote controlled movement shouldn’t be that hard to implement, especially when other teams open source their code on Github.

I left the team in June of 2017. This was after we won 1st at the Arizona North Regional competition and 2nd at the International competition. I decided that it was time to leave and go on to do other software heavy robotics projects.

A couple weeks after leaving, a nearby rival team, Valkyrie Robotics, asked me to head Computer Vision at their team. I accepted the role since most of the members were also Monta Vista students (there’s a huge backstory on Valkyrie’s existence and why it consists of only Monta Vista students). I spent a good amount of time there daily, but soon got caught in robotics drama. I left in July of 2017.

Picture from: https://www.33rdsquare.com/2012/01/what-will-self-driving-cars-mean-for-us.html

Moving into real Robotics

I don’t really think FIRST robotics is real, professional grade robotics. From my 500 hours there, I’ve learned that FIRST robotics at MVRT and Valkyrie isn’t anything more than plugging in some wires into an overpriced machine no more powerful than a $40 Raspberry Pi 3, called the roboRIO. There’s definitely some hardcore CAD that goes into the design every year and some other outreach programs you are required to toot to other teams to show that you care about your community, but that wasn’t enough to convince me to dedicate many hours of my day on a frequent basis to the team

That’s why I moved onto implementing autonomy onto the RC car I’ve been modifying since 2013.

Playing with ROS

I started using ROS in August of 2017. Having some experience in C++ and Python, I started building ROS nodes to communicate with one another. One of the first things I did was interface two Turtlebots in a simulation to mirror one another’s movements. Surely, I had to follow the tutorial step by step to get to this stage, but it showed me what ROS could really do.

Teaching ROS to FIRST Robotics Teams

After leaving the two FIRST teams I was in, I decided to teach ROS to FIRST teams in the Bay Area. Around 10 teams from around the Bay showed up (which I thought was pretty impressive). I taught them the basics and how they could implement them in their robotics. I even showed them a small demo using OpenCV, a Raspberry Pi 3, and a servo motor. Whenever a line on the whiteboard moved to the left or right, the servo would move that way as well. It was an example of publishers and subscribers with OpenCV integration.

Teaching ROS to Everyone

I made a video a while back detailing everything you need to know on how to get started with ROS. I didn’t have time to edit and upload the hour-long video yet, but will soon.

Getting Started with IARRC

How I found out about IARRC

Same way I found out about AVR; Georgia Tech’s robotics team. I was interested in Georgia Tech so I decided to look around and see what their robotics team is doing (I’ve heard good reviews about the RoboJackets). I eventually found out about IARRC and was surprised to see it allowed high schoolers. What was even better was that it allowed solo competitors to join. This was crucial since I didn’t personally know of many friends who were interested in robotics and had some Machine Learning/Computer Science knowledge.

Initial Approach

I spent 9 months working on ROS

I had OpenCV integrated, a mix of basic and advanced algorithms to take care of different parts of the competition. I knew this was going to be pretty computationally expensive, but not so much that an RPI3 and Dragonboard 410c working in parallel would both be exhausted of memory and CPU power.

Representation of what I had done. By: http://www.yisystems.com

I couldn’t afford a $600 Nvidia TX2 board (even with the educational discount) and had no other option than to scrape the entire ROS codebase I had written tirelessly day and night

Machine Learning Approach

For some reason, I learned some Linear Algebra in Pre-Calculus, so I extended my knowledge of Linear Algebra by taking a look at the Deep Learning Book by Ian Goodfellow and other various tutorials. I quickly grew interested in the field of Machine Learning because I thought Generative Adversarial Networks (GANs) were pretty cool back in 2017 and even got invited to the Tensorflow Developer Summit back in March.

Another reason I was interested in Machine Learning was the various ways I saw it being used to help others. It was being used to diagnose diseases in humans, animals, and plants as well as advanced science as shown in the Particle Tracking Challenge by CERN.

So I started working on implementing Machine Learning in my RPI3 and Arduino stack since it was the only option that didn’t require heavy computation power.

Working on IARRC

TEAM

Just myself. Just a high schooler going against top-tier University teams who could be fully funded by their Universities and could have sponsorships.

HARDWARE / MECHANICAL

Remember when I said I left MVRT because I didn’t like the mechanical/hardware part? I still don’t 100% love it, but I learned how to at least like it to build my robot. Hardware for me took the longest time, since designing parts and figuring out what components I needed took time and research. Stuff like what boards were compatible with I2C protocol was foreign to me a couple months ago, but now I think I’ve gotten a good of a grasp of the various protocols I used (and made) so that I can use it for brushed motor and servo motor control.

LEARNING CAD IN 3 DAYS

Sometimes at the end of June, I realized that my noob Tinkercad skills weren’t going to help. I made a couple of rough models in Tinkercad, but there were several limitations with what you can do on a CAD software that’s purely online. After doing some research I found that Fusion360 was the best option to use. They had several tutorials for noobs who used Tinkercad in the past and wanted to get more functionality, like me.

It took me a grueling 3 complete days and nights to learn Fusion360 from top to bottom.

I’m not a pro yet, but I’ve learned most of the functionality there is to Fusion360 (I’m not familiar with all the keyboard shortcuts though). I used my knowledge to create a cost-efficient CAD model for my car. I created multiple flat layers to cut down costs while maintaining functionality for the robot.

After a couple more days of designing and building, I finally built a model that incorporated all the components I needed for the robot.

3D PRINTING IN THE BAY AREA

3D printing in the Bay Area is hard. Really hard. At least for me. I called over 30 printing services in the Bay Area and found no price lower than $3,000 for my model. Even spaces like HackerDojo or other makerspaces weren’t available or didn’t answer my calls or emails.

With the death of TechShop, the only 3D printing service I knew of was the Sunnyvale Library. But with the dimensions of my model, there was no way I could get it to be printed. Even if my model was in the dimensions of their printer, the earliest date I found on the library’s website to when they were available to print was in November. That’s over a 5-month early booking!

So I went with literally my last option, 3D Hubs. They allowed people with 3D printers from all over the world to print your item at a low cost. The only reason I was hesitant to buy from 3D Hubs was because every time I looked for a printer, I got prices between the range of $300-$500. Albeit this was 10 times as cheap as prices I got from shops from around the Bay, it was still out of my budget.

Long story short, I got a 3D printing service order from Missouri. They gave me a reasonable price under $100 which I thought was okay.

CAD Model of Upper Base for ETG

PUTTING IT TOGETHER

I have a lot of experience in woodworking. I’ve moved to computer science since those times, but have a lot of experience in the field. I used my woodworking skills to build a structure that put all the CAD modules together.

SOFTWARE INTEGRATION

Software Integration is the mean layer between Hardware/Mechanical and Software. It is also one of the biggest challenges I thought I had. I was right.

There were times I went Youtube and saw really cool RC Cars driving around in circles or autonomously driving on its own. Every time, however, I got really puzzled on how they integrate their Python code into their car.

This was still the case when trying to implement the Machine Learning Python code (previously ROS/OpenCV) into the car.

I eventually taught myself I2C protocol and made my own protocol between the Arduino and RPI3 using the Pyserial library (I made my own protocol for faster and more reliable data transfer between the boards).

PWM control wasn’t that hard after I had found the PCA9685. I used the Adafruit library to finally control the throttle and servo.

Network built for ETG

SOFTWARE

Anything I explain here will be nothing more than copy and paste from what I have written in my paper for IARRC this year. Here’s a brief summary instead. I’ve also attached a link to my paper at the end of this section and the beginning of this blog post.

BRIEF SUMMARY

I used Tensorflow to build a DCNN for Traffic Light Detection. I trained it on around 5,000 images that I pulled off Google Images. I had a 100 image test set and a 1,000 image validation set.

I used Tensorflow to build a DCNN to predict Steering Wheel values. I trained it on around 50,000 images I collected during the pre-competition day they gave us. I had a 5,000 validation set and a 100 image test set.

I used Tensorflow (I solely used Tensorflow, although I made a model in Caffe that had several problems running on the RPI3) to build a RNN/LSTM model to predict Throttle values. I explain this in my paper, but essentially it prevents rapid changes or stutters between drive loops. In other words, it smoothly increases and decreases speed instead of rapidly accelerating and deaccelerating at random instances. During testing, the DCNN model actually broke the camera model a couple of times (as well as the ESC for some reason).

Salient Object Visualization. Video here: https://www.youtube.com/watch?v=lFjsN7KcKIE

I EXPLAIN A LOT FURTHER OF WHAT I DID IN MY PAPER.

GRAB A COPY AT THE FOLLOWING LOCATIONS:

Publication	Link
arXiv	https://arxiv.org/abs/1807.08233
Surya Dantuluri Paper Archive	https://sdan.cc/archive/1807.08233.pdf
ResearchGate	https://goo.gl/GoEj9s

Traveling

Airborne

I wasn’t done with the robot when traveling. I started having memory issues on the RPI3 when running the main Python script for more than a minute. This panicked me throughout the flight. This even prompted me to continue coding throughout the extent of the overnight flight.

I eventually fixed the errors, but in a way that was not stable at all. These final days before the competition reminded me of times before a hackathon’s deadline.

I had no sleep for the last week before the competition.

Landing in Canada

The humidity difference hit me hard. Last time I’ve experienced humidity levels that high was in India and Singapore. People also seemed like they were trying to escape into an AC equipped space fast. I’ve heard the temperature I experienced was an anomaly to temperatures generally in Canada, which makes more sense.

Raceday

Thursday

I was in Waterloo by Thursday. My mom and I went around the huge University of Waterloo Campus. It was as big as a city! There were new building everywhere and a big student population still roaming around during the summer.

I even decided to look at the parking lot where I would be spending the next two days racing my ETG robot.

Unfamiliar with Canada, University of Waterloo, and its students, I treaded the Engineering Building 5 with caution. I found a team who looked surprisingly young testing their bot in the building but didn’t believe that they were doing it for IARRC. I didn’t know you could freely stay in the building and work on your project at the time.

Friday

That team I saw on Thursday soon became friends with me on Friday. They had a somewhat basic OpenCV + Arduino robot, similar to many University level robots. I have to say they had some high-quality people on the team who knew everything about their bot and seemed genuinely passionate about their bot.

Initially, my robot was doing well roaming around. I was happy that at least the basic manual control worked over SSH. Then I started having the worst problem that I imagined.

The ESC broke.

Or at least I thought it did. I heard Ottabotics, in their words “quit” after their ESC broke, so I thought this was the end of the road for me. Surely, I hope it wasn’t since I came from over 4,200 kilometers away, and I hoped a simple $50 piece of hardware didn’t completely ruin my robot.

Perseverance was one of the things a lot of the judges and organizers told me that they saw in me. I thought the same thing as well. I came upon two huge hurdles during testing days and somehow managed to debug and fix the issue in record time. Regarding the ESC, it took a lot of debugging and electrical engineering knowledge to finally figure out that an external power supply was not needed to power the power-heavy servo motor.

Debugging the ESC took me 3 hours of tireless work. Then I started collecting data. I knew that collecting track data was the only good use of my time and battery power instead of taking the ETG on joy-rides. I collected around 40,000 good images, or so I thought.

Saturday

Given how chill the University and High School teams were (in comparison to any competition in general in the Bay Area for High Schoolers) I was also pretty relaxed, but still ready to go.

I just trained all my models on a cluster of Nvidia GPUs for an hour. I had gotten good loss scores so I thought my car was ready for the track.

When I initially tried it out, I got an error about some dimensionality issues between the model structure I was running on the car and on the GPU cluster. I didn’t think it was that big of an issue because I probably didn’t update my RPI3 software

Github

Github started my coding career. However, my lack of organization during this process (as shown in my contribution history over the past two months) caused me to train a model that was on a different branch. It took me an hour of debugging to find this issue on the ground in the parking lot. For some reason, the middle of the parking lot was the best place where I could connect to the internet in Building 5 and have a connection to the RPI3 over SSH.

After figuring out the issue, I started training my model in the rain. It started raining for some odd reason, even though it was pretty hot and sunny outside. I trained another model just to see if I could get a lower loss score (lower loss score but not so much that it’s overfitting).

It was unconventional already to be one of the only high schoolers there, but training my model on the parking lot was essentially everything all the other teams did with OpenCV and ROS over the past year.

That’s something I still can’t wrap my head around to this day.

Clockwise not Counterclockwise

So I trained all the data I was talking about for the car to go around the circuit and drag races in a counterclockwise direction. I learned soon that the race would go in a clockwise fashion.

I spent the next 3 hours pre-processing all the data I had. I whipped out some rusty Java skills I had from APCS and some Pillow documentation in order to flip angle values in the 40,000+ metadata files and flip the 40,000+ images horizontally so that I could train the model to go clockwise.

By the time I was done training this model, 2nd circuit races had finished and I couldn’t log a much better score. I tested it before they removed the track and it did quite well, possibly allowing me to place top 5.

Ending

I did my matches pretty late. I didn’t even think I should’ve done the 2nd circuit race at the time because I was sure I was far behind everyone else. Only now do I regret that decision.

Everyone cleaned up their materials and was ready to get the decisions for the match.

The results were pretty obvious, with Poland getting 1st, VAUL getting 2nd, and a team from Thailand getting 3rd.

Finals scores came out a week later. I came in 9th place up against University level teams. I outscored Georgia Tech and a couple other Canadian University teams.

Outscoring Georgia Tech was something I never expected.

Conclusions and My Limitations

This year-long journey was a long, strenuous, emotional, and most of all fun adventure. I had many dreams as a middle schooler and this was one of the ones I overtime didn’t think I could achieve.

Outscoring Georgia Tech on my own

This is something I thought would be impossible.

I lived in an apartment. Which mean I didn’t have a garage. Not even power tools.

I never had a mentor or coach

I didn’t have enough money to buy those coaches every friend I know does for their research projects.

So I created a 100% original and organic research paper out of my grit and passion for Computer Science and Robotics.

I self-taught myself everything I explained in this blog post and paper.

_ So to say that I outscored Georgia Tech on my own is a testament of my work and passion. _

Ending the Journey this Year

I’ve written over 1.9 million lines of code in the past 1 and a half years I’ve learned to code. Some might think I’m crazy, but I think coding is addicting. I’ve decided to hopefully take a break for the rest of this year starting in September (unless I go to PennApps) so that I can catch up with my own life outside of CS. Hopefully, this will give me time to think of new ideas and new approaches to problems I’ve encountered in my code right now.

Takeaways from IARRC 2018

I haven’t run post-project tests on the IARRC repo I made yet. These tests give me some statistics of various statistics of the repo. I’m guessing I wrote an upwards of around 10,000 lines of code, including code that I didn’t use on the vehicle during the competition.

As I’ve explained in my paper, I’ve found that machine learning methods can actually rival traditional computationally expensive computer vision, path planning, and localization algorithms. With this proof of concept, I’m planning on allowing the ETG 2 to learn on its own (hint: definitely not RL).

Canadians seem really nice and understanding and the IARRC competition was held without any flaws. International teams didn’t seem like they were competing with one another, rather just having fun driving around little robots. Teams also collaborated and helped each other out during the competition. This is what research and advancement in fields such as self-driving cars should look like; having fun, competing, and collaborating.

I’m definitely coming back to meet these extremely diverse, passionate, and compassionate teams next year to have some fun.

Acknowledgements (time sequential)

Caleb Kirksey
- He gave me some initial help and encouragement
kangalow from JetsonHacks
- He gave me some advice on what ESC to choose
Mohamed Alzaki
- He gave me some advice on how he implemented Ultrasonic Sensors into his robot
Tawn Kramer
- He gave me advice on how to integrate Hardware with Software in his videos