Robot Luggage- My Ben Heck Experience

[Colecago]

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
http://blog.colecago.com/?p=38

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. Video here:
http://youtu.be/tAyWrJoVUbs

[Colecago]

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.

[Colecago]

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 output of the device, or if its meant to connect to the TX of the remote device connected to its header, hence the often confusion. 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 incorrect 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.

[Colecago]

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. 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.

[Colecago]

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.



Code is on the bottom of my website, HaD won't allow .c files
http://blog.colecago.com/?p=87

[semicolo]

Neat project!

About the uart TX/RX rant: aren't TX out and RX in by design? I never had trouble with that. Usually it's the cable I pick I don't know if it's straight or crossed and if the connectors on board are straight or crossed, but once it's figured out and Tx on the one side is connected to Rx of the other side, it works.

[Colecago]

Neat project!

About the uart TX/RX rant: aren't TX out and RX in by design? I never had trouble with that. Usually it's the cable I pick I don't know if it's straight or crossed and if the connectors on board are straight or crossed, but once it's figured out and Tx on the one side is connected to Rx of the other side, it works.

Not always, I've seen plenty of boards where things were marked TX and they meant put the TX line of your communication device there as it goes to the RX on the micro.

[k-ww]

When I'm not 100% sure which is which, I put series 1K-10K resistors in the TX & RX signal leads, then I scope them to see if the signal gets thru - if its visable on one side, but not the other, I have two TX outputs glaring at each other.

[signal7]

Sorry to bump an old topic, but it took some time to get an account on the board.

Most people don't realize it, but the compiler for Arduino is the same compiler that's used for all (or nearly all) Atmega development. This means that though you may "hate programming for Arduino", you also have raw access to the low level hardware whenever you feel the need to access it.

Essentially, you don't have program for 'the bare metal' *or* 'the arduino'. You can mix and match between the environments within the same project and use whatever features you're most comfortable with. The only thing to watch out for is if your code wants to use Timer1 directly and there's some kind of conflict with another part of your code where (don't quote me here - it's only an example) perhaps the millis() function might also depend on the same timer.

[Colecago]

Sorry to bump an old topic, but it took some time to get an account on the board.

Most people don't realize it, but the compiler for Arduino is the same compiler that's used for all (or nearly all) Atmega development. This means that though you may "hate programming for Arduino", you also have raw access to the low level hardware whenever you feel the need to access it.

Essentially, you don't have program for 'the bare metal' *or* 'the arduino'. You can mix and match between the environments within the same project and use whatever features you're most comfortable with. The only thing to watch out for is if your code wants to use Timer1 directly and there's some kind of conflict with another part of your code where (don't quote me here - it's only an example) perhaps the millis() function might also depend on the same timer.

It was more of a hate bred from a short time constraint and things not working the way they would have writing C using Codevision, which is what we use at work. I tried taking some of the interrupt code from Codevision but the Arduino compiler didn't like it. Codevision probably has some special stuff in their libraries that Arduino didn't understand.

If I had more time, I would have wrote the whole thing in Codevision and used AVRDude to upload it. As a hardware base I think Arduino's are pretty awesome, there isn't nearly as much standard AVR dev boards as there are Arduino versions, I just don't have much need for the Arduino software and compiler. I'll probably give those another chance when I have some time to spend on it.