This page has updates on some of the work I've done at Udelv, an autonomous delivery startup in which I am a part of the Vehicle Robotics team. Our team is involved with all aspects involving the vehicle, cargo and teleoperation.

We work closely with the Autonomy team and Hardware team. I also worked closely with the Business Development and Operations team to get their requirements to make sure we were all on the same page.

We are a team of 3-4 people so it's pretty much all-hands-on-deck. While my role is in simulation, I worked on the vehicle state logic, the cargo logic, some of the teleoperation aspects, and once we began working with Apollo (Baidu) in mid 2018, porting all the nodes to work with protobuf, refactoring, and making sure our repos could be mounted separately from their repos. I provided engineering support for the tests in AZ, TX. 

Since the shelter-in-place order, I have set up my simulation workstation at home to test autonomy and cargo in simulation. 

I created some video logs to share issues and successes with the rest of the team. The video on the top right shows a sample of the tests we do weekly in Houston and one of our first successful switches to arrive state after fixing some of the bugs in the vehicle state node code that I found in simulation. Switching to arrive state has been one of the important pieces in integrating an autonomy loop with what we call our 'cargo robotics'.

Once I was able to test my route request code on a route with autonomy engaged, in simulation, other issues surfaced. Finding these in simulation before testing on the real vehicle in Houston saved us a lot of time.


The planner had a tendency of kicking out. Part of that was due to the overlapping waypoints on one of the loops. The planner brake messages (sent) and the chassis messages (drive-by-wire) did not match as we approached the final destination in the parking lot, causing the planner to kick out at times also. 

By the way this is our autonomy delivery vehicle and cargo:

After developing the nodes to control the motors on the first and second cargo, some of the tools I worked on was the webgl/three.js visualization/diagnostic page - basically when the car receives a command to open the cargo, I use rosnode js to listen to the cargo messages to animate the 'iris' doors. While the car is operated remotely we can see which openings are sent/received. 

The 3d page helped us debug some of the issues with our cargo node, which actuates 4 garage doors from the top/bottom, left/right on each side of the vehicle. We call it the 'iris'. The red beacons flash to show latency or lack of messages on motors, gps, and modems.

Our first vehicle platform, the Newton:

Above are some of the early dashboards that I built using plain javascript. 

We were testing the vehicle while doing real deliveries with small businesses around San Mateo. After a few failed deliveries with doors stuck open/close or the routes out of sync with the cloud, I sat with the driver to figure out what we needed on a dashboard for troubleshooting or overriding the states on the car and to open the doors manually if needed. The override was a key feature and saves us many times...

One of the early tests in sim that I did involved driving the car in gazebo, and checking to see that the states were changing properly. I also simulated the cloud using curl to send routes in json format and fulfill the order by opening the correct doors. Later I wrote some automated unit tests at every build.

I built these early worlds with google map tiles and a script to build buildings from osm data. I also built scripts to generate different types of parking lots.