Mike Szczys and Kerry Scharfglass recorded this week’s podcast live from DEF CON. Among the many topics of discussion, we explore some of the more interesting ways to move a robot. From BB-8 to Holonomic Drives, Kerry’s hoping to have a proof of concept in time for Supercon. Are you using On-Chip Debugging with your projects? Neither are we, but maybe we should. The same goes for dynamic memory allocation; but when you have overpowered micros such as the chip on the Teensy 4.0, why do you need to? We close this week’s show with a few interviews with badge makers who rolled out a few hundred of their design and encountered manufacturing problems along the way. It wouldn’t be engineering without problems to solve.
Take a look at the links below if you want to follow along, and as always tell us what you think about this episode in the comments!
Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!
Direct download (60 MB or so.)
Episode 031 Show Notes:
- Kerry Scharfglass built two versions of the Sympetrum badge:
- Interesting robot locomotion:
- Embedded Systems topics :
- Unofficial DEF CON badges discussed on the show
- Manufacturing Snafu Stories:
- DC Shoot Badge by @gigstaggart
- Tron Badge by @Sodium_Hydrogen
2 thoughts on “Hackaday Podcast 031: Holonomic Drives, Badges Of DEF CON, We Don’t Do On-Chip Debugging, And Small Run Manufacturing Snafus”
“Are you using On-Chip Debugging with your projects? Neither are we, but maybe we should.”
Maybe a series on how cheap production has enabled more diagnostics in a device?
Wished I’d listened to this sooner after it was released as it was interesting hearing from Kerry; I also do a lot of embedded software although I’m more on the hardware side, having started as a pure EE and yet doing embedded CPU design (coincidentally, it was on the embedded debug logic so, yes, I use on-chip debugging all the time!).
Oh, with regards 25:40, while I don’t know what Freescale are specifically targeting with their implementation, the Cortex M7 was designed as a DSP replacement in mind (hence why it can do two ops in a cycle with wide data busses).
Please be kind and respectful to help make the comments section excellent. (Comment Policy)