Project Logs

Collapse

• An update

  Cruz Monrreal II • 08/21/2014 at 02:40 • 0 comments

  While the Instructable is still being worked on (can't waite say when it'll be ready), I do have some other updates to share.

  As per The Hackaday Prize requirements, I've made and uploaded a system diagram for the project. After working on it, I was quite surprised to find how complicated the system was, with there not being much for me to simplify, unfortunately.

  In any case, I'll be uploading some videos (including the only "run" I was able to make at the Sparkfun AVC 2014) to show that this does actually work.

  Until next time!

• Backlog: Sometimes headbutting the table just isn't enough

  Cruz Monrreal II • 07/12/2014 at 04:02 • 0 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 :)

• Backlog: Sparkfun AVC, you were short, but fun

  Cruz Monrreal II • 07/12/2014 at 03:38 • 0 comments

  MASSIVE UPDATE WARNING!

  Oh, man. What a day. I'm already on my way back to Austin, having slept 12 hours last night (staying awake for ~30 hours will do that to ya), and sore due to a nice morning hike to one of the many summits in Colorado. Let me tell you, stuff went down.

  During the competition, I did have some victories, but experienced even more defeats. The last issue that I mentioned having was that I was not able to go straight, so I'll start with that. My plan of attack for the day was to be able to go straight for long enough to make the first corner. In order to do that, I needed to be able to go straight for some time, then turn left, never mind the fact that the pavement that we would all start at had something like 20 degree grade -into- some curbs.

  Anyways, after looking at and messing with the raw values that I was able to get from the IMU, I decided that i could get away with simply sampling the Gyro at 1KHz, and using that to tell the rudders which direction to turn. Plan of attack was decided, code was written, and tested. And it worked! Mostly. After I started testing, I found a condition where if I reset the MCU while a transfer was occurring, I would need to cycle power, until the part was responding to commands again. Something I need to look into later...

  But when it worked, it worked wonderfully! The rudders would correct for the direction that I would rotate the Hovercraft, and fairly quick I would say. Then another problem arose. If I were moving the Hovercraft while it was fetching the first reading, it would noticeably drift at a rate of a few degrees per second. This was no bueno. To counteract this, I made part of my startup routine take samples while the Hovercraft was at rest, and use that as the resting state for the Gyro. Calibration might have corrected for this, but I simply didn't have the time. In any case, this was able to work well enough.

  Alright, so now I have a possible method for going straight. Awesome! Time to start sending commands again. What's that? All of a sudden you're not taking them anymore? Not cool.

  Sure enough, as soon as I got the stabilization code functioning, the part of the code that would receive and parse commands stopped working. If it's not one thing, it's another... An hour or two pass by, and I'm checking over all of my new code, everything looks good, and then I see it. Two hours lost because of a single character. You think I would have lost it by now, being sleep deprived and stressed, but this is something I've actually gotten use to, having worked with Embedded Systems for years now. What was happening was that because I wasn't clearing the Timer Interrupt, I got stuck in an infinite loop that would starve the main program whose only task is to parse commands.

  Alright! So now with that out of the way, it was smooth sailing! ...right. I was able to get a few tests in that showed, for the first time, that the concept could work. I could start the hovercraft. It would hover on asphalt like it were smooth. It could lock on to a bearing and follow it as best it could. But it couldn't lock on well, and the control algorithm was primitive, and needed much more work. Evert time I tested it, it would over oscillate, correct for it, then swing even more. Frankly, it spent more time rotating and correcting for itself than actually moving forward.

  But this was moot point, because by this time, one of the three heats had already come and gone, which I had to miss out on. At this point in time, I had the chance to at least show off what I had been working on for months, and I took it.

  It performed as well as I thought it would, and took over a minute to actually get going due to the flakiness of the IMU startup code. Unfortunately, this was the only run in which the Hovercraft actually moved forward on it's own. It was exciting to watch, problems and all, but was still frustrating. It only made it halfway to the first turn before getting stuck in the curb due to the slant in the...

  Read more »

• Backlog: Android, you have failed me

  Cruz Monrreal II • 07/12/2014 at 02:18 • 0 comments

  Ok, not really, but I'm still in a hole. It's late Friday night/early Saturday morning, with only a few hours before the competition, and I've achieved some workable results with Android.

  First up, 3D orientation. While it seems that the world and APIs for accessing the 3D orientation of the phone have gotten better, tests are still not what I'd like them to be. Depending on the method, I either get lots of noise, lots of drift, or really slow response time. This just won't do. Looks like I'll be doing things manually with the IMU on the Robotics BoosterPack. I would have liked to avoid this if at all possible.

  Second, GPS. I did not expect that the GPS would need Google APIs to use, but it did. Spent some time getting that figured out, which wasn't all that hard. Once I got that going, I was actually able to get decent accuracy most of the time (~4m). Now, I don't know whether this is a radius or diameter, but at this point, I'll take what I can get.

  Third, game logic (aka, the interface between the Smartphone and BoosterPack). This is one of the reasons why I wanted to put myself through the headache of using a smartphone to begin with. With embedded systems, every time you make a change, you need to recompile the entire program and hope that the change you made doesn't completely bork everything. I would MUCH rather have my lower level controller take care of generating the signals needed to control my electronics, while having something at a higher level to control the objects on the actual Hovercraft. To summarize, I got this working and abstracted away the commands well enough that I'll be able to easily make changes as I need.

  Fourth, the UI. This might not sound like much, but this was a huge plus for me. The ability to program in a high level language to a device that already has a well defined method for interacting with a display was a huge plus in my book. In addition to using the touchscreen as the Start/Stop button for the Hovercraft, I also used it as a debug screen to print out strings of debug text. Definitely superior to LEDs.

  Despite how much progress I've made (and the fact that I proved that I can still pull all-nighters when I want), there's still a few fundamental things I need to figure out, the most important being that I STILL CAN'T GO STRAIGHT! This in and of itself is going to be a deal breaker if I can't figure it out. I'm not all that optimistic about this, since I haven't really gotten much *good* time logged with the IMU on the BoosterPack, but I'll need to make due.

  At this point, I'm not optimistic about finishing the course. Something as basic as driving straight still isn't figured out, and frankly, I'd be ecstatic if I even cleared the first corner.

• Backlog: Testing... Crap, there's slopes

  Cruz Monrreal II • 07/12/2014 at 01:51 • 0 comments

  Good news and bad news.

  Good news: Colorado is just as beautiful as I remember it.

  Bad news: It's as hot as Austin, and the asphalt is slanted.

  One of the things I wish I had completed before getting to Colorado was some sort of working vectored control. I wanted to be able to tell the controller "hey, I want to go in this direction, at this speed", and it would be all like "boom. DONE!", minus the explody part.

  Sadly, I was not able to get that to work. The goal was to use a feature in the IMU that I'm using to do all of the 3D Orientation calculations, and only periodically pull that value and do stuff accordingly. For reasons unbeknownst to me, this black magic is still black magic, and has left me grasping for straws.

  Since one of the project's main goals was to learn Android programming, I'm going to give the smartphone's motion sensors another try. A few years ago, I tried using the sensors to stabilize a robot, but found that they simply weren't good enough. I'm hoping/expecting that they've changed/improved since then. I'll also be looking at figuring out the GPS.

  I also managed to find a hardware issue, which while minor and completely fixable, still annoys me that I have to fix it. Oh well. So it turns out that the double-sided tape that I was using to bind all of the rudder parts together will not do. It breaks apart too easily during heavy usage to be reliable.

  So for the time being, I'm going to use more paperclips! I decided to poke two paperclips through the entire rudder structure, and bend each end of the paperclip 90 degrees to keep it in place. What has resulted is a rudder that's much more stronger, and feels like it'll be able to take some punishment, and then some.

  I have a long night ahead of me.

• Backlog: Tight on time

  Cruz Monrreal II • 07/12/2014 at 01:38 • 0 comments

  Due to recent events, I'm tight on time. The software's nowhere near done, the firmware is buggy, but at least the second Hovercraft is complete, with plenty of spare parts if I should need them.

  I'll be flying out tomorrow, with all of my electronics and cardboard. I'm still worried about flying with LiPo batteries, but I think as long as the leads are taped with electrical tape and the batteries are in their own box, I should be fine (or so I read).

  I'll be flying out there a day early for personal reasons, but will be on the actual field practicing on Friday as soon as I can.

  It's going to be a long weekend.

• Backlog: Making due.

  Cruz Monrreal II • 07/12/2014 at 01:37 • 0 comments

  <Note: I thought long and hard about including this backlog, since it was an incredibly personal event. For the sake of completeness, I've decided to include it, since it did have a heavy effect on the project, among other things>

  A few days have passed. I've helped everyone around me as much as I feel like I can. At this point, I feel like letting time take its course is the only thing left to do, which brings me back to this project.

  It doesn't feel right. It's not going to feel right. But this is something I can make do with. This is something I can deal with. This is something I need to do. I've put in too much time and effort to simply stop. I'm too close. The only thing that will change if I don't continue is the sense of guilt.

  I don't want to be left wondering "what if", which is why I'm going to press on with the last remaining days before the AVC, and get as much as I can done.

  If someone needs me, I'll drop this in a heartbeat. People are much more important. I'll press on.

• Backlog: Life is hard.

  Cruz Monrreal II • 07/12/2014 at 01:36 • 0 comments

  <Note: I thought long and hard about including this backlog, since it was an incredibly personal event. For the sake of completeness, I've decided to include it, since it did have a heavy effect on the project, among other things>

  This will be brief. A close friend of mine has suddenly pass away. Even though the AVC is a week away, this project and the competition are the last things on my mind.

  I've lost all motivation to work on the project, and even if I do get it back, it just doesn't feel right to continue working on it, so close to such a heavy event.

  I'll leave it up to future me to figure out what I'm going to do, but right now, present me is going to focus on helping those that I can, and simply getting through the daily motions of life.

• Backlog: CARDBOARD IS AMAZING!

  Cruz Monrreal II • 07/08/2014 at 05:04 • 0 comments

  Wow. I didn't actually expect this to work nearly as well as it has. Apparently cardboard + paperclips + solder + servo = working rudders!

  So here's the thing. For the longest time, I had wanted to make rudders for the hovercraft. The problem with this is that this would introduce a custom mechanical component to the design that would require replacement if it failed (trying to keep the design as simple and straightforward as possible; KISS). Unfortunately, I've reached the point where I'm short on time and I don't think I'll have the time to get the EDF thrust non-linearity issue (from way back) sorted out in time. I would much rather be able to set a speed for both EDFs, and simply interact with the rudder angle, getting rid of a variable from the control problem (two EDFs vs one servo).

  So now that that was decided, it's time to figure out how to make one, without much time left. Because this part would be under constant actuation, I needed to make sure it would hold up, make sure it would be sturdy, but also needed it to be cheap and easy to duplicate. It's the trifecta problem: cheap, fast, good. Pick two.

  This is where an old problem became a most WONDERFUL solution. Early in the project when I started using cardboard, I noted that its main issue was its perforation. There was no way for me to create an air chamber to use for hovering, without closing off the perforations with tape, due to the way I was constructing the hovercraft. The rudder design I was able to come up with, actually takes advantage of these perforations for structural support.

  But what about the actuation? This was some cleverness on my part that I learned about a couple of months back when I was using cardboard for a different project. It turns out, that it's really easy to make cardboard bend to whatever angle you want it to with a metal ruler and a mallet. This same "technique" I used to make the cardboard flaps, which also happen to be part of the support structure itself. Awesome.

  Ok, last step. I now have structurally sound rudders, I have flaps that I can now move freely, now I just need to figure out how to move them together. In comes paperclips and the soldering iron.

  A few years ago (junior year of high school if I recall), for some reason, I set out to solder together paperclips. I don't know why, but I just did. I remember it working well enough that I stashed it away in the back of my head as another "technique", to be used again when needed. Fast forward to now, and my soldering skills have only gotten better.

  With the paper clips in hand, I bent four pieces 90 degrees, pushed them into the flaps, about 1/2" from the end, and pushed them in as parallel to the end as I could. They punctured the top of the flaps, I soldered them together, and made another small piece that freely rotated in the servo horn, until it was soldered as well. And wouldn't you know it, it works! I might add some hot glue or tape to the paper clips poking through the top of the hovercraft just to make sure they don't sag down and drag on the battery.

  Not bad if I do say so myself!

• Backlog: I [almost] fits in a box.

  Cruz Monrreal II • 07/08/2014 at 04:34 • 0 comments

  I don't think I've mentioned this yet; I'm making two hovercrafts.

  As it turns out, this hovercraft qualifies as both small AND unusual. I cleared it with Sparkfun peeps, and they said that as long as I have completely individual robots, the same design can compete in different classes! Of course, this means that I need to actually fit inside of the dimensions.

  I threw together a plywood box with the inner dimensions being the same as the criteria for the Micro/PBR class (4"x6"x10"). So far, it looks like the design is a -tad- bit too tall, but I'll be able to make some tweaks to the design to make it fit in the dimensions.

  It's also worth noting that I'm going to try and add rudders to the design. With the thrust EDFs, I'll have to go back to having them parallel, which won't make controlling them any easier. Out of all of the hovercrafts that I see when researching them, nearly all of them have rudders, which tells me that they might be able to solve my control issues.

View all 25 project logs