At the end of last year, we released Try Viam to let anyone take the Viam platform for a spin. With Try Viam, you can take over a real robot from our New York office, without having to do any hardware setup at all.
When creating the project, a key decision we had to make was – which robot?
We needed one that was durable, low-cost, and ready to use out-the-box. There are a ton of options on the market, and we are big fans of certain models. However, one of the best things about Viam is that it works with any type of hardware you want to use. And Viam seriously accelerates hardware iteration cycles during prototyping.
So, we decided to build our own: The Viam Rover.
Viam Rover
The Viam Rover is a great robot for both learning robotics and supporting a broad number of cool robotics projects. It has the hardware you need to get started out of the box—you simply provide the compute board (in this case, a Raspberry Pi). And, the Viam Rover can be modified with additional hardware like adding an arm on top.
Most importantly, the code you write to control the Viam Rover or any of the higher level services you choose to take advantage of in Viam will work the exact same way with a robot on a factory floor, in a field, or under the sea.
As Viam’s resident hardware engineer, I was tasked with creating the Viam Rover and was able to take it from ideation to production in just a few months.
Design
The Viam Rover needed to provide a strong foundation for both getting familiar with Viam as well as supporting a broad number of robotics projects.
For us, that meant a board, two encoded wheels, a camera, and an accelerometer – everything you need to cover the basics like how to move a robot, understand its performance, and apply higher level services such as Computer Vision.
And, the top plate has mounting holes so you can add on LIDAR, robotic arms, and anything else as you learn.
Prototyping
Getting the Viam Rover wired up wasn’t too difficult, but with hardware you need to test, test, and retest.
Traditionally, you need software skills to get a robot set up for testing—which is a challenge for me, a hardware engineer that is still developing my coding chops. But Viam bridges the gap between hardware and software, and actually makes it pretty simple for hardware folks to iterate during the prototyping stage all from the same platform software engineers use to program the robot.
For example, I handed over a configured Viam Rover to our SLAM team and they instantly started implementing SLAM services–which were originally developed with a different robot–with a Viam Rover without having to re-write any low-level code relating to the robot configuration.
Viam made it easy for me to independently install Viam on my robot, and configure, test, and debug its hardware through an intuitive UI – no coding or software engineers needed. Here are the highlights:
Hardware configuration
Once I installed Viam on the rover, I was able to easily configure its hardware through Viam’s UI. Viam abstracts common hardware models into types such as ‘motor’, or ‘arm’, and supports hundreds of common drivers (if Viam doesn’t support it, you can easily write your own driver using our SDK). All I had to do to test my first rover was declare the hardware, describe a few attributes, and fill in how it was wired up. No software engineering required.
Iterative testing
Once my first rover was configured, I could immediately test it remotely through the CONTROL tab: operate the motors using my computer, or any hardware controller, and view the live feed from the webcam. Now, my first iteration wasn’t using the hardware the Viam Rover has – I actually hacked the first motors out of a few old mobile vacuum cleaners (they’re the same form factor after all).
As I tried different motors, I simply updated parameters in Viam’s UI to describe their differences – GPIO vs GPIO-stepper, non-encoded vs encoded, encoder type, ticks per rotation, and so on. It was even easier with the cameras. I simply declared ‘camera’ through the UI, and each model worked automatically. As I made each of these changes, the Viam Rover was automatically updated.
Debugging
As you can imagine, not everything went to plan right out of the gate. After assembling a few rover prototypes in the office, I noticed that one Viam Rover was dragging to the right. To debug it, I simply opened up Viam’s UI. In the CONTROL tab, I could reference a live feed of the motor’s position. I immediately saw the right motor wasn’t moving at the same rate as the left motor. After replacing it, I checked, and the motor was synced up and operating correctly.
Final testing
Now that I had a working prototype it was time to finalize with engineering. While most of us are based in our New York office, we have a few remote folks. Thankfully, Viam robots can be securely accessed from anywhere. I worked with an engineer in Oregon to write a simple script to stress test the hardware. He was able to write the code, and securely connect to the robot, right from his home office. No customization or extra software required.
Production
And, that was it. Our final prototype was off to manufacturing. I won’t get into that adventure, but if you want to chat about your manufacturing experiences, or really anything with robotics and Viam, do join our Discord server. If you want to control a Viam Rover in our offices, you need to check out Try Viam–the best way to get familiar with Viam.
I’m biased, but I think the Viam Rover is a pretty slick robot. If you want one for some of your own robotics projects, you can get one here!
