This is probably not the right place to gripe about the “mother ship” for the Arduino TinyML Kit but nevertheless allow me to express my disappointment. I understand fully the purpose of the Kit but the fact that the camera cannot be easily mounted elsewhere without custom PCB manufacturing (not trying to plug any particular company here but these are very cheap and, in one case, FREE for the 1st order except shipping) but the loss of direct connections to all the other Nano 33 pins (but for the Grove jumpers) is not forward thinking. Goes against Dr Reddi’s Use Case considerations, I believe.
Extensibility should be an integral part of the design. Sorry for the rant but I’m using the Kit without the mounting board.
Candid thoughts and feedback are always welcome! That’s how we make things better, so thanks for sharing
You don’t have to have the camera mounted, you can easily connect it without using the shield. The reason it is built that way is to minimize the wiring related start-up issues. So if we needed, we don’t have to use the shield altogether. That said, I am skeptical if I am answering the point of your concern. Can ya let me know?
Honestly, in the future, it would be great if we could just use any arbitrary kit, and we treat the specifics of the course as just a point example. We aren’t necessarily bound by the kid. Loads of new exciting hardware is coming out. For instance, especially the RasPI Pico: Meet Raspberry Silicon: Raspberry Pi Pico now on sale at $4 - Raspberry Pi
And by the way, @baqwas would love to hear any other thoughts and ideas you may have on how we can address this or any other issues to make this easier and more modular and flexible for people.
Thanks for the quick reply. Understand your viewpoint. I had challenges with Sandeep’s article with Nano 33 BLE Sense.
I published my obligatory Hello World exercise with Rasperry Pi Pico on YouTube. Will work on using the C SDK to emulate the Colab exercises. Had to suspend Pico work because I need to complete this course first!
Oh that would be so awesome if you could provide an alternative approach/deployment for the Colabs. Pete Warden, who you will “meet” in course 3 was all excited about getting it up and running on Pico and we’ve got some other skunk work projects in the pipe.
It would be great if we had different solutions so that there isn’t just one way of learning the course materials.
I absolutely think that RISC-V + TinyML is a boom waiting to happen.
Pete and I were working on Towards deep learning using tensorflow lite on risc-v. Check it out, but it was very much barebones stage and we never picked it up, but I would love to see us move that needle forward!
Let’s start a new thread on that @baqwas. Would you mind seeding that idea in a new post?
To reiterate what VJ said about the camera interface, you do technically have the option to connect the 18 requisite wires between the microcontroller and camera breakout independently of the provided shield. Having done this a few times myself, I can speak to the motivation for shield: it’s easy to mix up one wire with the next, which can be frustrating to debug, and perhaps more importantly, if you were to use jumper wires rather than hook up wire, given the 2x10 array of male pins from the OV7675 module are not breadboard friendly, you’d find that this approach is susceptible to some amount of inconsistency in continuity, affecting performance. Given the choice between a custom PCB with drop-and-go compatibility and a breadboard, wires, and some expectation that the interface could present practical challenges, we opted for the former.
On the whole, the choices that led to the formation of this kit are a result of carefully balancing many different factors, including a wide spectrum of learner familiarity with hardware. For educational purposes, we really wanted the kit to be plug-and-play, to cut away at some of the start-up friction that VJ alluded to. Sure, perhaps we could have sourced a development board with the camera directly integrated onto its PCB, like the ESP32-EYE, but in that case, you give up the on-board integration of an IMU that is required for some of the upcoming exercises as well as the GPIO extensibility you’re advocating for.
To that end, the shield and Grove connectors exist solely for the extensibility you’re after. With the I2C bus on the right-hand side, you’ve got the capacity to theoretically connect up to 127 ‘son’ devices, which could be other sensors, actuators, or modules, for a standard 7-bit address. The opposite Grove connectors enable plug-and-play connections involving simpler analog / digital IO. While I agree that seating the Nano board into the shield obstructs some connections to its IO, it doesn’t hinder extensibility in the sense that the above options exist and is perhaps more easily forgiven in view of IO hungry camera interfaces CPI, camera parallel interface, and SCCB.
Hopefully this helps to explain some of the thinking behind the kit, but this is only just the beginning. With time and community support, I wholly expect to see plenty of optimization moving forward.
I fully understand where you are coming from. Yes, I did have to manually connect duPont wires for the camera to my Nano 33 BLE Sense board. And, yes, I’ve used a similar camera with simpler direct cabling with the Maixduino board.
