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
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.
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 Sum: -262
Error Correction -9.12
Error Sum: -490
Error Correction -9.15
Error Sum: -503
Error Correction -8.28
Error Sum: -513
Error Correction -7.63
Error Sum: -558
Error Correction -6.08
Error Sum: 1
Error Correction 0.26
Error Sum: 10
Error Correction 1.35
Error Sum: 19
Error Correction 2.44
Error Sum: 90
Error Correction 5.40
Error Sum: 113
Error Correction 6.88
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
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
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
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
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
Return the difference (which is our error)
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
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
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
My upcoming project is a WiFi Radio. I have a small atom board computer that I will use as the base. I am going to load it with XUbuntu (a lighter version of Ubuntu) and make it a WiFi radio. I bought a cheap antique-looking radio from a pawn shop for $20. I plan on using it as my case.
I bought 3 RGB encoders with push buttons to replace the current pots in the radio. I want to still use the knobs but drill a hole down the center to allow the RGB light to shine through. I will probably have to use some clear fill to spread the light out like a lightpipe, not sure what I will use for that. I also bought an LED ring graph, that will be my channel/category indicator as I can make multiple categories of stations. That’s all I plan on using for the UI.
Playing a song- random fading, all the same or all different
Stopped- pulsing a color
In use- turn the one being turned a solid color
Possible Beat Mode- flashing/fading to a song beat
Changing Volume/channel/category- display the amount on the bar graph using both sides, when done (as indicated by no change for a period of time) flash the lights a few times and go back to whatever the ring was set at
VU Mode- Left and Right channel VU set up split top and bottom
Equalizer Mode- 4 frequencies shown going from each quadrant to the next quadrant (so 4 LED’s each freq)
Chase Mode- have lights go back and forth to give the idea of chasing lights
AM/FM Knob Turn- will be used for changing categories of stations
AM/FM Knob PB- Change light mode of the knobs
Tuning Knob Turn- will be used for changing station within a category
Tuning Knob PB- change light mode on the LED Graph
Volume Knob Turn- used to adjust volume of course
Volume Knob PB- Mute/Unmute
Speakers- I got some sony mini speakers on sale from Best Buy. I believe they were $5, originally like $40 though. They sound pretty good. Not as loud as the original speaker but has its own internal amplifier/driver and it’s stereo.
Software- I plan on using a teensy++ as my hardware interface. It will send encoder and push button information via serial. A python program on the computer will be doing the stream control using Streamtuner. Also hoping to put the equalizer and VU work on the computer. It would be nice to have all the LED control on the computer so it can be done quicker and more efficiently with the teensy board acting only as a hardware i/o interface.
The hard part will be the Python-Streamtuner interface, I have never programmed in python before. I typically use C, Java, or VB, but have used lots of other languages from time to time. Also, because I won’t have a screen, connecting to new wifi networks will be difficult, I’m hoping to write a script that if a usb drive with a certain file (wifi.txt) is inserted, it parses that text file into its wifi connections to be able to connect, then I will never need to use a monitor after I get it set up.
I bought an Olimex dev board on Sparkfun to help a friend on a car project. I never ended up using it but saw an ad on Craigslist for some freelance engineering work so I made it into a encoder based wire counter. The goal was to have a wire pulled off a reel and pinched on to a wheel so if someone pulled the wire or had some unwinder, the wheel would spin and an encoder would give feedback to a device that calculates the feet and inches. Well after making the product things kinda fell through in a crappy way so I am posting build info up here.
The dev board has 6 buttons, several inputs, an LCD, buzzer, relay, and assorted other IO. I ended up using the DALLAS input with an added cap from R8 on the micro side as a low pass filter to help with bouncing. I used all the buttons, left/right changes the Pulses Per Inch (PPI), up/down changes the inches and feet offset, the center button resets to the setpoints, and the lower left button stores the values to EEPROM. If you hit the center button upon power up, the EEPROM values are set to 0ft,0in,10ppi. I removed the Relay and Buzzer and tied into the relays terminal block for the encoder to plug into more conveniently.
You set PPI by finding your encoder Pulses per revolution, and then finding the circumference to find your inches per revolution, combine those (divide pulses by inches) to get pulses per inch.
Offset is used if you have to thread the wire so far before pulling, then you can keep track of that wire.
The code contains two interrupts, one for calculating adding and subtracting values for PPI and Offset adjustment. If you hold the button long enough the speed of the change increases. The second interrupt is INT0 as is connected to the encoder. Every rising edge a pulse is added, inches are added based on PPI and feet are added at 12inches and inches are reset. The main loop does all the button reading and lcd updating. LCD updates when a button is pressed or when an onscreen value is changed. I ended up using 99.2% of the flash and like 5% of the EEPROM. I had to make my own printf function because I did not have enough space for the standard library. Readbuttons is a routine that does all the I/O changes and matrix reading to do the button reading.
And that’s about it. Here is a video of me showing it off with my raspy sick voice. Not the greatest video, I have a video camera but not a battery charger or stand so I used my phone. Eventually I’ll get the better camera up and running.
I might put this thing in a box, I can tie in some better panel mount buttons, mount the screen, and maybe find a buyer. If you have any questions about this build or want it, leave me a comment or email.
That’s it for now!
Click below for the compiled hex code as well as the C file. I used some libraries available on codevision.
Recently I won a contest on Element14 where I was supposed to receive a hat from Ben Heck’s Ghost Squad episode (satire episode about ghost hunting). If you don’t know Ben Heck, you should look up some of his videos
Ben Heck is originally known in the hacking/modding community for his portable PS3 and Xbox360 Laptops and custom controllers for disabled players. He has been contracted by Element14 (part electronic supply company Newark) to make many of these videos. He is a graphic artist by trade and taught himself electronics. He does amazing things like portable CNC machines, portable workbenches, portable consoles (portability probably a good theme for him), and other neat things. He is kind of a hero in the modding/hacking world.
Anyways, I was contacted by Element14 about the contest and I asked if he was going to sign the hat, here is my email
Is Ben signing these at all? It would be awesome if he did. I’d even come to pick it up as I make frequent trips to Madison. I’m an EE and love his work, I’d hang it in my basement lab to give me inspiration to use my powers for good and not as much for corporate greed, except when I need to pay the bills, typically 8-5 daily.
Either way, thanks!
Hoping to appeal to Ben’s sarcastic fun nature. Well it worked, I was contacted about going to his shop last Tuesday and told I could meet him.
I went to his shop where Ben and Alyson (his camera person/assistant) were finishing up a show. I stood watching and looking around the lab (probably creepily) at all the awesome stuff there. Just electronic components everywhere, projects here, projects there, giant CNC machine in the main room. It was pretty awesome. After they finished the episode, I got to talk to Ben about electronics and you can definitely tell he is passionate and knows his stuff. He showed me some things in his shop including his 3D Printer, which I think he might turn into a laser engraver and his homemade pinball machine. I talked about what I do for work, and he mentioned a future project he might talk to me about.
We talked for about 20 minutes before I had to go, but it was a really awesome experience and definitely motivates me to do more electronic projects on my own (I wasn’t kidding about the hat for motivation). Here is a picture of it
For anyone interested in hacking/modding check out Hackerspaces. These are local establishments that teach classes and have equipment to assist any hacking or modding project.
Added the pushbutton on the side for resetting so it can be programmed without opening, and also added a light for when a button is hit. I tried to do Sugru strain reliefs, but I tried them thinking I could shape them, pull them out of the case, and then finish the case. Well sugru is very sticky and it didn’t work out as well as planned. It will still keep the cord from pulling out though as each cord has a plug of sugru inside the enclosure as well bigger than the hold. I think it looks pretty good.
On the software side I will eventually make a program that lets you change what keys are pressed, but it will just modify the c file and recompile. Then you can hit the side button and use the teensy programming program to update the firmware.
I’ve been wanting a gaming footpedal for awhile. I’ve been playing Counterstrike for many years and recently I’ve been sick of my keyboard/mouse settings for my talk and walk buttons. When I am steadily aiming at a wall, waiting for someone to round the corner for that headshot I don’t want to hit a button on my mouse to talk to the team and tense up my hand and possibly throw off my aim. Also, if I am in the middle of a firefight I don’t want to have to hit a keyboard button to talk because it would mess up my moving/crouching/jumping etc. This goes the same with the walk button, but less so.
Well recently we were cleaning out upstairs at work and I found an old controller with a footpedal. It was getting thrown out so I got my hands on it and took it a part with the purpose of using it as my walk/talk buttons.
I took it a part and the cable had five wires.
Green wire was chassis ground on the pedal, Red was the NO connection for both pedals, Blue was the NC connection for both pedals, and Yellow and Black were signal wires for the pedals. A friend from Sector67 turned me on to Teensy boards, which are USB Atmel AVR’s, they are small and can be programmed through USB. These are often used for HID Keyboard hacks, here is the one I am using
I stripped the foot pedal wires and connected them to the board. I connected the NO connection to ground, and both signal wires to pins on PORTB. PORTB is set up to internally pullup to VCC. I then edited some sample Teensy code and tossed it on the board to press the 7 and 8 buttons on the numpad for each pedal.
Next steps are to add a status LED, secure the board in place, and to use Sugru to add good looking strain reliefs to the cables.
I’m also thinking of adding a pushbutton and making the controller configurable using a windows based program communicating over the USB port. You could press the button, open up the program, and change what keys the pedals are bound to.