Well, this will be a quick little post, mostly for a location to drop some files. I made another Ben Heck Show appearance, this brings me up to 3. The video can be seen ehre
It was a cool experience as it always is. Some guys from Engadget were there to film as well and it was cool to talk with them. Also Ben and I got in an abbreviation contest which was fun. VHDL stands for VHSIC Hardware Description Language, with VHSIC standing for Very High Speed Integrated Circuit. That is the coolest one I know.
Anyways, a few people have asked for the code and such so I will embed it at the bottom. I have the Android code and the TI Launchpad firmware code, both in separate zips. The Android code was written for either Jellybean or ICS, don’t remember which, and that was for the rotate command, like the pot stir app. The APK is in the zip file. I didn’t take the time to really document as I’ve been a busy guy. Hopefully I’ll get to do a life update and an update on my ShapeOko CNC machine shortly.
Next week is my Wife’s birthday. She loves Minecraft so I decided to get her 3D printed versions of our Minecraft characters from Minetoys. Minetoys uses Shapeways as their “factory”. Shapeways 3D prints parts via several methods, these use printing a binder (glue) onto powder, then put more powder, print more binder, more powder, etc. See more info here.
The parts came in today, see below
My character looks a bit like Cthulhu (looks better in the game with extending tentacle head) and hers was a diamond block based character. The back of my character is wings
She was very excited and loved them. As I have been looking into these technologies, I was kind of bothered by the mistakes on the right arms of the characters. Mine has a big blob of material and hers has a divot in it. I am not sure if this is the best quality powder-binder printing can do, or if it was a just a bad print. Either way, it was an experience as my first ordered print and I’m pretty satisfied overall.
Skin files
Colecago
Kiloari
Took a bit of reverse engineering to get these. To see any player’s Minecraft Skin, use the following format
http://minecraft.net/skin/username.png
ex
http://minecraft.net/skin/Colecago.png
Stay tuned for 3D printing and CNC update/preview!
I’ve done this little “hack” twice now and figured others would benefit from it as well.
Have you ever noticed your phone/tablet charges slower from USB than from the wall socket? Many of these devices have a USB charging mode and an AC charging mode. This is because USB has a limit to what current it can supply unless the device negotiates with the port for more current.
USB car chargers can usually supply more current than the standard USB charging level, but if your device thinks its charging from USB instead of from an AC adapter it will only charge at the lower rate. So how do you trick it into thinking its hooked to an AC adapter?
Well, that’s pretty easy. For most mobile devices nowadays, short the USB Data- and Data+ pins together. Apple has their own methods using specific voltage levels on those pins. For an example for an iOS device, see Ben Heck’s Universal Wall Wart episode
First, here is my charger, it is manufactured by Rosewill, I bought it from Newegg
There are two USB ports and the charger says it supports up to 1A total
I took the charger a part and this is what was inside
It is a basic switching circuit, probably a buck topology as your car battery is always (hopefully) going to be higher than your USB voltage. A fuse was contained on the front end. More info about buck converters here
What I’m interested in is the bottom of the board, where the USB connector is soldered
I shorted the Data+ and Data- pins together as you can see above. I also tried removing the resistors near the pins but they are glued to the board. I think those are the resistors for iOS devices I mentioned earlier. After looking at them, I can see their values are high, about a 52k equivalent resistance across the 5V and GND lines, meaning very minimal current draw because of them, so I can leave them in.
I tested the device before and after, and before I achieved about 200mA of charging current. Afterwards, I achieved 400-500mA. I’m guessing each channel can do a maximum of 500mA to get the 1A total. I also checked the voltage level it was supplying. Many of these cheaper chargers are super noisy, here is a scope picture
Pretty good clean signal. Also, I should take a scope picture class so I remember to actually have some useful info on the right side of the scope and not the display controls
I’ve done this once before with similar results. It’s a great way to get more out of your USB car chargers, especially if your phone is a battery hog like my Galaxy Nexus, that before could drain the battery while charging if using navigation. Now I can at least break even, and maybe even get a charge.
I went to Ben’s to get a PS3 controller to assist him with a controller mod and he mentioned working on an upcoming Android episode. I told him I had a little experience with Android and bluetooth control and I offered my assistance. He came up with an idea of making a remote pot stirrer so you can stir and monitor your cooking from another room. We talked throughout the week about the basic look and he gave me some graphics to use.
As I was busy most of the week, I ended up doing the program Friday night. I had some sample code from my other apps, but strange Android errors still made it take me until 3AM before I finished a working product. I had weird layout issues, it seemed to be something to do with the main.xml file. I would move something and I’d get casting errors that crashed the program when it ran on the phone. I’d delete a few objects and re-add them, doing nothing in the java code, and the problem would go away. The biggest offender was the image button. I could not line the device id textview up with it otherwise I’d get one of those crashes. When doing the layout xml’s, I made it specifically for my phone, which included editing some of the graphics. I figured I’d port the program to Ben’s nook or phone the next day.
I showed up on Saturday for taping. Ben had the hardware for the stirrer complete. It was an arm on a stand that moved a spoon back and forth using continuous rotation servos and limit switches. As we had discussed the protocol over email, the firmware was pre-coded and working from a terminal. I also had my app working with a terminal.
Despite having both of our devices working separately, getting them to work together didn’t work straight out of the box. First, our baudrate on the Arduino was incorrect. We were using the Roving Networks RN41 module and those modules default at 115,200 which I forgot. After we figured that out, we had to get our continuous rotation servo working correctly. We simplified our code to just send exactly what the android phone sends, to the arm via pwm, so 0-180 with 90 being stop. This fixed that issue. And of course whenever you have an issue, you ended up “fixing” everything else until you find the real problem and have to go “unfix” what you had changed.
When trying to get this ported to the nook, I had problems. First of all, I needed to find usb dev drivers for the nook, not too bad. Then the version of Android I developed for 4.03 or Ice Cream Sandwich, was too new for the nook. I revered the project to 2.3, or Gingerbread, but then I had to take out the rotates as Gingerbread didn’t support the imagview.rotate command. I also had to change the layout a lot to get things to line up. I had edited Ben’s files to work on my phone and I had to edit them back to what he originally made.
Once I got it installed, I tried to get the bluetooth working. It would not, the nook, no matter what I did, would talk to the module. It couldn’t even pair. It would fail and give an error. Without even a successful pair, it was dead in the water.
Next, I tried Ben’s phone. This was harder, the drivers were not readily available to connect for development. I had to put his phone into recovery mode first, which windows then took over and installed the drivers. The phone took forever to reboot and I was worried I had broke it as I had to take out the battery to get it to leave recovery mode. It finally did boot though.
I tried to send the apk to the phone through eclipse. It didn’t work. No matter what I did, it couldn’t see his device as a target even with USB debugging enabled. I ended up having to put his phone into mass storage mode and dropping the apk on there. I got it installed on the phone and gave it a try. It would pair to the Roving Networks module, but would never connect. I’m not sure if it supports SPP or Serial Port Profile, which is a Bluetooth mode, kind of like HID or audio protocol. In the end I had to use my phone. We had to fix a few code problems on the receiver side and then we were up and running, except for the thermistor. We only worked half a day so Ben said he’d add the thermistor code that night and I would port the program back to my phone and re-add the rotate command for ICS.
I came in on Sunday for a few hours to finish up. Ben added the thermistor code and we started getting some sending errors back to the phone. We removed the old sending code, which sent the speed value received as a temp, it was a debugging tool of ours and no longer needed, and then it appeared to work on the terminal. I was still getting erratic behavior on the device when I plugged into Ben’s universal wall wart. I thought the previous day we had used a 5V supply, but apparently we must have used the 12V line to power the Arduino board. With the drop caused by the regulator, the Arduino wasn’t getting enough power to work correctly. After that fix, everything was working great. We finished taping the function and that was that. Not without problems, but definitely not as hectic as Robot Luggage.
Program Information:
I wrote this program based on some samples of previous programs I’ve written for Bluetooth Control. Much of the Bluetooth code was used and Adapted from the book “Programming Android”.
AboutInfoActivity- This file is all about showing the “About” section when you hit the options key. It just shows information I put in the about.xml file explaining the protocol
DeviceListActivity- This pertains to choosing a bluetooth device. After you hit the sync button, a screen comes up letting you connect to a bluetooth device.
BtHelperHandler and BtSPPHelper- These are the bluetooth control classes. They are pretty much exactly from “Programming Android” except I had to add some code to allow me to receive data. These codes I believe were adapted from the bluetooth chat example on Google’s code database.
BenSturActivity- This is the main activity. It is what you interface with for the program. It controls the other activities, uses the bluetooth, reads the seekbar and button inputs, and sends the bluetooth information every 250mS by use of a thread. You sync with a device and it will show the Device ID, you know its connected when the temperature changes from — to a number. Then you slide your finger back and forth on the slider in the upper right to move the arm. Releasing puts the position back to 90, or off. That’s about it.
Protocol- Its a pretty simple protocol with everything sent in Ascii. I did this because I was having trouble getting useful Byte data from the bluetooth helper classes but strings worked fine.
Sending- Start character – Three digits of position, always 3 digits, padded with 0′s when neccessary
ex- !090 (stop) !180 (full CW) !000 (full CCW)
Receving- Start character – One to Three digits of temperature, does not need to be 0 stuffed
ex- !99 !120
Known Issues- When coming back from a screen off condition (like a sleep), the program often crashes from an inflater error. Something about unknown class. I’ll see if I can fix it, but I’m not an Android nor Java king. If anyone else looks at this code and fixes it, let me know so I can update it.
Older Support- Because of the ImageView.rotate command, this is ICS and above only. Remove the ImageView rotation command and then configure the project for an older version of Android to work on older phones. Also remember to update the Minimum Version in the Android Manifest !
I figured I would write a better Buildhealth wrapup than just the videos I posted.
First of all, I have a playlist for the Buildhealth videos, see them here
Planning:
I heard about the Buildathon from Sector67′s Google Group. I talked to some friends about forming a team. A few weeks prior I was thinking about not going, then Meg re-insisted I should go after the April 3rd Sector67 meeting where Mark brought up the Buildathon. I talked to my team, they were still on and we signed up for some Google + chats to discuss ideas. I knew from the beginning I wanted to do hardware, but not sure what yet. We had a Google + hangout later that week to discuss. I had an idea about making a rumble belt for deaf people that took in several audio inputs on a necklace or collar type of device and rumbled with the intensity, frequency, and direction of the sound. I still think this is a great idea, but it doesn’t really fit healthcare. I forgot all about the Google + hangout on Monday to discuss and apparently everyone else did too. I recapped with them later in the week and because of conflicts, all of my teammates dropped out (had 2 guaranteed, 1 never heard from, and 1 possible). I was considering not going, and then I decided I should go even if I couldn’t build hardware just to support another team. On Thursday night I had this great idea of a UV System to kill germs. I told my team I was still going and started making preparations and getting supplies. I borrowed a Roomba and some random parts from Sector67. Then I got some messages from Steve saying he was back in. We planned on and off the rest of the day for our ideas and packed that night to leave.
Arrival:
We arrived at 9am and parked the car. Tim introduced himself to us and then showed us the upstairs where we could put our stuff. Steve and I moved a table into our empty room and then unloaded my car into the room. I had a lot of hardware supplies and tools. After unpacking we ate some breakfast and sat at a table with fellow buildathoners and talked a little bit while we waited for it to start. A little over 40 people showed up, but not all were participants in the challenge.
Introductions:
The buildathon started with some basic introductions of the organizers as well as talking about the space and goals for this event. We broke into small groups and did introductions. Then Tim Bartholow talked about some staggering health care numbers. After the data was gone over, the submitted problems were explained. Some of the people that submitted problems were actually present, so they explained them. As Steve and I had an idea beforehand for a solution, I gave a short description of the problem and solution we wanted to work on. Then everyone broke into groups to discuss the submitted problems. No one joined us at this point and Tim released us to go work on our problem/solution.
Designs and Lunch:
We sat in our rather warm glass room and worked on some designs. I would take care of the Roomba and all involved with that and Steve would do the ceiling unit and the rotating reflector unit. We ate some lunch, then continued designing. A journalist from the Journal Sentinel stopped by and interviewed Steve and I about the buildathon and our idea. After she left, we finished up our shopping list and left to Menards. It was about 2pm at this point.
Menards Trip:
We spent a long time at Menards. First we got the lights, Steve picked out Daylight CFLs as they are bright and produce whiter light than incandescents. We picked up some wire, and then some low voltage halogens for the Roomba. Next we needed hardware for the rotator. Steve found some lazy suzan hardware near the castors and we found some vacuum belts with help from the associates. We also got some wooden dowels, nuts and bolts, and some sliding door handles which were originally going to be used just to trace a circle on our cardboard for the rotator. We picked up some reflective cardboard for the rotator, and got some much needed duct tape and industrial velcro. We made it out of there $80 poorer.
New Member and Dinner:
When we came back, Alex was waiting for us. He wanted to join our team so we explained what we wanted to do. We tasked him with building the ceiling fixture. I hooked the Roomba up to my power supply and turned it on to know what to expect. You have to hit the power button, then hit the clean button. I started taking it a part to hack into it. Around dinner time we had two more people join us, Emily and Jesse, Emily researched current UV technologies and killing pathogens and Jesse helped build the cardboard topper for the lights on the Roomba. I ate some dinner with Chris from Sector67 who stopped by and Tim Bartholow. Then back to work on the Roomba.
Roomba Power:
Alex finished the ceiling unit and Steve was making good progress on the rotating unit. He had a good base but was having trouble getting the belt to connect to the motor properly. We decided to use the two sliding door handles/cups back to back as the pulley for the belt to ride on. Our belts were too small and Menards didn’t have rubber bands (according to associates), so we duct taped them together. I soldered wires on all the Halogen lights, which was pretty difficult as that metal didn’t like to solder, and then gave them to Jesse to put in his topper. I then went to work on the power distribution of the Roomba. I hooked up some wires to the Roomba’s main power, hooked some wires to a perf board and then to the two 7.4V batteries in series and a switch. I powered up the Roomba and it worked fine.
Roomba Logic:
I needed a microcontroller on the Roomba to turn on all the relays, one for each light as they all draw close to an amp each, so four total, and also to act as a person pushing the buttons. I traced out the buttons I needed, added some wires, I planned on sending a 0V signal to initiate the power on and clean sequence as the buttons were connected to ground. For the lights, I tied the high side to the positive rail of the battery and the low side to the relay and the other side of the relay to ground. The relays switch ground to the lights, completing their current path. All 4 relays were switched on using using a single bjt as my micro couldn’t handle the current. I had a lot of trouble getting this working. I had a stable 5V and when I’d switch a relay, my power would die. Mark from Sector came by and asked me how I was doing. I explained my problem, how I switched out the regulator, bypassed the regulator, and I couldn’t figure out why it was failing. He asked about my caps on my regulators. I told him I didn’t have caps on them because I was running off of battery voltage and didn’t care about any ripple, I mean batteries make pretty clean power. I tossed a cap on the regulator and problem solved. Apparently regulators need a minimum capacitance or they go wacky, and not always apparently, because they could handle my micro alone. Well this fixed all my problems, but in the end, I wasted so much time with testing and resoldering connections, I knew I couldn’t implement a wireless link. I instead introduced a 10 second delay or so from switch on, to turning on the lights and Roomba function. I then moved on to the spinning light control.
Rotating Light Logic:
I already had the code down for the delay and relay turn on, I tossed this code on another micro. I found a 19V AC/DC convertor and hooked up another 5V regulator, this time with a cap, to power my micro. I used a BJT to both turn on the AC powered light and another bjt to power the motor. The motor spun really well at 5V so that’s what I used. I then hooked the power supply up to a switch and tied the relay to the lights. When I turned the switch, I waited 10 seconds and both the light and motor would start. This part was done. Steve did a great job getting this one working.
Ceiling Light:
This last light was the easiest. I cut open another power supply as I planned on using another relay. This relay was controlled by an inductive prox, our door sensor. So I would turn the switch on, and then when the sensor sensed metal, it knew the door was shut and would turn the light on. This worked pretty well. Once all three systems were done, we went to bed. I put our overnight videos on youtube and ended up going to bed at 4:30.
Morning Prep:
I woke up at 7:30 to begin our preparations. I cleaned all of my equipment out of our little room and swept the floor and table. I woke the guys up around 8 so we could install our system and work on our presentation. We mounted the ceiling unit using yarn, put the Roomba on the floor, and put our secondary surface cleaner on the table. We did a dry run of our system for our video here:
Alex and Steve had done most of the presentation the night before and this morning. So we finished up the build slides and tried to come up with the intro. Alex and Steve were to present most of the presentation and I just covered some of the build information.
Presentations:
We were the third group to present. As we spent 90% of our time working on hardware, I felt like our research was lacking a bit, we didn’t know our market perfectly, but it went over well. At the end, we took everyone over to our room and showed a demonstration. All in all it went well. All the groups finished their presentations, and all were good. I especially liked Triage.me presentation, even though the presentation part was filled with technical difficulties, the actual content and idea was solid. I really liked the website they put up and the text messaging service. A big thanks to DC414 for helping out Triage.me and their presentation by remote desktopping into the mac and displaying to the projector through their laptop. DC414 definitely were the hackers of the buildathon.
Results:
The judges consulted for a bit while a storm raged for a little bit outside. We lost power for a little bit, so I grabbed the Roomba in case we needed a little roaming light. They came back and presented the winning teams. See the video here:
Reality Check won third place, Triage.me won second place, and we won first place and people’s choice. This also included an invite to DC for the Health Datapalooza. We took a picture with Ken from HHS, talked to the other groups and started packing our things to leave.
Conclusions:
Buildhealth was great. I wasn’t expecting to do so well, and I’m glad I could do hardware. Tim put on a great event and I can’t wait for the next one. I met a lot of great people, from organizers and judges, to participants. I don’t feel our idea was as hardhitting as the other guys, and I hope they were not discouraged to flesh out their ideas into full products. DC is up in the air right now, waiting on word from HHS, this might not be the event for hardware guys such as us We’ll see, it would be a great opportunity. I don’t currently see the light at the end of the tunnel for us starting our own business around this idea, but you never know. This was my first Hackathon, but it won’t be my last.
Update: I’ve added the Teensy code below. Pretty simple because its just a delay. Wish I had gotten time to work on the wireless. I do a lot of serial work so rolling a protocol wouldn’t have been super difficult.
Not only did I put the electrical system together (and some of the mechanical), I also made the controller board and wrote all of the code.
AGV Controller Rev 1:
The first wireless controller was pretty rough. It was a two board design and had sliders to control the front and back actuators. It used gaming joysticks for the control, kind of video game style with one joystick for left/right and one for forward/backward. The sliders have tops on them, I just don’t remember where. I designed the placement in Autocad, then drilled and dremeled the case.
AGV Controller Rev 1 picture
AGV Controller Rev2:
Rev two took parts and ideas from a controller I built for a customer and built this beauty. It was a lot more rugged, had a larger battery, state of charge led’s, and an onboard battery charging unit. It used the large rugged joysticks. One stick was for forward/backward/left/right and the other was to control a conveyor on the top which we had to remove and send to a salesman later. It uses Zigbee (like the last one) to control the AGV. I did design this one as well, but I had a third part do the milling as I had some square holes as well as holes larger than our available holes saw.
AGV Controller Rev 2 picture
The AGV is also bluetooth controlled via an Android App I wrote after going to the Marakana Android school
We to make some motor mount encoders. The idea is to mount directly to the shaft of the backend of the motor and you would ziptie the cord of the encoder to keep it in place. We offered single and quadrature options. We designed a style in solid works, then had a representation of the encoder CNC’d out of metal to assist me in making molds.
Mold Rev 1:
I built mold rev1 from silicone, it was my first time doing something like this. Mold rev 1 was very thick and used screws for keying. I also used some screws or wires for the air and pour holes. It did its job, but not very well. The pour and air holes were too small and not connected very well because they were put in after. Still it got the proof of concept to work, I poured a few sets of encoders, all using polyurethane for their base.
Mold Rev 1 picture
Mold Rev 2:
To fix pour issues from Mold Rev 1, we remade the model to include air and pour lines. This helped me make Mold Rev 2. I used hexagonal spacers for keying. This mold worked very well and I did probably 5-6 pours to get more prototypes ready. The black encoder pictured below was actually poured from this mold. The quality is pretty good. It was one of several polyurethanes I was trying and was my favorite as it still had a slightly soft feel when done and didn’t have too many bubble issues. The Green encoder is one professionally made once we submitted our drawings to an injection molder. We are still in process working out quality issues with them. The last hole shows the circuit board that goes into the mold.
Mold Rev 2 picture with finished and unfinished encoders
SwitchBox
I never have enough reliable switches and potentiometers around. I often have to hunt for working ones and then attach new wires to fit what purpose I was using them for. After being fed up for the last time, I decided to make a multipurpose switchbox.
I designed the box below in Autocad then drilled everything out on a drill press. It features two 2-way toggle switches (upper left and right corners), one three way rotary switch (bottom left), six NO and NC Arcade pushbuttons (center), two 5k potentiometers (left and right sides), and six constant current LED’s which can be given 2.7-30 some VDC. I use LM317′s in constant current configuration for this. Below is the face for the Switch Box.
SwitchBox face picture
The top of the SwitchBox contains all my connections, all wago terminal blocks that you use a screwdriver in the top slot to put in your wire in the bottom hole. These terminal blocks will last a lot longer and hold a lot better than screw terminal blocks. Everything is labeled with marker, which is hard to see, and I made a whole lot of tinned jumper wires to connect to this to save myself time. This box really came in handy when I was designing the logic board for a door opener, which has a ton of inputs to it. But the main goal was to end frustration finding/repairing/putting wires on and getting shocked by my components.
Last Tuesday, Ben, “Doug”, and I gave a talk at Sector67. We basically talked about the process of building robot luggage, how it works, what electronics are in it, and then we showed it off. It was fun, but Doug was misbehaving, I’m thinking either some 2.4Ghz Zigbee noise or 40Khz Ultrasonic noise might have been interfering with him.
A lot of cool projects were shown and the knitting machine did a great rendition of Robot Luggage! A picture of robot luggage was taken unbeknownst to us and the last presentation of the night was the showing off of the knitted blanket! All in all great night, I can’t wait to go next month.
Back in November I won a hat from Ben Heck, I went and picked it up in person and talked to him and his assistant Alyson, they were finishing up the latest episode of the Ben Heck show. See here for more info
During the visit, it was brought up that I might be able to help on a future episode. Well that day came February 4th. The project was robot luggage. We started out by brainstorming over Skype. I had thought about this prior and this is what we decided on:
2 Ultrasonic sensors (receivers) on the luggage, 1 Ultrasonic sensor (transmitter) on the person (the target), 1 Wireless transmitter/receiver on each. The wireless is used to initiate the remote ultrasonic ping on the target. I thought this was the better route than using wireless RSSI on the transceivers for a few reasons;
- We don’t know what frequencies are in use in an airport and don’t want to be interfered with
- Wireless bounces a lot and is strange sometimes how it is affected by humidity, near ground effects, etc
- If not using RSSI and instead using Time of Flight, you’d need a very fast micro to record the distance, Ultrasonic sound travels much slower and its easier to discern a distance
I went to the shop the next day to do the recording. It was a little bit weird being on camera as you can tell I didn’t do the best acting in the beginning. It became easier and more comfortable later on. The recording day was all rehashing the design for the camera. We went over why we chose what parts, the mechanical design of the device, dimensional analysis for the speed and many other things. It was about 4 hours of work for 8 minutes of video.
Our next recording date was several weeks later as we needed to get the parts in. That day consisted of more of the mechanical work and testing out all the electrical components. Ben made a preliminary wheel, we soldered wires to all of our electronics and mounted them and added batteries. I had a lot of trouble working with the motor drives because everything needed to be sent in hex and it’s hard to find a good terminal program in windows7 that lets you do that, had I brought a windows xp computer, I could have used realterm, which is my go to terminal. I ended up using XCTU which is digi’s terminal program, originally meant to configure the xbee chips. It was not supported on win7 but it worked.
Also, a note on UART dyslexia, if you are designing anything with a UART interface, please, please, mark your terminals in some manner like TXOut, RXIn so we know what direction the traffic should be. Most things are marked TX and RX but they don’t indicate if its the TX of that device or the one connecting to it, I’ve seen it both ways on modules that use UART. Here is the best quote I’ve seen on this
Before purchasing this part you need to know if you have a condition called UART dyslexia. This is a neurological disorder that will render you incapable of properly wireing this device no matter how my times you triple check the the wiring. I have this disorder and I have only found three possible solutions:
1) Find someone else without UART dyslexia to wire it up for you
2) When you get the board, immediatly scratch out the silk screen for the TX and RX pins. You will have a better chance attaching the wires at random than attemping to determine the proper connections in your screwed up head. Test the device and if it doesn’t work swap the lines. The advantage of this approach is that you didn’t spend hours trying to figure out the wrong way to wire the connections.
3) Try to figure out the proper connections and do the opposite of what you think is correct. I have had some success with this approach. -MotiveForce sparkfun comment
I got some wheels spinning and we got the wireless generically working, and that was about it for the day. One big comment about the transistor inverter-
Originally I wanted to do a NPN inverter but I wanted the signal pulled low so it was always low if the input was floating, this required me to change to the pnp approach, I switched the arrow, but did not switch the pins of the device. Emitter should have went to VCC and collector to the signal out/pulldown resistor. That is why it did not work. The arrow represents the internal diode (because of PN junctions) of the device and you can think of it as the direction the current will flow, so of course current cannot flow backwards through it and the device didn’t work. That was a fundamental mistake on my part, not much to blame it on but nerves and working on the fly on camera.
I was supposed to come up the next Saturday and Sunday, but I got pretty sick, so I sat alone in my lab all day Saturday working on code
Let me say this, I hate programming for Arduino. It’s a great platform for hobbyists and gets people into electronics and programming. There are a ton of boards out there and quite the following. Most Arduinos are based on AVRs which I use all the time at work. I figured I’d do it as an Arduino this time, and I did not enjoy it. This is how I expected the program to work
Decide to take a reading, send out a serial wireless command to do a ping, count on a uS timer until both left and right ping received, the distance is the turn value
I couldn’t find uS timers, so I tried the next approach
Decide to take a reading, send out a serial wireless command to do a ping, do pulsein to record time for one receiver, repeat for second receiver
This didn’t work as the serial library is so bloated that variable lag was causing my values to be off 50-150uS whereas the difference values I was looking for many times were less than that. I hooked up a scope and the end point of the value was bouncing but not the difference, it must be from inconsistent serial lag to the remote sensor. Basically I had to read them both on the same wireless ping to get accurate results.
Use interrupts, I set both ping sensors on an interrupt so when they changed state, I’d check the second sensor to see if it triggered, detatch the interrupt so it doesn’t happen again before I’m ready and then when I receive the next interrupt that is my distance.
Well, that didn’t work either, I think either the arduino doesn’t like detaching an interrupt within that interrupt or just how long it takes to do a digital read (which I didn’t know yet) was causing grief.
Next try, sit in a loop that’s doing uS delays and counting up (with a timeout) and polling the pins to see when they change (because they received the ping back), then receive that, set some flags so you know which one went first and wait for the second one, then do the difference value etc.
This didn’t work either, I think because digital read takes a very long time (longer than it should). Once I changed it to read directly from the port (PINB & 0xyadayada) that approach worked.
The whole project I was struggling with arduino based problems, if I had better access to the lower level parts of the AVR, especially timing interrupts, I would have been fine. Once I got the error values working correctly, the project worked great. Next time I skip the arduino and go avr studio and straight c. Once I got the terminal result below, I went to bed
Error: -26
Direction: Left
Error Sum: -262
Error Correction -9.12
Error: -17
Direction: Left
Error Sum: -490
Error Correction -9.15
Error: -13
Direction: Left
Error Sum: -503
Error Correction -8.28
Error: -10
Direction: Left
Error Sum: -513
Error Correction -7.63
Error: -2
Direction: Left
Error Sum: -558
Error Correction -6.08
Error: 1
Direction: Right
Error Sum: 1
Error Correction 0.26
Error: 5
Direction: Right
Error Sum: 10
Error Correction 1.35
Error: 9
Direction: Right
Error Sum: 19
Error Correction 2.44
Error: 18
Direction: Right
Error Sum: 90
Error Correction 5.40
Error: 23
Direction: Right
Error Sum: 113
Error Correction 6.88
Error: 28
Direction: Right
Error Sum: 141
Error Correction 8.41
I was moving the target from left to right in front of the receivers, Error was the difference between the left and right times, Direction was which direction to turn, Error sum is basically the integral term before weighting, correction was what to add to the turn value.
The next day I showed up with my own box of kleenex, hand sanitizer, and trash bag as to not infect Ben and we went to work. We got everything installed, Ben finished the 3rd leg and handle and I changed the code so it would send the turn value to the motor controllers. Off the bat, it worked pretty well, had to do tweaking but I was surprised at how well it worked increasing and decreasing the separate wheel speeds based on location of the target. I added a distance timeout for too close and too far, tweaked the P and I weights, and added flashing lights for status. We tried a smaller battery pack but it died pretty short into it so we went back to the huge lead-acid batteries. We got it following well and then I left. Ben and Alyson finished closing up the front, added some decoration, and finished the taping. All and all, it was an awesome experience, I had followed Ben’s work on HaD and it was a once in a lifetime experience to work with him, I hope I get to work with him more in the future.
Watch the full video below
Here is a little bit longer explanation of the program flow
Powerup
Setup-
Set up the 3 serial ports
Serial is for debug at 9600
Serial1 is for motor control at 38400 and 2 stop bits!
Serial2 is for zigbee for remote ping
Set up leds
Send some commands to motor control
Main
Loop-
Clear out important variables like difference and distance
See if handle switch is in disabled position
Flash status LED
If Not Disabled; Do 4 pings and average difference result and distance result
If too close to person (based on distance); disable
If Difference looks good and not disabled; update the drives and
clear timeout; else increase timeout
If timeout counter is too high, disable
If disabled; set the drives to zero and blink lights
doPingDiff-
Do the high low thing to start both receivers
Send Zigbee start command
Wait for either left or right sensor to go to zero or timeout; record
that setpoint
Wait for second sensor to go to zero or timeout; record that setpoint
and break loop
Calculate the difference by subtracting
Calculate the distance by adding both values and dividing by 10 (for
scaling speed)
Return the difference (which is our error)
updateDrives-
Calculate the direction of the error (basically left or right turn)
If direction has changed, clear out the error sum (integral part of PI Loop)
Add Error to the Error Sum
Calculate turn value by doing Kp*error + Ki*errorSum where Kp and Ki
are set to 0.5 and 0.25 respectively and then add to 128 which is our
Zero
Calculate the speed by taking our above distance divided by two, then
subtract from 128 because forward is 0-128 (with 0 being max allowed)
Make sure turn isn’t greater than 250 or less than 5 (preventing
overflow or underflow)
Make sure speed isn’t less than 5 (preventing an underflow)
If Debug is set output all of these numbers through the Serial port as well
setToZero-
Set speed and turn to 128 (bidirectional data around 128, 0 is max
one way 255 is max other way
I’ve also attached the code for download. I’ts a .c file, but is actually the .ino, wordpress doesn’t like .ino files so just rename it to something.ino
Colecago
Kiloari
