In response to the posts on this hackernews post, I wanted to take a simple thought experiment into what it would take to create a simple hobbyist snowblower robot. This is all very high level and is not exact by any means.

Let's just throw a dart on the board with an MVP that would be a 4 wheeled robot with a snow shovel on the front, battery powered, and sensors to help the robot locate (localize) itself to the environment it is in. We'll assume a general purpose snow plowing robot for a single family home - consisting of a 2-car width driveway and sidewalks. I will make assumptions here that the robot should have an IP rating enough to keep the water from getting into harming the electronics/motors. I will discuss some of the problems below along with the tradeoffs we could make.

The problems we'd face

Again, not a comprehensive list. Just some that I could think of while writing this post in response to the Hacker news post.

A reasonable budget. After all, this is a hobby, so we could assume a limitless budget. Learning is fun, why limit that!
Having a robot large enough to plow a standard size snow shovel equivalent to a human held unit. 18 in. combination blade is ideal for shoveling and pushing snow. (As a hobbyist robot, perhaps you could make a smaller scale version of this. Again, it'd probably take the robot all day to plow the snow and the question of time vs value comes into play. How much time building the robot for how long it takes to have the robot plow the snow. It is a hobby, after all!)
Actuating the snow plow up and down - we'd probably want a plow that we can operate so we don't just push the snow back to where we just plowed it.
Dealing with the robot getting stuck in the snow. Due to this, we'd probably want a 4 wheel drive independent motors, along with a suspension that could flex to varying heights of the snow.
Finding a battery and battery management system that could handle low temperatures and supply enough power for the motors and compute.
Finding some compute small enough to fit into our IP rated enclosure/chassis, powerful enough to run the algorithms for PID/MPC, localization (unless you just want an remote controlled unit), and low power enough for the smallest size batteries.
Choosing 'robust' sensors to help the robot localize (know where it is). Since we would assume that the wheels may slip in slow or ice, we can't really rely on the odometry of the wheels to tell us how far we've gone, and thus, cannot use them to localize.
Fast iteration feedback loops. After all, that snow could be all melted by the time you 'get to market'.
Keeping the electronics dry. As I mentioned above, we'll assume an IP rating to keep water out, but we'll have to take in account the wiring leaving the enclosure to get to the edge of the motors/actuators.

The hardware

You'd need:

A chassis that you could mount the snow plow to, as well as the motors, wheels, compute. As mentioned above, we'd want IP Rated enclosures - either one to hold everything (motors, actuators, compute) or a distributed set of them.
Sensors to support localization - either small lidar units (expensive), cameras (what if we go blind, more below), or some other paired set of mechanisms, perhaps GPS / BLE / RFID. We might even need those sensors to be placed in the environment if we want a smaller compute footprint.
A rigid body that the plow attaches to for support actuating up and down. Thus, we also may need some weights on the rig to keep it stable while driving. (Akin to putting sand bags in your truck while driving without any payloads).

The electronics

At a high level, you'd need the following:

Boards to control the motors (arduino, beagleboard, Raspi, etc).
A battery to power the boards that can power all motors, compute, etc.
Some mechanism to control the battery and switching to charging (battery management system). Assuming we'd want to just plug and play batteries (think like portable drill batteries), we'd need some boards that can do power transfer to what the compute or sensors need.

The software

Could use ROS here. Plug and play for a lot of the sensors mentioned above.
You'd need something to localize, based on what sensors you use, whether it be LIDAR (expensive), cameras (compute intensive), or some beacons to assist. Either solution, you'll need to rely on Kalman filtering for state estimation. Here are some localization methods from Carnegie Mellon.
If you don't choose an off the shelf solution, you're probably ready to sign up for a PhD level course to learn more, needing background in linear algebra, probability, bundle adjustment, and other algorithms to assist in SLAM.
Your software will be heavy on the compute depending on the speed you require. The more speed and power, the more battery you will need.

Iterating - feedback loops

Chances are your iteration with hardware will be the slowest iteration loop.
Second to that, the time between software revisions.
You'll probably be best fit to have a laptop that you can plug into your board (or boards) to flash the USB card, JTAG the board, or however else. You've got updates to hardware, firmware, electronics/boards, or the software itself. Many changes to make!

Supply Chain

Want new hardware? Either 3d print (without the IP Rating) or order some parts. Ordering will take a week or more, depending on the source.
Want boards? Maybe you're lucky to live down the road from Sparkfun, or you've got amazon prime for 2 day shipments.
Want custom motors? Order from China, wait a few weeks.

Working generally vs specific cases

Depending on your use case, this is a large effort at least, an extra large effort at worst. There's a reason hardware is 'hard', since the iteration cycles take longer and mistakes 'cost' more.

Why is the large effort at best? You'll need hardware, electronics, motors, and software to drive them. It's not an easy task, but if you're up to it, you're the best hobbyist of them all.

Cheers!