Monthly Archives: July 2021

Now that I have my robot built, it’s time to start making it do things. This is where I got stuck before last time. I was using an Arduino at the time to control the steppers and read in the range finders’ data. Now that I’m going 100% Raspberry Pi for the brain, there are no longer any memory, speed, or math concerns like last time. I expect that to be helpful.

With that history out of the way, what’s the roadmap for this next month?

Weekend 1 — The Console

I’d like a simple console application that shows the range finders, stepper motors, and other basic status text. I’d want it expand to use all available space like htop and other similar applications. Figure it’d look something like the featured image above.

Obviously I’d color the hell out of that. After all, 95% of debugging is making sure the console colors look right. The most important part is that I have the console’s UI completely done. I don’t care if none of the sensors or motors are hooked up to it. I care about if it can store and display all the necessary state information.

I’d also want the console to be able to accept user input. I’d like it to be able to stop all the motors and put them to sleep when Escape is pressed. I’d like a way to individual control a single motor.

Weekend 2 — REST API and Movement

Once I have a way to display the internal state, I need to begin accepting REST requests to update that state. I want to focus on getting the wheels moving and performing a set routine showing off the robots maneuverability. I’d like to be able to do something like curl http://catpoo/api/dance/1 and have that trigger the robot to the first simple “dance”. Executing curl http://catpoo/api/dance/2 would do another predetermined routine.

I’ll consider this step successful once I have the following minimal API implemented:

API endpoint	Description	Notes
/api/stop	Stops all motors while keeping them energized	This is what should be called in the event I implement a panic button.
/api/sleep	Stop all motors and put them to sleep	This is also a good option for a panic button, but has the added benefit of turning off the motors. This is a good default, power-saving state.
/api/move?x=123&y=-100&rot=10	Instruct the robot to move the desired distance in the X and Y axis while rotating a certain amount	All variables are optional. /api/move would be the same as calling /api/stop. To move forward it can be called as /api/move?x=100 or the more verbose /api/move?x=100&y=0&rot=0
/api/dance/123	Cancels are current movement and begins a predetermined “dance” routine	This is how I’ll debug how well the robot is moving, or show it off when I don’t want to remote control it.
/api/status	Return status information	This would only need to include 1 or 2 things for now, but eventually would be where all the range finder and accelerometer data would be populated.

Weekend 3 — Web UI

This is where things finally start to get interesting. This weekend will all be about getting a basic website served using Bootstrap, ReactJS, and that good stuff. To keep myself from going down rabbit holes, I’ll be focusing solely on the following MVP functionality:

1. Video stream works
   • I’m not worried if there’s a bunch of lag, low FPS, or suboptimal resolution.
   • Video should take up the vast majority of the screen, with UI elements on top of the video
2. Movement controls
   • Doesn’t need to be fancy. If it can go forwards, backwards, stop, and turn to the left or right, that’s enough for this point
   • Write does notes in another post for any cool ideas for the UI. Keep this barebones as possible.
3. System settings page
   • I don’t want to make the mistake of having no options for configuring and fixing issues quickly.
   • At minimum, I’d like a GUI page to allow me to change the wireless network that the robot is connecting to.
   • A virtual keyboard would be best as I don’t want to have to rely on having the keyboard handy.
     • If I was going to keep the keyboard handy at all times, it would make a good remote control for debugging when w/ the console…

Weekend 4 — Typing Up Loose Ends

It’s time to pay the piper. Got to get this demo ready. To who I would be demoing, I do not know. Maybe I’ll see if it can play pool down at the local bar. Who knows.

I’ve not thought about hooking up the only simple sensors that give the robot an idea of what’s going on in the world. Anything else involves the camera which would require complicated computer vision. I’d like to go down that road, but not yet. The range finder information and accelerometer need to be represented in a visually intuitive manner on screen eventually. For now, I’d be happy with raw data dump on the side of the screen. Once I get the information flowing, I’m confident in my abilities to make it useful and look cool.

The other loose end by this point would be the webpage itself. It needs to be usable enough that my wife can use it to chase the cats. It needs to have a dead mans switch so that if the browser is closed, or the connection lost, the robot doesn’t end up crashing into the nearest wall or down a flight of steps. I also want the UI to be close to finished. Good enough for awesome night vision screenshots.

Unscheduled Tasks

Here’s the section for dumping thoughts on things that I want to do, or think I should do. I’m pretty sure they’re all option. I’m going to do them anyways.

1. Bill of materials
   • I really should collect together a list of materials that I needed to build this.
   • Whether someone else wants to make a copy of what I’ve done or not isn’t important.
   • I want to know how much it cost to build this
2. Write about the construction
   • This is where I want to explain why I did the things that I did.
   • I’d like to also capture the things that I was happy about, as well as the things I’d have done differently
3. Begin production of new body
   • Now that I designed everything and I know it works, I’d like to make a new chassis that looks super awesome
   • I’m leaning towards letting my wife do the decoration, even though I’m afraid it’ll end up looking like a panda
   • Once the new version is printed, it’d probably only take an hour to disassemble and reassemble in the new chassis

Future Thoughts

Once all these features are implemented, I’ll be a point where I’ll have to decide what to do next. I always wanted to develop this platform so that I could swap out the bottom and take it on a calm lake or river. How cool would it be to have a kayak buddy to help take selfies of my wife and me? Yeah, I could buy a drone off the shelf, but where’s the fun in that?

It’s Alive! (Again!)

I’m proud to report that my newest robot iteration has been built. Look at it in all its glory:

So far, all I’ve been able to verify that the basic system is working as intended. The LCD screen is working great. The power consumption is rather low at idle (assuming the IR illuminator isn’t triggered). The I2C bus is showing that the 4 channel ADC is working, as is the accelerometer. The camera is also working well.

Next Steps

Now that the basics are all verified as operational, it’s time to start testing things further.

Things Left To Test

1. Test the 4 channel ADC circuit
2. Test the accelerometer circuit
3. Test the stepper motors

Things Left To Implement

In short, everything needs to be implemented. In no particular order, here’s what I have planned for the next few weekends:

• Write proof of concept code to read in the values from the ADC
• Simple movement test program to have the robot perform a predetermined routine to test out the wheels
  • The movements, if done properly, should cause the robot to return to its original location
  • Use some sort of cat and kata pun in the name. pookata? catkata? catkatapoo?
• Create a console (i.e. ncurses) based application to expose the robots internal state in a top like fashion
  • This will mainly be a great way for me to ssh in and screen -r to see what’s going on inside the robot.
  • It doesn’t have to be pretty, but it should be at least look as nice as htop or glances.
  • Should show the current acceleration state of all the motors, ranges finder values, and temperature
• UI/UX mockups and design
  • For the range finders, I want something not precise but intuitive to understand. Maybe fade in red on the edges of the screen? Front side is the top of the screen, and so forth? As the range is shorted, fade in a red hue like an injury indicator from Black Ops Zombies? Visually it might read as “not having space” equals “robot pain”. I’m ok with that. Hell, lean into it. Make the robot attempt to always maximize the distance between it and everything else.
  • A configuration page would be necessary
    • This would mostly be related to configuring network settings on the fly away from home.
  • What differences would there be between the UI on the back of the robot, and what you’d see in the browser?
    • Should disallow changing system or network settings over mobile
    • Could display CPU utilization and not on mobile? I’d be ok with having as much debugging shown in the mobile app actually… something like out of old school Terminator movie vision.
• Actually implement the mobile interface
  • I’d like to use ReactJS with the interface, as I’d like the option to port it to a mobile app later
  • Should work well on desktop and mobile

End Goal

The initial version will focus on allowing easy remote control via any web browser that can connect to its built-in Wifi hotspot. The user interface should be simple and intuitive. Within 5 seconds of loading the website, my wife should be able to use it to chase the cats around in the dark.

Once I’ve gotten that far, the sky’s the limit from there. I could start learning about AI, and pursue making the robot autonomous. I could instead focus on making it as small and energy efficient as possible. What about making them as cheap as possible, so that I could have a swarm? Lastly, I could instead focus on making it able to navigate outside or in water.

In whatever path I choose, I’ll be able to reuse large amounts of code and object models. I’m looking forward to that.