Strobotics

For the open Hardware Rallylog device I’ve been working on, I’d based my design around fitting into the handy Sparkfun Project Case and since most of my projects never get to the “enclosure” stage, they are either used bare PCB or thrown into anything that may provide some protection against the elements, such as the widget sensor housing.
(http://blog.strobotics.com.au/2009/06/15/widget-sensor-housings/).

This project was different for me since I’m required to build 10 of them for the local motorbike club, something a bit more “finished” than your standard geek project. Throughout this project I’ve learnt how to use 3D modelling to check mechanical layout and tolerances, also to use mechanical data supplied in technical data sheets in selecting my components. This along with taking into account PCB heights, button heights. Overcoming challenges like how do I get my LEDs to the outside without using panel mount LEDS, or how do I protect or mount my LCD display again with out using a panel mount. I then used all this to make things easier for me when it came to production to produce CNC tool path G-Code to cut my enclosures.

I thought I’d document the process that I’ve gone through to get my Rallylog nice and snug in the Sparkfun Project Case. BTW this may not be the right way, but it’s the journey I took, I would love to hear from people who do this professionally for a living to get a feel of the full product design process.

It has to be easy to make and assemble

Right from the outset of the project I wanted this to be easy to assemble. Seeing I have to make 10 of them (to start with) I wanted everything to be mounted on the PCB so all I have to do is get my enclosure and put in the finished PCB, screw it all up and its working, i.e. I didn’t want to have a panel mounted LCD or LEDS that I had 1) manually fix to the Enclosure, and then 2) “wire” back to the PCB. I wanted something that I can reproduce easily and with the least amount of human work, I love my projects, but quickly hate having to manually do a lot of repetitive work like solder up individual LEDS etc. (I guess I ‘m lazy). I also have a small CNC machine at home, A Zenbot Mini that I purchased off eBay some time ago, so I wanted to automate the panel cut outs as much as possible. I wanted this to be repeatable, using a handheld Dremal is not my idea of fun, especially if I have 10 to do now I will quickly loose interest after the first one, and it’s definitely not repeatable. Also if I get an order for another 1, 10, 100 down the track I definitely don’t want to do it manually, and I don’t want to think too hard about getting things set up.

I could have also gone with an Arduino board and made up a custom shield or use the RFID shield, again it would have meant more painful hand assembly, so I decided to stick with a custom board fitted into a readymade enclosure.

It all starts with the User Interface

Whilst I already had my initial schematic laid out (in Kicad), before I started my PCB layout process I needed to work out what it was going to live in. I was very eager to start laying down track as I love designing PCBs, but I had to hold myself back and ask a couple of questions first:

1. What am I going to put it in? It needs to be functional, fairly robust, and fit everything in, including the battery, the RFID module, the LCD, SD Card socket and so on. It needs to be off the shelf that I can easily modify, no custom injection moulded case for this project ( I wish)
2. What is the user interface going to look like? I needed to keep to the KISS principle. The majority of users at this motorcycle club are semi-retirement to retirement age, so not the most savvy when it comes to geek gadgets,
3. Will it be easy to assemble?

When you stop and think about it, it makes sense to start with the user interface and how this will fit into an enclosure, then move onto the physical PCB layout and component selections, else my PCB might not fit into the case, it may be too big, too small, same goes for components selected. The user interface may not be functional and then we’d have to start again.

The User Interface design

My initial schematics included a Nokia LCD display and a joystick for user input. Also a couple of LEDS for visual feedback.  

When I asked myself the three questions above I quickly went back to the drawing board, as the Nokia display failed Question 3), same went for the Joystick, also I felt that it was would have been a bit too had for the target audience to use, so it failed Question 2) as well.

In the end I decided to go back to a tried and proven UI design that consisted of a simple and easy to read backlight 2×16 LCD character display with three push buttons for user input and two LED indicators, something a bit easier for the end user to use.

As yet I had not selected the parts i.e. the LCD or switches, I just had the layout in my mind (or on paper) the UI layout that was a three button input under a standard 2×16 backlit character LCD, and x2 LEDS to the left of the LCD display, these LEDS would be Red and Green, which could be used to indicate different statuses easily, really simple!

The Enclosure

Once I had the basis of the interface this is where the engineering juggling started, I had to find an enclosure that would meet my requirement, and find components at the right price that would work with the selected enclosure in the way I wanted.

I had a look around on a number of sites and found there is a wide variety of enclosures out there, however without physically having one, its a bit hard to start working out measurements and getting a general feel for it in your hand. As luck would have it I already had a couple of Sparkfun Project cases at home that I had purchased for a “future” project, well this was that “future” project, I used this initially as my enclosure of choice, it seemed to fit well in the hand and be spacious enough to seemingly fit everything in, i did this initial check by putting in the ID-20 RFID reader module and a 9V battery to see how things would fit. At this point I still did not have an LCD or buttons selected.

Once I had my enclosure selected it is now a matter of finding the right size components to fit, as mentioned above I wanted everything mounted on my PCB, and now I had the dimensions of the enclosure I could start my PCB design and component selection, this process I found to be the most time consuming. However I initially needed to start working out my clearances with my PCB in the enclosure, I’m also a visual person, I need to see things to make it easier for me to understand, so I decided it would be much easier to utilise 3D modelling and model the enclosure and mock up my UI, I’ve used Alibre in the past and this is what I modelled the Rallylog enclosure in.

The 3D Model

Not wanting to re-invent the wheel I contacted Sparkfun customer support with a request for a 3D model of the Project enclosure and received an email from Casey Haskill, the designer of the enclosure, he was more than accommodating (Many Thanks Casey!!!) and sent me the files in IGES format, one that Alibre supported……supposedly.

The great things with standards is that everyone has their own take on them, obviously Alibre was no exception, the problem was that each time I went to import it failed, after a bit of research I found a small utility program that I used in a two step process that allowed me to clean up the IGES and export it as an STP file, one that worked with Alibre.

Once imported I can now can get accurate measurements and start modelling individual components. My modelling is very simple, make a basic 3D model using the supplied mechanical data, no fancy surface or trying to emulate the real thing.

One of the immediate things I could see is that either I had to use a panel mounted PCB or I needed a two tiered PCB design as the headroom above the PCB was quite large. The panel mounted LCD was ruled out due to easy of assembly rule, so I knew that I would be dealing with a two layered PCB design.

Alibre is great for quickly creating 3D objects and by changing dimensions it regenerates the 3Dmodel, so I quickly created a two tiered mock up of a PCB with the correct thicknesses of the PCB substrate being used, this was added to the enclosure assemble so I could visualise the internal dimensions. The two PCB layers are separated by the dimensions of a standard 0.100 header and socket of 8.5mm.

From this I now had the dimensions required from the top of my PCB to the inside and outside of my case.

Now I needed to know what LCDs, buttons and LEDs out there that when mounted on the PCB how they would interact mechanically as far as clearances with the enclosure, however I had to work into the constrains of my circuit design and of course price.

Due to I/O restraints I couldn’t use the standard character LCD in 8 bit or even 4 bit mode, so that ruled out most of the cheapest LCD displays around. So it had to be I2C, SPI or Serial, my initial design was done with the Nokia LCD in mind and so used SPI, as I wanted it to mount onto my PCB, almost all LCD I’ve found have their own PCB with a connector that either plugs into a cable or you plug it into a socket onto the PCB, so another layer on top of the existing PCB was not feasible. I located the I2C range of New Haven Displays and found one that would fit given the dimensions, however I couldn’t get them locally and ordering in from New Haven was approx. $USD50 per display, not economical! Unfortunately there were not many alternatives.

After talking with my local local supplier he put me onto the EA-DOGM Series of LCD Character displays, these can be run in SPI Mode or traditional 4 or 8 bit mode, there are also directly mounted on the PCB, and have an optional LCD backlight module that mounts under the LCD module. The price was even better, $AUD15 for 2×16 and $AUD4 for backlight, perfect pricing just need to check how they would fit. From the Technical data sheet I whipped up a simple model and added it to the PCB

From this I could see that the LCD would fit if PCB mounted, but had an interference with the top of the Sparkfun case, this was acceptable as I would need to machine the cut-outs at some point.

I then did the same for switches and their buttons, I wanted the button to just clear the case and not be too pronounced or the reverse I didn’t want it to be recessed. In the example below using 6mm Omron switches and their associated square buttons. I found they were too pronounced out of the case.

I ended up finding the 12mm Sparkfun Push Button which met the right criteria and the button just cleared the case, after modelling it looked perfect, however the switch body itself has some interference with the top of the case, this meant that if I wanted to have a switch with the right height I would have to machine out the inside of the case.  

Engineering decision time….After weighing up the aesthetics and the work involved in machining out the case I decided to stick with machining out the inside as I would already have the top case mounted for cut outs, what if I just flip it around and machine from the inside, that way I could kill two birds with one stone. I could pocket out around the switches ( and the LCD if required) and then perform the panel cut out. I didn’t know how I was going to perform this but seemed doable.

Just to make sure where my interferences I used a great feature of Alibre called “Assembly Boolean” where I can select the top of the project box as my blank, and then select all the buttons and the LCD as my tools, the Result is the top of the Project box with all interferences subtracted so I can I know where to machine.

Just to cover my bets I added both switches to my design, that way I could use either if the other didn’t work, much easier to add the extra footprint at design time that to find out after that I really should have used the other switch, so I had an escape clause

The LEDS

What about The next thing I needed to worry about was what to do with the LEDS. Where possible I now use SMD components rather that PTH, but using the PTH over SMD was going to be my only choice, however they would be standing quite tall off the board, and as the end user would have to remove the back of the case to eventually change batteries, I didn’t want them to be able to damage the LEDs if incorrectly re-assembled for any reason.

I started looking around for solutions, not being in the industry I wondered how they did it, looking at every day consumer electronics I saw that pretty well every LED indicator is displayed through a plastic window, that’s what I needed, but what are they, after much Googling I found the correct term of “Light Pipe”, this made things easy. I could stick with my 0603 SMD LEDS and have a standard 3mm vertical light pipe (they come in many different flavours) bought directly to the top of the SMD LED.

The Final PCB

Happy with the components selected I then proceeded to finished my PCB design, again to make things easy to assemble I designed the two layers as a single board separated by tabbed routes and tooling strips so the individual boards can be separated after assembly. I also moved my LEDS over to the right hand side to accommodate for the PCB connectors finished result.

To see the full assembly steps see my previous blog entry http://blog.strobotics.com.au/2010/07/21/rallylog-assembly-progress/

Next…How I machined my enclosure cut-outs

Jans Gentsch has made his compact version of the Strobit Triggr available to the community, his version, the Strobit M08 based on AVR design can be found here.   Please note that there are a couple of things that need doing to the PCB, if you get a chance to implement Jans design, please post back any changes to me so I can make them available.

Hello Stephen,

I’ve attached the Eagle-Design-Data as well as the source code. I haven’t found time to do anything on those since my post, so the are not in the best state. There are a few Problems with the board design:

Transmitter – There is a connection missing between the processor and NIRQ of the transmitter-module (the transmitter module doesn’t have a fifo, so that the nirq-line is needed to clock out the data). I just added a piece of loose wire during assembly.
Receiver – NIRQ isn’t connected as well, so I am constantly polling, not really a power saving design. however I am still running on the first set of batteries so it’s not like they are being drained empty immediatly.
IO-Board – Thr optocoupley was meant to sit on the bottom side but I got confused. It has to sit on top now.

Getting everything into the housing was a major challenge.

The source code has been developed using avr-gcc and the eclipse ide.
As it stands only the most basic function, tiggering, is working. The control flow will have to be reworked in order to add the rest of the functionality. And of course my “magic” trigger id should be changed.

Have fun!

Alle the best
Jan

Files

You will need Eagle PCB to view/edit the schematics and PCB files, found here -http://www.cadsoft.de/

The firmware is written using winavr found here – http://winavr.sourceforge.net/

• strobit_mega8.ZIP
• sm8rxtx.zip

Introduction

20/03/09 *UPDATE * This project now has a new home and is actively being developed on Google code project hosting http://code.google.com/p/strobit/

IMPORTANT    This page is no longer being being maintained please go to the new project page.

Welcome to the Strobit Triggr Project, an open source hackable wireless trigger used in photography lighting by using low cost strobe units triggered remotely via RF. This was started while trying to find a cost effective and reliable solution to the commercial alternatives out there. At one end of the market is the Ebay or Cactus Trigger, which is low cost but rather unreliable. At the other end of the market there is the industry standard, Pocket Wizards, very reliable, but very expensive (i.e. way out of my price range).

What I wanted to do was to create an open platform that anyone can easily build for a low cost and then be expand upon by the community. The pair of prototypes I’ve built were a proof of concept that I can get a camera to trigger a strobe unit reliably at a low cost. From early tests it appears that I’ve succeeded in my goal, but further testing is required.

Project Status :

- Prototype successfully working in single master/slave configuration !

- (20/03/2009) Project now has a home at Google Code – http://code.google.com/p/strobit/

Still Todo:

• Specifications
• Hardware Design
  • Schematics
  • PCB
• Software Design
  • Wireless
  • User Interface
  • Protocol
• Hardware Prototype

License

The strobit hardware design is covered by The TAPR Open Hardware License. Please see http://www.tapr.org/ohl.html for further details.

Schematics:

Prototype Details

Firmware Description

Protocol Description

Downloads – Files associated with the project

Tests – Tests done so Far

In the Wild – Version of this trigger made by others

I’m toying with the idea of putting together a low cost kit for the enthusiast. i.e. PCB, pre-programmed PIC, etc. So we could all benefit with a bulk order of the components. If your interested please email me using the contact form the top menu or use the mailing list signup on the right to give me an indication of numbers interested. Once I finaliaze the design and get some idea of numbers I’ll get a better idea of price. At the moment it will only be available in kit form due to FCC and other Licensing regulations.

Future Improvements:

• Higher Sync Speed.
• Frequency Hopping.
• Forward Error Correction.
• Power management.
• UI to change settings, Channel etc.
• Save settings in Flash memory.

I’ve put an initial design (both eagle source files and PDF) into SVN that is aimed as a board replacement to the ebay triggers.

http://svn.everythingrobotics.com/strobist/mk1/trunk/design/ebay_trigg.pdf

Things seem to have slowed down on the forums qute a bit, I’ve also put a poll up for the project name, based on a few from the marketing topic where a number of people have put forward their suggestions, well, while the poll has been viewed a large number, only 12 people have voted so far, a bit dissapointing, obviously they didn’t like the names I’ve pulled from the forums, Oh well I know you can’t please everyone.

Anyway moving forward….I’ve been busy researching RF modules and coming up with a prototype design.  Currently I have 2 prototypes designs on the go.   One as a drop in board replacement for the Ebay Triggers based on the RFPIC, the other as a Pocket Wizard type trigger, but hackable, based on the Phillips LPC2148 ARM7 Chip.  The designs are not complete by any means.  I’m still in 2 minds about the RFPIC Design I may for go it in favour of a standard pic with an external RF module, that way I could use the same RF module in both designs.

 Ebay Trigger Replacement Preliminary Design (TX)(PDF)

 LPC2148 Based Trigger (PW Replacement) (PDF)

I started testing last night after finishing initial motor and wheel sensor hookups to my development board.  Couple of minor issues so far. 

Issues 

I’m using a pic based board from Modtronics. These are great and reasonably priced, along with the prototyping daughterboard.  However I have since found that the onboard RS232 is not on the same pin as the PICAXE28X, so I had to wire in an additional programming circuit, no biggy.  The other issues so far were the wheel sensors.  From my initial design I had used 10K resistors to bias the output of the opto-transistor, this was not tested and when testing the logic probe was picking things up ok, but not the PICAXE, after much stuffing around and not being able to find my multimeter (it was still packed away from shifting house) I ended up prototyping the same circuit, still had some issues, so I went  hunting for my multimeter and of course it was on the bottom box lol.  Luckily thanks to my trusty multimeter I found that the sensor was just dropping down to 3.8v when interrupted, anyway the solution to the problem was a larger resistor, a 22K on the output, this tested AOK, now getting ttl levels when switched, I also noted that the distance of the sensor to the reflective object (paper in this case) was fairly critical.  I modded the breadboard and then found one side was working fine, the other was not being seen.  Checked and found that the sensor was slightly further away than the one that was working.  So out with the hot glue gun and moved the sensor.  Both side are now giving me a reading on the PICAXE.

Motor Tests 

Next I adapted some motor control routines on Hippys PICAXE site to test my motor circuit.  First I tested without my motor control board plugged in, didnt’ want any smoke to escape, and all logic tested aok, then came big crunch of running motors live.  I can gladly say that all tests worked A1 with no issues.  Motor was tested though a range of 3 speeds in FWD, REV, Turn right FWD , Turn Left FWD, Turn Right Rev, Turn Left Rev, Spin Left and finally Spin Right.  While Testing the FWD and REV, I checked the Pulses from the wheel encoders to see how much the same each drive was over 100 counts from the wheel encoders and it looks like the Right side is slightly stronger than the left, no real surprise here as no two motor/gearbox combinations are the same.  I had thought about this a few days ago and knew that with any differential drive system I will encounter this type of problem.

Motor Control Algorithm 

This then leads me onto my motor control algorithm.  Over the last few days I have been researching PID Controller and their application to motor control for robots, as I want Buzzbot to drive in a straight line, also been looking at fuzzy logic, but I think will give that a miss at the moment.  I have been thinking of using and adaptation of the PI Proportional controller from the book “Robots – Inspiration to Implementation”  however so far I’m not 100% happy with the PWM and the way it is from the code I adapted, while it is very simple and works,  I would really like to use the onboard PWMout routines, but as I mentioned in an earlier entry it is only limited to two PWM and to two physical pins on the PICAXE – Bummer!!!!   I also thought I can use the old PWM command.  This command requires it to be refreshed, much like what is happening in  my test code, except with a agreater resolution, unlike the PWMOUT that runs in the background, perfect I thought!, but when I went to test it I found it’s only available on the 08 series…double Bummer!!!!!  So now may have to look at teh PulseOut command.

While the existing configuration does give me three speeds, the lowest is time critical and I notice that when I add a debug routine the slowest speed does start pulsing, also I don’t think it will give me the fine control needed on each of the wheel speed controllers.  I’m going to have to think about this a bit deeper.

Conclusion 

All in all everything is working as expected, with a couple of minor hicups along the way.  Biggest issue will be PWM resolution and time of my routines.  I think I’ll need to come up with another way of doing what I want simply and without too much additional hardware if I want a closed loop control system.  While I ponder on this I’ll test the IR Sensor circuits.  These I’ll prototype first before I hardwire in.  Once I finish these I can then start working on behaviour.  I would like to look at using some sort of subsumption model, but will look at it deeper as I get closer.

Last night I did some brain storming asto what the I/O requirements will be.  During this requirements phase I came across a bit of a delima with the PWM requirements for the motor controller.  The motor controller requires two outputs per motor, so this rules out using the onboard PWMout command of the PICAXE, as there are only two dedicated PWM pins on the chip that I’m using.  Although I could do it with some additional glue logic in hardware, I don’t really want to do that (as I’m lazy), so now I will be doing it all within the software, this should free up the servo command within the PICAXE, so I can now use this to drive the servo for the sonar unit.

I’m going to be using the PICAXE 28X. With my I/O current configuration of the 22 available I/O on chip, I have 2 Inputs/Outputs and 4 Analogue Inputs Available for future expansion (or and additional 4 inputs if I don’t want to use the analogue inputs).  It will be interesting to see if the processor will be fast enough process everything in a timely manner, especially with the motor control and encoders.  Well I guess I’m about to find out.

I’m now going to actually get my hands dirty with the PICAXE as I still haven’t plugged the development board into my PC yet

BuzzBot – I/O Requirements

Buzzbot – PICAXE Circuit

Over the past number of years, along with my interest in robotics and software development,  I have also had a keen interest in machining and metal work, I suppose ever since I build my first Stuart Turner stationary engine when I was 15 on my fathers Lathe,  BTW my father is also a very keen model engineer/machinist.  So wanting to merge my interests along came CNC.

I don’t own a lather / milling machine, actually I don’t even have a workshop myself (about to change with my new house being built), although I do have access to them when ever I want its still not the same as ducking out to the shed to whip up a part, in general I find making small components and PCBS a bit of a pain, mainly though lack of tools and proper work area.  So Getting back into the robotics/electronics scene after a long break has also re-kindled my interest in the CNC Area, especially for small robotic parts (plastic and aluminium) and one off PCBs (routing and drilling). 

So in my quest for knowledge, I spent the last few nights browsing what’s out there, and was very surprised to see the huge amount of work that people have done.  I must admit it had been a couple of years since I’ve last looked, and there there are some truly amazing machines out there (check out http://www.cnczone.com/).   Anyway I think I want to start off small first with a low cost pcb router/drilling using a 3-axis with a dremal.  Plenty of photos out there with low cost designs and common parts have inspired me to take some steps and begin some design work, so stay tuned.