Updating the Action Plan

admin's picture

Nomad has been out and about as a show piece a lot, lately. Unfortunately, still not sufficiently mobile. Recent experience and discussions with folk from The Robot Group, ATX Hackerspace, and at some of the many exhibitions has made a few things abundantly clear. First, I need to address the power issue sooner rather than later. Second, I need to get Nomad running about, even if only with the game controller at the moment. And third, there is still much work to be done on its physical configuration.

Ah, life. The first half of the year has been crazier than expected. Between travel, work, managing The Robot Group, putting together content for workshops, and the consulting work for Makerarm, there has been little time for my own builds. That does not include the work I've been doing to organize and run an unrelated, annual convention. And, now, I'm starting a new job next week. Very exciting, that. After nearly seven years, I'm leaving my current role, at Dell, for a new adventure with a company called SparkCognition. The really exciting thing is Nomad helped land me that position. So, thank you Nomad.

But, in this last six months, Nomad has also been traveling about the Austin area. It's been to SXSW, again, and then on to exhibits with the Boy Scouts, at schools, museums, and even promotional events at theaters. In all those wanderings, it has not moved on its own... at all. And it's been very frustrating to stand there and explain the things preventing motion and not having the time to address them. But, that is changing starting today. So, what is needed and what are the plans to address them?

The thing that will have the single biggest impact is addressing the issues with power. In my most recent tests, and by most recent I mean October, whenever I ran the motors, the current draw was so high it would drop current to other areas, most crucially being the main board. When current dropped on the Jetson, it would reset. This means commands would stop being issued to the motor controller, which would faithfully execute the last command it received... the very command that caused the board to drop. Well, that one is fairly easy to fix; isolate the power for the electronics from the power for the motors. Since I'm running four hefty lithium polymer battery packs, devoting one to the electronics while leaving the other three for the motors, solves this issue. This also means, however, that I need to run an isolated line from the power supply while it's on the bench, otherwise the motor controller won't be available for the serial connection from ROS. A simple solution for the motor controller availability would simply be to reconfigure the motor controller to power the logic through the USB rather than the motors' power supply. Easy enough.

While at the shows I would frequently use the battery packs to power the internal lights, which would have the added effect of powering the fans. This revealed a design flaw and an opportunity. First off, I am powering things unnecessarily when a general power distribution strategy is used. In order to save battery life and provide more control over what is, and is not powered, I will need to add a control circuit. Probably the easiest way to do this would be using a series of switches, but that is so manual. Rather, what I will do is add a separate microcontroller and relay board to manage the power throughout. I have a number of push button switches that I can use to toggle the power for individual circuits and implement logic for overriding as needed. Or I could drop on an LCD and use a mode selection approach. Food for thought.

The added opportunity here is implementing a watchdog process through the microcontroller. This watchdog process would monitor the power on the main board and, should it drop out, it could shut off the power to the motor controller. In a similar fashion, it could also monitor the overall voltages across both banks of batteries and implement logic there, as well. If the voltage for the electronics is too low, initiate a shut down sequence. If the voltage for the motors is too low, initiate an notification and charging sequence. This last point, the charging sequence, is another opportunity.

Charging internal batteries can prove challenging. Charging internal LiPo batteries even more so. I currently have all of the batteries housed in to easy to access compartments, one on each side of Nomad. When they need charging, as they do now, I have to remove them and put them on the charger. At the moment I can charge only one at a time. So, there are two solutions. I can invest in a better charger that will allow multiple packs to be charged simultaneously. Or, I can build an internal charging solution. Of course, I can also do both, an internal charging solution and an external charging solution, especially if I invest in back-up power packs.

The second need, getting Nomad running, can happen in parallel to the other two. Once the power is isolated within Nomad, and batteries are actually charged, I can work on getting Nomad moving about. Of course, this is the big, multi-staged goal... a working robot. The code for running Nomad with the game controller is already working; that's how I discovered the power drop issue. So, once the power issue is addressed, so will this. From there the challenges of getting the sensors connected, working, and sending output to the Jetson board begin. And from there, autonomy. That's the long term, ongoing purpose of the entire project. So, power, run Nomad on the game controller, and continued research and development into autonomy.

Which brings us to the third need, revelation, whatever you want to call it; the physical build. Right off the bat, the very first thing I need to do is solve the squishy tire problem. What it boils down to is, Nomad is just too heavy for the wheels from the original kit. I actually have two options, here. Well, three, actually. I have the parts to make the tires air-filled, then I use a compressor or air pump to make them universally rigid. I can use a denser foam for the existing tires. I had though about using Good Stuff spray foam insulation, but Derek pointed out that it breaks down pretty quickly under stress, which the 16lbs of robot will cause. And, of course, the third option is to replace them all together.

And then, I'm afraid there's no way around it, Nomad is going to need a new shell. As nice as the current one is, it just doesn't leave the kind of room needed for expansion. Not to mention it's a bit to flimsy for my taste. The Jetson's carrier board is huge; a lot larger than I really need. Making my own carrier board, or finding one that's smaller, would go a long way to freeing up space. But, third party boards are expensive to sat the least, and the DIY approach, where viable, is a bit time and labor intensive. Not that I'm opposed to that, but, as you've read in the beginning of the post, time is a precious commodity I just don't have in abundance. So, most likely, I'll be using the existing board and designing around that. Which brings me to my next quandary; how much of the original kit stays and how much simply goes away? I have loved working with the Actobotics parts and I recommend them strongly for any prototyping projects you may have (and most custom or hobby robotics falls squarely in the prototyping category). But there comes a time in every project where you have to trade off that convenience and flexibility for out right  efficiency. I think Nomad has reached that stage. Of course, I could also port the entire project over to the Mantis chassis. More food for thought (I am going to have some fat thoughts if they keep eating like this).

Okay, so let's break this down:

  1. isolate the power for the electronics from the power for the motors
  2. run an isolated line from the power supply while it's on the bench
  3. reconfigure the motor controller to power the logic through the USB rather than the motors' power supply
  4. run Nomad on game controller
  5. add a separate microcontroller and relay board to manage the power
  6. add an LCD tot he controller and implement modes (run, exhibit, test, etc.)
  7. implement a watchdog process through the microcontroller
  8. build an internal charging solution
  9. buy external, 4 channel charger and another set of battery packs
  10. connect sensors
  11. connect GPS
  12. connect IMU
  13. connect camera
  14. add power to USB hub
  15. make the tires air-filled
  16. replace wheels with rigid equivalents
  17. design new chassis
  18. physical rebuild

Of course, this isn't necessarily the order of operations, nor is it all inclusive. It, obviously, doesn't even address the autonomy tasks that are forthcoming. But, this is an ample list to get me moving on the project.

Startup Growth Lite is a free theme, contributed to the Drupal Community by More than Themes.