We made progress today and ROVer ends the day stronger than ever in the Autonomy department, but we didn’t quite make it far enough for him to stretch his legs for a drive test. Don’t get me wrong… there was lots of testing as all the new programming that I did resulted in more broken code than I’d like… so debugging was a big part of the agenda.
Fortunately, we now have the ability to assign multiple switch-cases to commands and programs within the Events section of ROVer’s Command Center (aka cloud server), which will prove immensely useful as we move forward.
Boy did I battle some monster bugs to get this to all work, reliably, but we got there!
ROVer is now able to respond to his sensors depending on what his happening around him – respond differently depending on how his mission, per se, may change and adapt to his environment. ROVer’s Arduino, Android and Command Center (web server in the cloud) have all undergone some big-time upgrades to make this happen and any time that I go so deep into the code, I end up breaking a whole lot… it took forever to fix what I broke, but it works.
We’re now able to create Programs that incorporate responses to various events that ROVer will relay to the Command Center. For example, we can now have ROVer respond differently to an obstacle at his forward-left sensor depending on whether we were having him drive forward or whether he was executing a turn, etc… that sort of flexibility will mean a huge amount of capability later.
More than you ever wanted to know about sensor data! :p
Wether we’re talking the speed and distance readings from the primary motor encoders or the proximity values from any of ROVer’s 5 (so far) distance sensors, getting reliable data has proven a bit challenging. The problem stems from the fact that we’re requesting those values many times each second and once in a while, we get a bad reading. That one bad reading, however, can through a serious wrench in the works when it comes to obstacle avoidance and/or navigation.
I think I’ve found a solution (code sample below, of course 🙂 that will bump-out the anomalies and keep the “good” values so that we can get averages that make sense.
The next step is to plan for contextual events via programs…
Today isn’t a particular sexy 1sts day, like yesterday, but we did get some important items checked-off the to-do list.
First, we FINALLY got ROVer’s four motors synchronized using the PID coefficients used by the RoboClaw motor controllers. This is something that I’ve struggled with – to almost an embarrassing extent. I used to be good at math, or at least I thought I was, but this PID-stuff seemed to mystify me.
We’ve got ROVer’s shinny new 24v Turbo Charger all wired-up and ready to go as well as a bunch of the Autonomous Programming that I’ve been working on over the past few days. It’s been a whole 3 days without a video update (my apologies!), but there’s just been so much debugging to do that I didn’t think you guys would be all that interested :p
Fortunately, SOME of the bugs have been squashed and we’re ready to try out ROVer’s new hardware & software.