Member Since: June 29, 2011

Country: United States



Boston Area IEEE Robotics & Automation Society http://www.robotics-boston.org/

Spoken Languages

English Spanish Lolcat

Programming Languages

Objective C C++ Python Pascal C ARM Assembly THUMB Assembly PowerPC Assembly 68k Assembly




Robotics, Video Games, Anime, Board Games, Electric Vehicles, Go-Karts, Sailing, and Mythology

  • Don’t forget the IEEE’s Women In Engineering (WIE) group: http://www.ieee.org/membership_services/membership/women/index.html

    1. Interrupt Driven Programming How to build software that actually reacts, instead of just waits on a polling loop. Why this can be critically important, particularly for events that might be missed in between polling loops. Talk in depth about interrupt priorities. Compare an Arduino, which cannot do nested interrupts, to smarter processors, which can handle multiple nested interrupts. Point out that just about no processor can do multiple simultaneous interrupts, regardless of how many cores it has, due to being on a single system bus, rather than a switched fabric; notable exceptions to this, if any.

    2. Hard-Real-Time Software What Hard-Real-Time, Soft-Real-Time, and other varieties of “Real-Time” mean. What this means for which C standard libraries to use, and POSIX compliance issues. Implementing a Hard-Real-Time system on baremetal. Implementing Hard-Real-Time with one or more Hard-Real-Time OSes.

    3. Complete HID Device development The complete process of HID Device development, from start to finish. Implementing:

    4. Buttons
    5. Digital Joysticks
    6. Analog Joysticks, Analog Pedals, & Analog Triggers
    7. Trackballs & Mouse sensors
    8. Capturing data from sensors
    9. More experimental examples

    10. Designing for Manufacturing & Reliability What does Sparkfun do to squeeze the most value out of its manufacturing? How should footprints and PCB designs be changed to be cheaper and more reliably manufactured?

    Also, check with your local IEEE Section: http://www.ieee-denver.org/ And Technical Society Chapters: http://www.ieee-denver.org/technical-societies/

    They will no doubt have some very relevant advice.

  • Consistent weight measurements would be fantastic.

  • Also works as ADB cable, on old-school Macintoshes!

  • Seconding some of the things already said…

    Problems with the current description: Fixed!
    No tolerances listed for the resistors
    No wattage listed for the resistors

    Problems with the kit as designed:
    Using the same resistor value in series accumulates tolerance error
    “Looped” resistors introduce impedance, which is inappropriate for a piece of test gear
    Traces should be extra thick and as short as possible to minimize additional resistance; alternately, the trace length should be matched to the resistors, to bring the total resistance to a precise value
    No nice box to put it in

    Make the 2.0 version a long rectangle, sort of like a power strip, with the binding posts on the low resistance end. That way, you can read the value straight across.

    Other changes should include:
    Each resistor should be the ONLY resistor used for that value of that digit; no resistors in series for the same digit, which accumulates tolerance error!
    “Lay Flat” resistor through-hole spacing, to eliminate the “looped” resistor impedance
    SMD pads between the through-hole pads, to install more precise SMD resistors

    Options should include:
    A selection of resistor kits, so people can install the precision they require, in through-hole and SMD
    A nice box to put it in, either with numbers on the box, or numbers on the silkscreen, so the selected values can be seen
    A selection of knobs to use with the nice box

    Remember that, as the resistor values go up, the tolerances must go up as well. For instance… If you are using individually selected 1% resistors for 10 Ohms through 90 Ohms, 0.1% for 100-900 Ohms, and so on through the digits, there will still be an error accumulation of up to 4.5 Ohms across the whole box. This would be MUCH worse if all the resistors were in the same percentage of tolerance, because a 1% tolerance on 900k Ohms is 9k Ohms! This would mean that 3 digits on the box are always completely wasted for any purpose!

  • <pilot> Hey, Mr. Wizard; check out this watch I made with government surplus parts! Now, you don’t need a spell to tell the exact time! <wizard> Feh! Next thing you’ll tell me is you don’t need a spell to fly, too!

  • You need to add some pads for the user to install multiple filters, such as band-stop, high-pass, and low-pass filters, so they can filter out power supply noise. These should be optional, of course, and the filters required will wind up being unique to each supply, but to make these supplies genuinely usable for more advanced projects, finding the right frequencies to snuff out to provide clean power is a must. Maybe one through-hole set of pads, and 3 surface-mount sets of pads, per output?

    Take some random power supplies, give them a load, and put it on a spectrum analyzer. You will see all kinds of crazy noise spikes. These should be filtered out before someone uses it on a serious project. And they won’t be the same across supplies, either.

    The user should have the option to filter out his supply’s noise with a set of pads for that purpose. It’s a cheap, affordable improvement that adds a lot of value.

  • Just because my last two planes burst into flames into mid-air, that doesn’t mean they get to tag my plane with a flame paintjob…

  • Yes, but now you’re ignoring the entire context within which I made my comments. Your robot can do a lot when it has an INTERNAL COMBUSTION ENGINE to charge the batteries. I was clearly dictating a context in which that was not an option, one in which batteries alone provide the power. When you have an alternator on an internal combustion engine providing the power, you can waste power on anything you want. Intel chips, FPGAs, ANYTHING. When your entire system is battery powered, and has to perform a long-term mission anyway, Intel chips and FPGAs aren’t an option.

  • While FPGAs are getting better all the time, they’re still too power inefficient for robotics except for very particular computationally intractable problems. For vision processing, there’s no reason to use an FPGA instead of a GPU, so long as you pick the right one.

    Smart phone and tablet GPUs are changing all the time, so leaving graphics out of the Edison package gives developers more options. Further, with so many form factors and corresponding resolutions to pick from, there’s no one RIGHT graphics solution. The Edison lets the hardware developer integrate Intel’s CPU into prototype hardware without them having to worry about how to integrate a complex chip package that really requires a full production run to assemble; this allows them to focus on prototyping the application specific hardware.

    Do you actually ship robots to customers, or are they merely prototypes? Aside from reluctant concessions to JAUS compliance, and other similar tough pills to swallow, I haven’t seen anyone choose to use X86 on a robot slated for production.

No public wish lists :(