Close

Backlog: Sometimes headbutting the table just isn't enough

A project log for Cardboard Hovercraft Robot

Answering the question: Why aren't there more robotic hovercrafts?

cruz-monrreal-iiCruz Monrreal II 07/12/2014 at 04:020 Comments

So I've started taking much more pictures of the creation of a hovercraft so that I can make an Instructable out of it, but that's not what this post is about. This post is about how I can make the dumbest mistakes, and it's a miracle that I know what I'm doing at all.

The remaining firmware issues that I've had are as follows: IMU lockup, IMU full functionality, and the random, but apparently necessary printfs. Over the past couple of days, after taking a good week's rest from the project, I've managed to fix two of the three issues that are holding me back from publishing the code.

The first issue I was able to fix was the IMU lockup. This one actually wasn't that bad to fix. What was happening was that if I reset the MCU at the wrong time, then the IMU would not respond until I did a power cycle of the entire system. I found this to be really odd until a certain day at work. I was helping out a customer that wanted some code to recover the I2C peripheral if it was in a locked up state, and it dawned on me that this was possibly the exact same thing that was happening on my system. Sure enough, once I added some code to detect and manually send clock pulses onto the bus, the issue was fixed! That wasn't so bad.

The second issue that I fixed, and feel _really_ dumb for was the printf issue. Since the code isn't available right now, an explanation of what I was doing is needed. Whenever I would get a character incoming from Bluetooth, I would immediately jump into a routine that would put this character into a buffer, and increment a pointer to the next free space in the buffer. In the main routine, I had two pointers that I was using to delimit the start and end of a command. Most of the time, I was constantly doing a comparison between the pointer that points to the end of the command, and the end of the buffer. Whenever a new character came in, these two values would be different, at which time I would look at the new character to see if it was the end of a command, and would respond accordingly. My issue, which now that I look back at it, I want to bang my head on the table, was that the FIRST thing that I would do was increment the pointer of the end of the command. This worked with the printf, provided that it took a sufficient amount of time, because while the program was in the printf, another interrupt would fire, putting another character in the buffer, and since I would populate the buffer faster than going through all of the characters, at worst I would miss a command or two. The reason that this code would not work without the printf was because as soon as there was a new character, and I would increment the command pointer, I would be pointing to EMPTY SPACE. Simply moving the increment pointer to the end of the loop fixed everything. Sigh...

As for the full IMU functionality, I still don't have this working. At this point, I'm done trying to port over the I2Cdev libraries and function calls, and would rather give the official SDK/API from the manufacturer a shot. I'll have to get to that another time though. I'd like to upload what I have before undertaking that endeavor since I'm getting close to starting a different project.

I also think that writing the Instructable is more important at this time :)

Discussions