OSHWA Trailblazer Blog Post 8: Flower∞Bots Learning Road Map

As my year as an Open-source Hardware Trailblazer comes to an end, I am so appreciative for this opportunity. I have learned so much along this journey, including the proper way to document my project, that there is no such thing as too many resources and that I need to make an entry point for different types of users. Based upon this, I have created a learning road map so that people can determine their entry point for open-source robotics. A novice would start with Lily∞Bot and the top row on the road map. An intermediate user would start with Daisy∞Bot and the middle row on the road map. Finally an expert user would star with Rosie∞Bot and the bottom row on the road map. Therefore, although I include educational levels at the bottom of the chart, it is just as legitimate to use the novice, intermediate, expert levels instead of the school years. I hope you enjoy this journey as I continue to post learning materials to help you grow in robotics and also eventually post the kit and curriculum for sell on a website.

FlowerBots Road Map

OSHWA Trailblazer Blog Post 6: Debugging and Troubleshooting

Open Source Hardware Association and Sloan Foundation Logos

 

 

Debugging and Troubleshooting

A key skill set for all engineers is to be able to problem solve which involves having debugging and troubleshooting skills. No one writes perfect code or builds a perfect circuit or 3d model. In fact, I’m actually embarrassed to share how many robot chassis, sensor and motor mounts we had to 3d print to get Lily∞Bot built. Then even with us now having a working model, we have discovered some necessary improvements and are already on to versions 2 and 3. It’s called continuous improvement and when you can see better, do better. Even with all of this, a bug still sometimes sneaks through and in the engineering community we like to call it “a feature”, not a bug. In the robotics community, we call it an emergent behavior.

First of all, troubleshooting should always be systematic. In other words, start with a with a clear plan and continue iterating through the possibilities until the problem is corrected. There should be a hypothesis, test plan and evaluation of the results. It’s necessary to identify which errors are systematic and repeatable and which ones are observable and resolvable.

So how does this relate to open source hardware? Well, the most obvious connection is that since the design is completely transparent and typically designed by the user, it is possible to verify all the subsystems with the documentation. Also, since it is white box testing, there should be few errors that are not observable even if not fixable. Then, the next benefit is that with open source hardware just like with most other elements in engineering, the community can help identify errors and also help solve them. Yet another benefit in addition to using their innovation to improve designs. I always tell my students the first step is always check the power first.

Similarly, a systematic process to creating code such as by having a software design plan is integral to debugging your code. In addition, detailed comments are a must as well as logical names for constants, variables, and functions. In programming, some of the most common mistakes in code are opening and not closing parentheses, putting or leaving off semi-colons, or trying to access variables that are not defined or not local or global.

Now that we have shared the joys of scholarship reconsidered for academics and also some of the key components of engineerin such as the design process, creativity, innovation, debugging, troubleshooting, please come along on our journey to bring Lily∞Bot to life. Our open source mobile robot platform to afford academics doing service, teaching, research, and professional development.

∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞∞

8/28/22 Video Blog: Debugging and Troubleshooting