One step closer…
This thing screams with wall wart power. Watch…
Now comes the hard part…choosing a decent battery and mounting the circuit board savely on the chasis. I have found a few good candidates, but they are a little bulky for my application. Still looking…
The UI should be fairly straight forward. Just need a few more garage sessions, and I’ll be good to go.
The cordless Dremel was a super purchase FWIW. One of the best tools I’ve used.
These rims are hotter than the combination cutting and grinding bit on my new cordless Dremel (after I’ve been cutting and grinding servo fittings with which to secure the rims in question.)
For a project that is being tackled in five-minute-sleeping-baby sessions, it is shaping up. I am not quite sure if the IOIO board will fit in the enclosure, but it will sure be close. I suppose if all else fails, I can chop the thing up a bit…as much as I enjoy Dremel-ing, I’d like to avoid that if possible. Maybe next five minute session…
My off-the-cuff remark about building an auxiliary bilirubin light manifested itself into a quick project.
In order to approximate the specific color of the bilirubin lamp, I figured that I would need to provide a means of setting PWM values for the three inputs. I had hard-coded values in Arduino code in the past, so thought about taking that route initially. I blew the dust off my Duemillova, fired up the Arduino IDE, and promptly decided to modify my Java servo PWM code to do the job.
Sort of growing attached to the IOIO…sorry Arduino.
So, the controller was born…IOIORBG.
Hit the bump for a video and some more info…
Continue reading “RBG LED Controller”
Consider this the conclusion of the IOIO DC motor experiment until further notice…
I’m chalking this up as a success. Even though it is ugly and raw, I learned a ton mashing this thing together. Very fulfilling project from a nerd standpoint: I learned more Java, had to buckle down and do a little EE, kicked up the soldering skills a notch, and introduced a few more components’ features into my ghetto skill set.
My code is live on github with a preemptive v1.0 push…
I also dumped the apk to the Android Market as promised.
Pins 21 though 26, wired through the usual candidates on an H-Bridge. Contact me with any details…it should be very spec sheet-heavy though. The main stumbling point is with the power source, so keep that on the front burner.
Cheers. This may be my last time intensive project for some time. Hardware is time-costly…I am planning to take on the software project I have been contemplating between diaper changes and feedings. Look for some dad stuff in the mean time…
The motorized orange thing project is a wrap. Well, as wrapped as it will be for the time being…Katie is full term, so we are working on borrowed time. I managed to introduce remote control to the orange thing via Android and my IOIO board.
I found a goofy motorized alarm clock, Clocky, on Woot a while ago. My first thought was something along the lines of ‘that looks like a great thing to tear apart.’ The unit is designed to make a lot of noise, and drop off the nightstand when the alarm is triggered…key features are its ‘ruggedness’ and two-wheel design. Pretty slick platform for horsing around with my IOIO.
Once it arrived, I began ripping it apart:
My focus points were fairly straight forward…keep the drive train system intact, and gain control of the motor function. The stock power was via four AAA batteries, so I did some testing with my 3.3V outputs on the IOIO:
My 3.3V connections really made the unit crank. The on-board DC motors were fairly snappy…looked promising. I broke out the leads from the battery holder as well, figuring that I *may be able to drive the IOIO with the 6V. That is when thing got sort of dicey…I could run over a hard connection, but the current needs of the board / bluetooth setup was too great for this application.
I determined that I would need to introduce some technology, which ramped up the complexity of the build by a bit. Luckily, I had a Adafruit MotorSheild collecting dust on my bench. I scrapped one of the H-Bridge chips, and mounted it on a simple test board:
This approach worked. DC motors are power thirsty little bastards…keeping my power sources isolated was the key to getting everything running w/o issues. Basic setup became this mess:
Zip ties, electrical tape, Altoids tin, some swearing, etc. later…
…weird orange thing is ready to roll. Check the video:
Down the road, I would like to turn orange thing into a mobile mount for the phone itself. The end-goal of this whole bizarre project would be to have a web-controlled vehicle with on-board video streaming. I need to do some research and figure out how to mash around the video feed…going to have to step the Java game up a few notches. That takes time, and spare time is not abundant…it could happen though.
I will dump this code on GitHub and throw the apk on the Android Market. Stay tuned.
I aspire to clean this mess up.
I have an app tossed together that provides my six digi-outs. I just need to spend some time welding my soldering iron, and figure out how to mound this stuff on the platform. Expect a video post Sunday.
I thought I could get away with utilizing the onboard 6V from my cannibalized motion platform…aka the orange thing…in order to power both the DC motors and my IOIO. My bluetooth connection was cutting out…indicating that I needed to introduce a separate power source for the board and for the motors.
My workaround didn’t pan out…time to rethink the build. Guess what I have on my desk:
Adafruit Motor Shield for the Arduino. Two good looking H-Bridges staring at me….that’ll do. I never thought I would find myself treating my Arduino gear as a scrapheap, but the day has come.
The H-Bridge will allow me to cross over (think of a capitol H) and provide bi-directional motion from the hardware level. 3.3V digital outputs…no more open drain needed (bonus.)
Anyhow, I ended up putting together a little test board…socket, some male pins, and eventually some wires for a more secure connection. Sucking some serious soldering fumes…
It looks sloppy, but here is the hardware in its entirety:
Here is a quick video of my testing. I fired up my IOIOSeek program, which has two simple digital outputs triggered via buttons…
Early success? Yep. Except for the early part…this has been more work than I had assumed. More EE work…hoping the UI and hardware containment goes smoothly. Tune back in.
The project is wrapped. I have fully shown servo control via bluetooth, via Android, via IOIO. +3 via
The easiest way to test this, by far, is to snag the app on the Android Market. Here:
This does require a newer version of the IOIO bootloader than is currently shipping from units at Sparkfun, but details can be tracked down at this Google Groups area on how to update. It will work standardly, with a USB cable.
From there, you can take a look at my code on GitHub.
I haven’t included the IOIO libraries, but that will be part of the Eclipse setup if you decide to start hammering out some code. I can provide some guidance if anyone is in need of any.
Take a look. I bumped the SDK minimum again, in order to ensure that this function is intact. If this causes any hardship, I can relax the requirement.
Anyhow, take a look at the app in action in the previous post. Cheers.
I’m preparing to publish a project utilizing the new bluetooth library for the IOIO. I started horsing around with my IOIO Servo Controller application, and finally got frustrated with the lag that was existing between my slider bar and the servo. I never pulled my improved function from my IOIOSeek work over…it was overdo.
Anyhow, I sort of cleaned house and put together an improved interface, and pushed it to github.
Here is a quick vid of the new app in action:
I pushed a new apk to the Android Market as well. If you have it installed, it should update in the morning. Here is a sneak peek of the updates:
*Optimized code to alleviate lag between slider bar and servo positions.
*Increased minimum version requirements, for future bluetooth connectivity
*Added function to keep slider in an inactive state until IOIO connection made
*Cleaned up code to remedy force close situations
*Remapped PWM pin from 5 to 10 for consistency with my other apps
*Removed text field of slider position / on board LED
*Simplified layout for smaller screens
I pulled some function, but am more than willing to reintroduce the relative readout and/or on-board LED display. I am trying to go simple with this one, and ramp it up once I can figure out the lag that the bluetooth connection will introduce.
Well, I made some progress this weekend with respect to hardware, firmware, and bootloaders. My bluetooth IOIO implementation is still giving Eclipse shit-fits. I am seeing an error with the bluetooth library…it fails on compilation. Unfortunitely, I am running out of weekend, so will cut this one short and make a statement about the backend.
In order to replace that pesky USB cord with a sleek virtual cord, aka a bluetooth connection, one must update not only the IOIO application, but also the IOIO bootloader. The application is easy enough to flash, but he bootloader requires a programmer for updating. Luckily, Ytai was kind enough to design a ‘programmer by second board’ option, and incorporate that into the same UI as he utilized for flashing apps to the board. The first step was off to SparkFun for a second IOIO.
I kept the second bare bones, except for the pins I would need to do the actual programming.
The key was to have both boards up to date enough to function as programmer and target, so I first loaded the newest application versions to each board. The rest was a matter of utilizing the IOIO Manager app on the Android, and letting the programmer do its thing.
For reference, the setup was power to power, ground to ground, pins 37|38 to pins 37|38, and pin 36 to mclr…with mclr being on the target board. USB connected to the programmer board…that is that.
Unfortunately, my IOIOSeek app ended up stroking out when I attempted to load the bluetooth library. It works fine with the newest general library version, so I know that my bootloader indeed was a success. Back to the Java drawing board before I can demonstrate the new feature.
