Clock

 https://youtube.com/shorts/slTmWbaungY?si=idd1TFyRJzIdk9W_

NVidia Caterpillar

 

I keep hearing the same subtext when people talk seriously about modern perception systems, and the podcast made it explicit. Perception is no longer about a clever model running on top of generic hardware. It is a full stack problem where sensors, electronics, data, simulation, training, deployment, and iteration speed all matter equally. If one of those layers is sloppy, the system fails no matter how good the neural network looks on a benchmark.

What resonated most is how far we have moved away from the idea that perception starts with data and ends with inference. In practice, perception starts with physics. Photons, vibrations, motion, noise, timing, power stability, thermal drift. These shape the data long before a model ever sees it. If you ignore this layer, you end up compensating with bigger models, more compute, and endless data cleaning. That is not sophistication, it is waste.

This is where the opportunity for making becomes obvious. Instead of building generic robots or chasing full autonomy, the real leverage is in building small, purpose-built perception instruments. A node, not a platform. One sensing problem, one or two sensors, tightly integrated electronics, deterministic timing, clean power, and just enough local intelligence to extract structure from the signal. Everything else can be pushed upstream.

The podcast emphasized simulation and synthetic data as first-class tools, not backups. That only works if your hardware is well defined. When you control the sensor characteristics, the sampling, the noise profile, and the geometry, simulation becomes meaningful. When your hardware is ad hoc, synthetic data becomes fiction. Making your own electronics is what closes that gap. It turns simulation into a usable engineering tool rather than a marketing slide.

From a practical standpoint, this reframes how I think about AI on the edge. The device does not need to be smart in a human sense. It needs to be precise. Timestamping, synchronization, filtering, event detection, compression, maybe a small embedding or classifier. That is enough. The heavy reasoning, training, and iteration live on a workstation or server where iteration is cheap. Edge intelligence exists to reduce ambiguity and bandwidth, not to impress.

The build loop becomes very concrete. Design a small board around a camera, IMU, microphone, or low-cost LiDAR. Get the clocking right. Get the power right. Mount it correctly. Collect data you trust. Augment it with simulation that actually matches the device. Train a narrow model for one task. Deploy it back. Observe failure modes. Revise both the electronics and the model. Repeat. This loop is faster and more educational than any abstract model comparison.

What I take away most strongly is that iteration speed beats theoretical optimality. Teams and individuals who can close the loop from field failure back to retraining and redeployment will always outperform those chasing perfect architectures. Custom hardware accelerates that loop because it removes unknowns. You know what the sensor is doing because you built it.

For anyone interested in #make perception with AI, the path is clear. Do not start with autonomy. Start with perception primitives. Build devices that see, hear, or feel one thing well. Treat electronics as part of the learning system, not a carrier for it. When physics and electronics are handled with care, the AI becomes smaller, simpler, and more reliable. That is not a compromise. That is good engineering.

University of Illinois CS_400: Object-Oriented Data Structures in C++

I decided to take a refresher on my C++ skills.

The University of Illinois (U-C) had a class on Coursera: "Object-Oriented Data Structures in C++"

https://www.coursera.org/learn/cs-fundamentals-1

The funny thing is, that I actually learned C/C++ at the University of Illinois (UIC), just over 20 years ago!

Getting the instructor's code:

Uki@iMac 18:38 Coursera_OO_data_structures_Cpp $ cd ..
Uki@iMac 18:38 _REPOS $ git clone https://github.com/wadefagen/coursera.git coursera-cs400
Cloning into 'coursera-cs400'...

Setting up macOS for C++

I am following these instructions:

https://courses.engr.illinois.edu/cs225/sp2019/guides/own-machine/#macos

Install Apple XCode

$ xcode-select --install
xcode-select: error: command line tools are already installed, use "Software Update" to install updates

IMPORTANT, if you get Xcode errors when running the make command, execute this command:

sudo xcode-select --reset

by the way, I cannot get XCode IDE because my 2012 iMac is outdated and does not support higher macOS:

Getting BREW

$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

the above will take quite a few minutes.

Once BREW is installed, install the following:

brew install ghostscript
brew link --overwrite freetype

 

brew install imagemagick

brew link --overwrite libtool

 

brew install graphviz 

brew install cmake

brew edit valgrind

This will open your default code editor. In the opened file, change the URL in the head section from https://sourceware.org/git/valgrind.git 

to 

git://sourceware.org/git/valgrind.git 

and run the following:

brew update brew install --HEAD valgrind

Test MAKE

$ cd /Volumes/GoogleDrive/My\ Drive/_REPOS/coursera_wadefagen/cpp-std
cpp-std $ make

xcrun: error: active developer path ("/Volumes/SSD500GB/Applications/Xcode.app/Contents/Developer") does not exist
...

Uki@iMac 02:03 cpp-std $ sudo xcode-select --reset
Password:

Uki@iMac 02:07 cpp-std $ make
g++ -std=c++14 -O0 -pedantic -Wall -Wfatal-errors -Wextra -MMD -MP -g -c main.cpp -o .objs/main.o
g++ -std=c++14 -O0 -pedantic -Wall -Wfatal-errors -Wextra -MMD -MP -g -c Cube.cpp -o .objs/Cube.o
g++ .objs/main.o .objs/Cube.o -std=c++14 -o main
g++ cout.cpp -std=c++14 -o cout
g++ cout2.cpp -std=c++14 -o cout2
Uki@iMac 02:08 cpp-std $ open .

Uki@iMac  02:10 cpp-std $ ls -alt

total 96

drwx------@ 1 Uki  staff    16K Aug 12 02:10 ../

drwx------@ 1 Uki  staff    16K Aug 12 02:08 ./

-rwx------@ 1 Uki  staff    54K Aug 12 02:08 cout*

-rwx------@ 1 Uki  staff    54K Aug 12 02:08 cout2*

-rwx------@ 1 Uki  staff    61K Aug 12 02:08 main*

drwx------@ 1 Uki  staff    16K Aug 12 02:08 .objs/

-rwx------@ 1 Uki  staff    26B Aug 10 18:37 .gitignore*

-rwx------@ 1 Uki  staff   368B Aug 10 18:37 Cube.cpp*

-rwx------@ 1 Uki  staff   312B Aug 10 18:37 Cube.h*

-rwx------@ 1 Uki  staff   228B Aug 10 18:37 Makefile*

-rwx------@ 1 Uki  staff   209B Aug 10 18:37 cout.cpp*

-rwx------@ 1 Uki  staff   248B Aug 10 18:37 cout2.cpp*

-rwx------@ 1 Uki  staff   395B Aug 10 18:37 main.cpp*

Uki@iMac  02:14 cpp-std $ ./main

Volume: 13.824

Surface Area: 34.56

Week 2

Week 2 Forum
https://www.coursera.org/learn/cs-fundamentals-1/discussions/weeks/2

2.1 Stack Memory and Pointers
https://www.coursera.org/learn/cs-fundamentals-1/lecture/Iccq3/2-1-stack-memory-and-pointers

I got to use Microsoft Code and Terminal properly

How to make the compiled files execute in the command line?

If you get a similar error, you might have to change the mode to execute the file..

zsh: permission denied: ./addressOf

cpp-memory % chmod +x addressOf
cpp-memory % ./addressOf
Value: 7
Address: 0x7ff7b9eef878

Mounting Microcomputer with LEGO

Let's face it, electronic projects are a workbench tangle of components. 

I have experimented with multiple techniques to mount my projects:

- plexiglass with elements screwed to it

- plexiglass with double sided tape

- plastic containers, eg. tapperware

But for modular building nothing is better than LEGO blocks. The construction is very solid and reconfigurable while on the bench and can be glued together with solvent when completed. And looks fun, too.

I was pulling my hair out how to mount a microcomputer like this I.MX6 as it does not fit in LEGO grid very well. I considered screws and silicon and rubber mounts, but it was not simple, nor elegant.

What is found out to work the best was to cut a notch in corners of LEGO with Dremel cutting disk. Very simple and fast. You can put a drop of silicone inside the LEGO to work as a rubber dumper, if you have any wiggle/play.

I am sure someone has done that before, but this technique was my original idea, and I am very pleased with the results.

#lego #make #bbb #pi

Mounting Microcomputer with LEGO

Let's face it, electronic projects are a workbench tangle of components. 

I have experimented with multiple techniques to mount my projects:

- plexiglass with elements screwed to it

- plexiglass with double sided tape

- plastic containers, eg. tapperware

But for modular building nothing is better than LEGO blocks. The construction is very solid and reconfigurable while on the bench and can be glued together with solvent when completed. And looks fun, too.

I was pulling my hair out how to mount a microcomputer like this I.MX6 as it does not fit in LEGO grid very well. I considered screws and silicon and rubber mounts, but it was not simple, nor elegant.

What is found out to work the best was to cut a notch in corners of LEGO with Dremel cutting disk. Very simple and fast. You can put a drop of silicone inside the LEGO to work as a rubber dumper, if you have any wiggle/play.

I am sure someone has done that before, but this technique was my original idea, and I am very pleased with the results.

#lego #make #bbb #pi