Author: marrs

https://github.com/merlinmarrs/Video-Memory

This project started with an ambitious board combining ADC, DAC and SRAM. 

There were too many issues so I broke the board down into two parts: a memory board and a ADC/DAC board. This allowed me to isolate things and proceed in a step by step way.

I discovered that the memory needed a WR signal inbetween clock address refreshing, and for the second board that my op amp choice was inappropriate and needed to work around it (by using the DAC only as an R2R ladder and skipping the op-amp for the ADC input). 

During assembly I found that several 0 ohm jumpers were causing shorts. I also tore out the 8 pin header but applying too much force accidentally. Otherwise the switch system was very effective to test my understanding of the memory chip operation. It can essentially record a series of button manipulations for about 1.5 minutes.  

Here is my first successful “recording” of a sine wave through the ADC and into SRAM and play back from SRAM through the DAC :

BOARD ERRATA:

-need last bit of address counter (cuts memory in half !)

-more jumpers should be broken out for testing (like alternative op amp for input, clk for various chips, etc.)

-leds burn out when activated and output plugged into 5V at the same time…

-GND and 5V switched on the two boards 🙁

-Wrong op amp spec’d. The ADC1175 suggests the LMH6702MF and a choke between power supplies. 

-caps on all ICs

-the LEDs I set up on the microchip are plugged into ADC…

-Add enable header on microchip board

-power LED on the ADC board

-add a MSB and LSB next to LEDs on memory board **

I calculated how much I could store in the 4K of the SRAM I am currently using, and it would be a single line of a 600×800 screen at 40Mhz pixel frequency…

So what can I do with this ? I could record 4,000 pixels of a static image (i.e. lower the resolution of the image to 100×400 for instance) and then play it back. This would require me to control the sampling of the ADC with the CLK pin of the ADC1175 for every X pixels, somehow synchronized with the VGA in signal (use timing signals of an incoming VGA signal set), or to generate a custom VGA output signal with different timing using the VGAX library. 

Some important references : 

nootropicdesign.com/video-experimenter/build

gieskes.nl/visual-equipment/?file=gvs1

I am looking into what I could draw on screen with only 4K memory at a 20MHz clock.

EEPROM and SD cards are also interesting before reaching the holy grail of magnetic recording media of course…

I have the AT28C256F-15TU EEPROM chip which has 256K x 8 bits (enough to at least store an entire 600×800 static screen) and the ADV7125STZ50 8 bit triple HS video DAC. 

https://www.mouser.fr/datasheet/2/268/doc0006-1108095.pdf

https://www.mouser.fr/datasheet/2/609/ADV7125-1503638.pdf

I’d like to have a standalone arduino VGAX based board (https://github.com/smaffer/vgax) which can output 120×60 pixels and reads from internal SRAM and can record and playback. With 256K I could record a static image on screen at a higher resolution or a low resolution short video.

I have already made an SD card image saving board: 

Just realized what I’m trying to do is called a frame grabber and it’s a massive PCB :

https://en.wikipedia.org/wiki/Frame_grabber#:~:text=A%20frame%20grabber%20is%20an,or%20a%20digital%20video%20stream.&text=Historically%2C%20frame%20grabber%20expansion%20cards,to%20interface%20cameras%20to%20PCs.

*********************************************************************************

I have designed a similar memory board but using a 256K EEPROM chip in place of the  SRAM and with VGA connectors to begin testing images. (There do appear to be larger SRAMs, going up to 16MB. There are obviously large flash memories in SD format going into the GBs which may also be interesting to play with).

-Added out VGA to work with VGAX library (not sure if need a second microchip to handle just the memory stuff?)

-Added a 16MHz resonator

-With two 8 bit counters to have the full 13 bits to control this time.

-EEPROM will keep a recording after power down.

-can control buffers with microchip

Just learned that EEPROM is probably the slowest…

Just a thought but I could save control signals for the 0c74 instead of saving actual pixel information…

*************

First test (WORKING):

int switchState = 0;

pinMode(6, OUTPUT); // CLK LED (*)
pinMode(7, OUTPUT); // CLK

pinMode(10, OUTPUT); // WR/RD SIGNAL TO SRAM
pinMode(A3, INPUT); // WR/RD SWITCH (WR HIGH, READ LOW)

pinMode(8, OUTPUT); // WR LED
}

// the loop function runs over and over again forever
void loop() {

switchState = digitalRead(A3);

// check if the pushbutton is pressed.
// if it is, the buttonState is HIGH:
if (switchState == LOW) {
// WR selected on switch so turn WR LED on and send a LOW to SRAM

digitalWrite(8, HIGH);
//
digitalWrite(10, HIGH);
digitalWrite(6, HIGH); // 
digitalWrite(7, HIGH); // 
delay(10);
digitalWrite(10, LOW);
digitalWrite(6, HIGH); // 
digitalWrite(7, HIGH); // 
delay(10); // 
digitalWrite(10, LOW);
digitalWrite(6, LOW); 
digitalWrite(7, LOW); 
delay(10); // 
digitalWrite(10, HIGH);
digitalWrite(6, LOW); // 
digitalWrite(7, LOW); // 
delay(10); // 

}
else {
// READ selected on switch so turn WR LED OFF on and send a HIGH to SRAM
digitalWrite(10, HIGH); // STAYS HIGH THE WHOLE TIME
digitalWrite(8, LOW);
//
digitalWrite(6, HIGH); // 
digitalWrite(7, HIGH); //
delay(20); // 
digitalWrite(6, LOW); // 
digitalWrite(7, LOW); // 
delay(20); //

}

}

This is what it produces:

Second test (WORKING): 

int switchState = 0;

// the setup function runs once when you press reset or power the board
void setup() {
// initialize digital pin 13 as an output.
pinMode(6, OUTPUT); // CLK LED (*)
pinMode(7, OUTPUT); // CLK

pinMode(10, OUTPUT); // WR/RD SIGNAL TO SRAM
pinMode(A3, INPUT); // WR/RD SWITCH (WR HIGH, READ LOW)

pinMode(8, OUTPUT); // WR LED
}

// the loop function runs over and over again forever
void loop() {

switchState = digitalRead(A3);

// check if the pushbutton is pressed.
// if it is, the buttonState is HIGH:
if (switchState == LOW) {
// WR selected on switch so turn WR LED on and send a LOW to SRAM

digitalWrite(8, HIGH);
//
digitalWrite(10, HIGH);
digitalWrite(6, HIGH); // turn the LED on (HIGH is the voltage level)
digitalWrite(7, HIGH); // turn the LED on (HIGH is the voltage level)
delayMicroseconds(1);
digitalWrite(10, LOW);
digitalWrite(6, HIGH); // turn the LED on (HIGH is the voltage level)
digitalWrite(7, HIGH); // turn the LED on (HIGH is the voltage level)
delayMicroseconds(1); // wait for a second
digitalWrite(10, LOW);
digitalWrite(6, LOW); // turn the LED on (HIGH is the voltage level)
digitalWrite(7, LOW); // turn the LED on (HIGH is the voltage level)
delayMicroseconds(1); // wait for a second
digitalWrite(10, HIGH);
digitalWrite(6, LOW); // turn the LED on (HIGH is the voltage level)
digitalWrite(7, LOW); // turn the LED on (HIGH is the voltage level)
delayMicroseconds(1); // wait for a second
// wait for a second
}
else {
// READ selected on switch so turn WR LED OFF on and send a HIGH to SRAM
digitalWrite(10, HIGH); // STAYS HIGH THE WHOLE TIME
digitalWrite(8, LOW);
//
digitalWrite(6, HIGH); // turn the LED on (HIGH is the voltage level)
digitalWrite(7, HIGH); // turn the LED on (HIGH is the voltage level)
delayMicroseconds(1); // wait for a second
digitalWrite(6, LOW); // turn the LED on (HIGH is the voltage level)
digitalWrite(7, LOW); // turn the LED on (HIGH is the voltage level)
delayMicroseconds(1); // wait for a second

}

}

And here are some shots of what three different speeds (10ms, 10microseconds, 1 microseconds) as delay in the Arduino code :

***********************************************************************

Third test (NOT WORKING):

I recorded a sine wave at 100KHz (with WR activated on the microchip board) with the ADC being clocked at 10KHz. I made sure I had the ADC selected with the right buffers and then sent this 8 bit sequence to the memory where I recorded it with a new Arduino code:

void setup()
{
DDRD = B11111111; // set PORTD (digital 7~0) to outputs
DDRB = B11111111; // set PORTB (digital 7~0) to outputs
}

void loop()
{
if((PINC & 0b00001000)==0)
{
PORTD = B11111111; // set PORTD pins (digital 7~0) high
PORTB = B00000000; // set PORTD pins (digital 7~0) low
PORTD = B00000000; // set PORTD pins (digital 7~0) low
PORTB = B11111111; // set PORTD pins (digital 7~0) high

}
else
{
PORTB = B00000100; // WR PULLED HIGH SO TURNED OFF
PORTD = B11111111; // set PORTD pins (digital 7~0) high
PORTD = B00000000; // set PORTD pins (digital 7~0) low
}
}

/*
CLOCK:
_____ _____
| ` | | |
___| |___| |____

WR:
_________ ____________
` | |
|___|

*/

I then switched to the DAC with the buffers and switched into READ mode on the microchip board.  Now the 8 bit sequence was being translated back into a sine wave. I took this sine wave and amplified it with an audio amp and sent it to the three color channels combined with an arduino running the VGAX pattern code without the colors plugged in and only H and V SYNC.

I got this on the screen :

Here is the tentacular and unoptimized setup :

To make this actually easy to use, I need to:

-have the microchip control the buffers and the ADC clocking based on the switch state.

-have the memory and adc on a single board.

-have a VGAX out setup integrated into the memory board.

-have an op amp on the ADC board to amplify the output signal !!

-have a dial change the speed of the playback / sampling of recording.

*******************************************

I added an external crystal and set the AVR dude Fuses to : Ext. Crystal Osc.8.0 – ___MHz 16K CK/14 CK + 65 ms. 

I added F_CPU 16000000UL ABOVE the #include. 

Forgot that if you don’t add 0b before a binary number nothing happens with the pins !

Here is the code that still isn’t working :

/*
* eeprom board v.2.c
*
* Created: 06/02/2022 09:19:50
* Author : Jonah
*/

#include <avr/io.h>

int main(void)
{

DDRC = 0b00000000; // PC3 is the switch for WR (0) or RD(1)

DDRD = 0b11111111; //PD5 is CLK and PD4 is !OE

DDRB = 0b11111111; //PB0 is the LED and PB2 is !WE

while (1)
{

/*
BYTE WRITE: A low pulse on the WE or CE input with CE or WE low (respectively) and OE high initiates a write
cycle. The address is latched on the falling edge of CE or WE, whichever occurs last. The data is latched by the first
rising edge of CE or WE. Once a byte write is started, it will automatically time itself to completion. Once a
programming operation is initiated and for the duration of tWC, a read operation will effectively be a polling operation.
*/

if((PINC & 0b00001000)==0) // WRITE MODE: (CE -> TIED LO); !WE -> TOGGLE ; !OE -> HI ; CLK -> TOGGLE
{
PORTD = 0b00010000; // !OE -> HI ; CLK -> LO
PORTB = 0b00000000; // !WE -> LO
PORTB = 0b00000001; // !WE -> LO (to make the pulse width at least 100ns)
PORTB = 0b00000101; // !WE -> HI
PORTD = 0b00110000; // !OE -> HI ; CLK -> HI (next address must come a max of 50 ns following !WE going HI?)

}

/*
READ: The AT28C256 is accessed like a Static RAM. When CE and OE are low and WE is high, the data stored at
the memory location determined by the address pins is asserted on the outputs.
The outputs are put in the highimpedance state when either CE or OE is high. This dual-line control offers designers flexibility in preventing bus
contention in their system.

*/

else // READ MODE : (CE -> TIED LO); !WE -> HI ; !OE -> (TOGGLE ? OR JUST LO?) ; CLK -> TOGGLE
{
PORTB = 0b00000101; // !WE -> HI
PORTD = 0b00100000; // !OE -> LO ; CLK -> HI
PORTD = 0b00000000; // !OE -> LO ; CLK -> LO
}
}
}

**********************************************************************************

One question I have is: does the EEPROM require OE to go on and off when reading unlike the SRAM I worked with in the previous board ?

Another question is, how long does the EEPROM need to write a byte ? It talks about “access times of 150ns”…?

Is it OK I have CE tied low the whole time ?

As a next step I will try doing all of this but very slowly to see if that works. 

*EDIT : tried slowing everything down and I’m still not able to load anything into the memory :(. I just get 5V and little pops of ground after writing ground into every cell of the memory. This is after changing !OE toggle and always ON also. 

I did get the VGAX code running though so at least that works. 

ERRATA:

-the labeling of WR and RD are confusing, when the switch is to the RD side it is in WR mode etc. 

-the VGA parts are COMPLETELY wrong. 

-I need to order 16MHz of this format (I took one from a dead Arduino board). 

-the text is too small and came off during cleaning.

TROUBLESHOOTING AT28C256 EEPROM:

-Need to wait a second before doing and writing or reading,

-Need to either wait the maximum time for the EEPROM to write (Write Cycle Time Max AT28C256 = 10ms) or poll 1/0 7 to wait until it matches what you sent it before starting another write cycle.

-The device may be locked (even though the devices should ship unlocked) :(. The unlock sequence is :

LOAD DATA AA
TO
ADDRESS 5555

LOAD DATA 55
TO
ADDRESS 2AAA

LOAD DATA 80
TO
ADDRESS 5555

LOAD DATA AA
TO
ADDRESS 5555

LOAD DATA 55
TO
ADDRESS 2AAA

LOAD DATA 20
TO
ADDRESS 5555

LOAD DATA XX
TO
ANY ADDRESS(4)

LOAD LAST BYTE
TO
LAST ADDRESS

************************

Here are some thoughts I have on the SRAM device :

Do I want addressed to loop or not ? (Add inverter if want to loop)

  >> Make it optional with a jumper, this expands the possibilities of experimenting.

Another idea is to start with the actual solution (two small servos) and make it look better. It’s sturdy and already balanced. It just needs a hinge and a tilting arm:

With a makeshift hinge and tilt arm:

This would only require an Arduino mini pro and some super caps charged by a solar panel through a diode.

Some other more simple options:

For a miniature 2DOF.

A mini 1 DOF.

  The 2 metal gear motor design I was working with early on.

*****

Here is a super simple two servo motor controller that recharges supercaps through a diode:

This works with the code below as a test:

#include <Servo.h>

Servo myservo1; // create servo object to control a servo

Servo myservo2; // create servo object to control a servo

int pos = 0; // variable to store the servo position
int threshold = 100;

void setup()
{
myservo1.attach(5); // attaches the servo on pin 9 to the servo object
myservo2.attach(6); // attaches the servo on pin 9 to the servo object
}

void loop()
{

if (analogRead(A2)-analogRead(A3)>threshold)
{
myservo1.write(90);
delay(15);
}

if (analogRead(A3)-analogRead(A2)>threshold)
{
myservo1.write(-90);
delay(15);
}

if (analogRead(A4)-analogRead(A5)>threshold)
{
myservo2.write(90);
}

if (analogRead(A5)-analogRead(A4)>threshold)
{
myservo2.write(-90);
}
}

This is the monster in all its tentacularity:

****

Testing the barebones circuit with the solarbotics white DC gearmotors and the SMD solar engine. It works with only two mini solar cells and the SMD cap as long as the sun is medium strong!

This is exciting as a result (but I just needed the change the motor wire polarity):

Here’s what the circuit looks like:

This suddenly stopped working and I did the following things:

Checked to see if the cap was charging, if the voltage monitor was triggering (and I manually triggered the MOSFET to see if the motor fired), the voltage at the midpoint between the two photodiodes, and if there were any shorts.

In the end I replaced the zener with a normal SMD diode which I found, replaced the photodiodes with green LEDs because one lead was broken on the photodiode, and then discovered the motor was broken (or at least the blue wire was disconnected on the inside)! It gave me a chance to look inside the tiny gear boxes of the motors though: 

Here is the, once again, working prototype:

I would like to be able to tune the midpoint between the LEDs. I would also like smd light sensors. 

Some options for solar panel and motor assemblies:

Here’s with SMD LEDs soldered on:

Not sure why but the thing is only turning clockwise…

I tried the following things:

1. A 10K trimpot (with each photodiode into each side of the resistor and the variable pin going to the logic chip). The trim pot at either extreme does indeed make the circuit turn in the opposite direction. However, in the middle it stops either side from firing.
2. Replacing the photodiodes with Silicon PIN Photodiode BP34s, green LEDs 5mm, Green SMD LEDS, and LDRs.
3. changing the ground of the photodiode pair to the ground of the capacitor instead of the ground connected to the floating connected to the MOSfet.

Just found this image here (http://solarbotics.net/library/circuits/bot_popper_240.html) which seems to imply I could use phototransistors also:

Looking at other Smart Head circuits, it looks like the + side of the photodiode pair is connected directly to the Vcc but that the negative side is connected to the “local” ground, not the negative of the capacitor. However, there are also counter examples…

I tried just setting up the dual photodiode circuit on a breadboard. Two photodiodes , two LDRs etc. They each move from a midway value up or down depending on which device is in the dark. However, they don’t always have 1/2V as a midpoint, which appears to be the important threshold point for the oscillator. **EDIT** I think what they meant was half of VCC not 0.5V. I could try to find the exact threshold voltage that is the balance point with the power supply?

2.25V for my desktop breadboard version of the circuit while supplying 4V for the solar panel. 2.85V was the threshold with solar panels at 5V. It also has a dead zone where neither motor will fire if it is perfectly in the middle. 

For the soldered version the threshold is around 1.3-1.4V when being fed 4V as solar panel. 

At 3.5V solar panel supply, I have a lower threshold bound of 1.25V and a higher bound of 1.4V. In the deadzone neither direction turns. 

At 3V funny things happen. It will only turn one direction unless I suddenly make the input 0V. This might explain why my circuit is behaving strangely! I am using a 2.92V voltage supervisor so I don’t think my current circuit is ever going to work. 

I should replace it with a higher voltage threshold like this one perhaps: https://www.mouser.fr/ProductDetail/968-ISL88001IH46ZT7A 

In the meantime I can use a voltage divider like I did for the 1381. 

Here’s the scope output attached to one lead of the motor. The fat, fuzzy part is when the motor is not turning and the threshold is reached. Either side it sends between 1.5-2V to the motor turning one way or the other.

Setting up my own little trim pot between the LDRs I was able to tune them to the correct voltage threshold and everything works well on a breadboard at least.

Here is the 74AC240 datasheet: 

Checked out the 74AC240 datasheet, for 3.5V the threshold should be between 0.9V-2.1V.

****

Version 2 of the board has trimpots for the voltage trigger and the light sensors (which are now SMD and on either side of the board):

Here are the parts laid out with the new board:

Post-soldering. The size of the board versus two small solar cells:

I had to put electric tape under the trim pots because contacts were exposed underneath…  The full assembly:

****

Found this online here (http://www.smfr.org/robots/robot_images/dualsolarhead_schematic.png): 

It uses the solar panels as the light sensors! It also lays things out in an easy to understand way (the midpoint is the boundary between what the inverter sees as HIGH or LOW. Once the solar engine has enough power this decision of HIGH vs. LOW then powers the motor through six remaining gates – presumably to increase the current as each pin seems to be limited to 75mA according to the datasheet above?).

***

Testing V.2:

I can get 3.5+ volts (4V outside in full sunlight even) with the current setup of two solar cells + little cap!

BUT…When I short the voltage supervisor 5K trim pot the motor fires, but even in its least resistance position the supervisor is not triggering…It is also only doing mini movements, not full shots. I removed the trim pot and now it behaves normally. I don’t understand why the trim pot doesn’t work when it was flawless with the benchtop power supply…

With a 1M trimpot the variable voltage trigger does work just as expected, however! I moved it up to 3.5V ish.

The 5K trim pot for fine tuning the light sensors also does not appear to work. Also doesn’t work with a 1M and two green LEDs…

I tried using the two solar panels as sensors as suggested in the found circuit and it appears to work, there remains the same problem of how to tune the voltage level however if my trim pot solution doesn’t work. 

***

I think I need to order 74AC240s (I think the 74LS540s I am using might be slightly different in terms of their HIGH/LOW thresholds) or voltage triggers for 3.5V+. This is a nicely tuned circuit that seems hard to mess with.

Just a reminder of how much the complexity has been reduced in this project!:

***

I have realized I need to understand the circuit I am working with better in order to tinker with it. 

First thing, the 74LS540 that I am using has a minimum voltage of 4.5V! It also can only supply 45mA max as an ouput if I understand correctly. However, I also have a 74F244D octal buffer which works as low as 2V. However it is Bipolar and not CMOS technology like the 74AC240 AND more importantly, it has non-inverting outputs. Clearly getting the right logic chip and family is an important element and not a detail for this circuit…

So, the LDR “photo bridge”. After testing 10 we had lying around I arrived at these average values:

Here’s some R Thevenin calculations (Thanks to Learning the Art of Electronics!) to figure out what size pot I can afford to pull up or push down the midpoint from the LDR divider:

And here’s the current logic circuit in a more understandable format:

****

Did some tests, looks like I need to bring the midpoint DOWN in my circuit:

Yellow is the cap voltage (3.42V) and green in the midpoint (2V) with equal light on both phototransistors. 

This scope image shows first both photodiodes in light, then the left (connected to GND) in darkness, and finally the right (connected to VCC) in darkness:

Without even needing to take any measurements it’s evident that the midpoint is too high. This causes the motors to always turn the same direction when the light intensity is equal between the two phototransistors. I flipped the photo transistors and observed the same effect so I think it’s the circuit not the difference between the phototransistors.  

This scope image shows me adjusting the phototransistor trim pot. (Fully attenuating on the left, halfway in the middle and then fully open on the right). 

And here’s testing with the middle threshold covering and uncovering each phototransistor:

This shows that the 10K trimpot effectively drops the entire midpoint! I can effectively dail in the midpoint to exactly half of VCC now (3.42 Vcap, 1.71V threshold)!:

Now the machine is not turning in only one direction! But it also might need some resistors for when the two photodiodes are both seeing bring light. I also need to replace the LS540 with an AC240 because I am currently operating outside the maximum minimum voltage of the IC. It would also be nice to use the solar panel as a sensor and thereby reduce the part count (I could still tune the midpoint in the same way once I determine which way the imbalance is – it would also solve the shorting problem in high light). 

I varied the pot and everything is working as expected. I also added heat shrink to the phototransistors. Here is a video:

I tried some 2DOF designs but I think this needs to stay MINIMAL and the force of the project, if it comes, will come from the array more than individual complexity. Plus they already seem imbalanced and more likely to malfunction…

Some tests with the solar panel voltage divider:

Here’s what it looks like when I change the solar panel midpoint with the 10K trimpot:

Here is the solar panel midpoint trim pot all the way to one side:

Here is the solar panel midpoint trim pot all the way to the other side (not sure why it goes all the way to the ground here only):

Here is me putting one panel in the shade, then the other. The difference is not massive.

The problem is that now I fall into a large deadzone where no movement happens in the middle. I’m trying to find the right combination of voltage trigger trim level and solar midpoint level but it’s not easy without sunshine…

****

Here’s the cost per unit of this design:

74AC240: 0,462 €

0.2F cap: 1,21 €

solar cell: 3.56 € (1.78 € x 2)

micro gear motor: 4.25€

voltage trigger: 0,356 €

diode + 0.47uF cap: 0,1€

PCB: ?

Total: 9.938€ + PCB cost

****

I have now a 1M trimpot on the solar midpoint and have added a 1M between the midpoint and VCC to try to balance things out.

I think 3×3 is better than 4×4 ? 5×5 would be out of control.

****

Working towards simplifying the dual servo sun seeker. Here is a post for controlling servos without a microcontroller:

https://www.pololu.com/blog/18/simple-hardware-approach-to-controlling-a-servo

Could use LDR pair to replace pots inside the servos, based on ideas from Hackaday post shared with me by Paolo Salvagione:

Light Tracking Robot Relies on LDRs

***

Went back to the super simple business card sun shaker and added some feet. I also tested the new 0.2F caps and they work with outdoor light but might be too tough to charge with indoor light (unless it’s actually bright then they work fine). After Paolo Salvagione’s comment about using a smaller motor to rotate the device, it occured to me that I could use the vibe motors in two directions to create movement that follows the sun:

****

Ordered this motor: 

Here is a new design with (human) adjustable tilt. It has more of a “pro” vibe. The motor adds 5 euros to the total cost of the machine bringing it up to 15 euros:

****

Looks like the trick with the light sensing is just to put the photodiodes behind the board so that the shadow cast by the sun creates a clear preference for one side or the other. They can be bent around a little bit to be perfectly tuned but it also adds a bit of idiosyncracy to the ‘bot. So it doesn’t appear that I need a trim pot for this option. I’m not sure how to create the same contrast with the solar panels as putting either in the shade is obviously not a good idea. Pointing them in different directions creates some difference but not a great deal.

****

I’ve redone the circuit for the 74AC240 and make it more compact:

Here is my next design with the smaller DC gear motor. I’m imagining a soldering a pin to the PBC in order to attach the pivoting arm to it. Otherwise the issue is how to make this attachment without creating a whole frame and bumping into components etc. It has a small M2 bolt to fix the print to the motor and to adjust the angle:

I’ve made a cleaner video of the first prototype:

Continuing the project of making a small solar tracking device.

****

Idea to simplify the circuit drastically and make the 3D model a bit more robust and less fragile so it is far easier to assemble and won’t topple over (while hopefully maintaining some elegance…) 

-Battery-powered (and possibly solar recharging through very simple circuit):

plus Attiny with two steppers only powered directly from output pins (max 40mA and danger of kick back which might be solved with diodes) and no light sensing – just the almanac algorithm for sun following. *

*(Remember you can test the stepper resistances to know which are pairs!)

Tried powering a stepper directly with an Atmega using the Stepper library in Arduino with a bunch of different step and speed values – if it turns at all it’s extremely weak…So this doesn’t appear to be an option.

Tried powering an atmega328 directly to cap and solar panel through diode, in medium sun there is no action. With bright sunlight it manages to power up despite blinking a blue LED every secon. I could try with the sleep timer I recently acquired (https://www.adafruit.com/product/3573). Or maybe a simple sleep code will be enough. This seems like a viable option which would simplify the circuit considerably.

Another cheap and simple option is the ULN2003, but this requires 5V to function unlike the low power DRV8833 I have. 

***

Tried driving the stepper gearmotor chain drive and it moves very smoothly and almost imperceptably. 

I dug up some DC DVD raft drives, they are nice mechanisms:

The black rack was attached to the raft. 

I tried powering these with Wilf’s SPSH circuit and the bearbones solar head and they were too big a motor to be powered unfortunately. I could still try to increase the 1381 trigger level with a resistor though…

I’ve redesigned the microchip version of the board to make the wiring to the stepper much easier this time. I’ve also added two caps to smooth out the motor supply. 

And here is a more robust version of the previous two stepper, this one has two parallel bars, a more robust hinge, and the lower bearing is encased completely for more stability hopefully. I am also getting rid of the lead screw plastic piece and trying to replace that part with a thin metal rod. In general it’s simplified and a bit thicker all around :

I am using a dremel to clear out the holes before inserting things and this is reducing shattering of the more fragile white resin. 

The bottom bearing:

Part of the solar panel hinge:

Only one of the two stepper drivers worked on this board but I haven’t found the issue yet…I wonder if back reverse polarity I destroyed it by accident or over heated it during soldering. I’m going to replace it with a fresh one and see if that changes anything.

Here’s the assembled machine:

Here is a look at some of the technical details:

A different panel orientation option: 

Comparing the two versions (the newer is far more compact and stable but less playful and off-beat/asymmetrical):

Check out the angle range, it’s better than I expected!

ERRATA:

1. The idea of putting a pin accross to act as the lead screw is not working with only one side screwed in. AND the lead screw platform is impossible to insert into position (I had to break it in half and glue it back together once in position). I should definitely not try to go under the lead screw, with the nut that holds the pin, it actually makes contact with other nuts holding the whole linear rail assembly. I think I should go back to integrating the existing plastic lead screw – aesthetically it adds more flavour and asymmetry.
2. The part that attaches to the panel should be one connected part because this gives more surface to attach to and more rigidity. (X)
3. There is a volume which enters into the bearing socket that I needed to remove with the dremel. (X)
4. The three bottom holes for screws are not evenly spread out around the circle. (X)

POSSIBLE CHANGES:

1. Tensioner for bottom chain or larger bottom gear?
2. The top hinge is too symmetrical for my liking but otherwise it’s super stable.
3. Transparent resin is definitely nicer.
4. The bottom nut needs a tiny bit more room, but it just works.
5. The bolts are hitting the bottom stepper gearmotor.

Here is a new version which solves the errata, but it looks hideous:

I am considering returning to a one bar setup. I am also considering how I can make one version of this device that will work for the different linear actuating steppers and the different rotational motors (the micro steppers and DC gear motors have the same face plate thankfully). The top and bottom of device are also not connected (so varying heights of linear drives can be accomodated). Should one single design be able to work with belt drive or chain? I think I should now focus on producing a bunch of these.

Here is how the little plastic parts that act as lead screws work:

There are all kinds of shapes but in the end they all appear to have one main screw location and a bunch of other nibs and slots to help with alignement. I can include a sliding slot for the main screw in the 3D print but I may use a dremel to adapt it to different nib locations. 

I’ve revisited the version 1 and have made the following changes:

1. I’ve kept the more robust base from version 2.
2. I’ve revised the lead screw plastic part holder and made the print compatible with the highest number of these peices and allowed for longer stroke.
3. I’ve kept the magical setup that allowed for a great variation in the panel angle.
4. I’ve kept the circular base which is more stable and made a larger base gear so it looks more stable. (The pitch of chain I am using is 0.1227″ https://www.mcmaster.com/miniature-roller-chain-sprockets/pitch~0-1227/)
5. I adjusted the motor so the bolts are no loner hitting the bottom stepper gearmotor.

****

Wire management:

I like the ribon wires from the CD drives and the mini locking sockets and plan to use them:

The top option seems sensible.

Here the bottom motor ribbon is going to be super stretched when the panel is at full extension in angle…

I like the asymmetry of the second option, it implies that the lead screw and hinge action is taking place on one side and the electrical connections on the other side.

(I’m just realizing that some of the ribbon cables that come with the stepper linear drive are not very long + the brown/orange doesn’t go super well with the white. Should I replace those cables with white ones so that everything is the right length and homogenous?)

There is also the possibility of folding the ribbon cable…

I’m trying to find this product (it seems to be called “flexible flat ribbon cable”) but not having luck on Farnell or Mouser (*correction: https://www.mouser.fr/ProductDetail/Wurth-Elektronik/687606050002?qs=qR1qlUC5%2FYSp8nXHAtNchQ%3D%3D) …Here it is on Ebay and Amazon:

The other option is to harvest wire from the old CD drives I have, the wire lenghts seem to vary from 8-11cm.

Some solar panel options:

****

Next version sucesses:

orienting parts so that the supports don’t touch faces that will be seen is a good idea, it saved the bottom platform from pockmarks.

Errata:

1. The main issue is the lead nuts. They are massive and therefore reduce the stroke considerably. Most have a setup where they push against the leadscrew and twist the sliding cam which is now only fixed to one rod.  I should try to design the nut myself, if the solar panel is in the middle it is hidden in any case. The other option is to find another one in a million lead nut that works like the one in version one where it doesn’t push against the cam / use two bars. (X)
2. Somehow the ratio of arm lengths is producing a totally different range of angles, mostly in the negative direction! (X)
3. the layer on top and below of the bearing is too thin and comes out wavy. (X* I did the top visible part but not the bottom).
4. missing a subtraction around the collar of the bottom stepper motor shaft. (X)

Possible changes:

1. all black hardware would be nice. Or perhaps all white?

******

Modeling the lead screw:

The threads themselves:

I want it to be possible to adjust this thing so I am planning to use a stack of washers to accomplish this. I am also adding a notch in the purple volume to prevent the green volume from rotating. It should also mean that the green volume can be made to accomodate different threads and the purple volume will still work regardless (i.e. it’s modular).

The backside leaves space for a nut to fix the green piece in place at the right height.

I’ve also adjusted the angles to match the version 2 as exactly as possible this time:

Here is the finished version 3:

Some quick ideas about how this project could be displayed in an expo:

1. I can make a bunch of solar critters that react to the sun in different ways (sweeping in circles, following the sun but staying in place, making sound by tapping the ground or playing a song, etc.). This is the kind of ludic, “diversity of nature” bio-inspired option. The robots are indifferent to one another but occupy the same space. I’m not sure how to chose the materials but maintain difference/cohension of the group but presumably I could pick a kind of 3D printing and use the same motors.

2. Make one such critter (like the sun follower) and create an array of them in a given space and watch the group effect of their behaviour. This is kind of obvious but at least it’s abstract and sober, hopefully fitting in my portfolio with my other more abstract/representational work. It would also be easier to mass produce one design than to make a bunch of one-off designs I think.

And here is the BOM so far:

And here is the newest build:

ERRATA:

1. The lead screw does not work. It is not perfectly aligned with the threaded rod and the system for holding it tightly in place is not working. I think I need to put the lead screw on the bottom side of the threaded rod and have a tensioning mechanism on the front (accessible) side.
2. The angles are still wrong. If I make the top arm (that is glued to the solar panel) shorter I think it will improve.

I’ve put the lead screw on the back of the threaded rod and inserted alignment rods and increased the borders to hold the top piece in place:

****

The solar panel angles are fixed! With two of the threaded nut sides making a sandwich it does actually work as a lead screw nut (even though it really doesn’t look nice) !

***

Thoughts from artist Paolo Salvagione:

1. Make a power budget (what does everything i.e. steppers, microchips, drivers use when not on, when on)
2. Run motors 24/7 for weeks before to test that nothing falls apart.
3. Replace bolt hinges with flanges or miniature bearings from McMaster Carr. (The smallest available at a reasonable price is 5mm OD no flange).
4. Try pulling up everything to the top beneath the board and alternatively pushing everything else to the ground to create a sunflower.
5. Think about the center of balance of the machine and how you can place it directly over the pivot point (or move it there with weights).
6. What kind of choreography would I like to see here.
7. Alibaba has super inexpensive solar panels that look great.
8. Could the array relate to different light sources which exist in a kind of solar system around the plinth.
9. How can visitors experience this piece at different distances (“layers” of experience)?
10. Medium-runs of a finished design are easier than making a ton of one offs or mass producing.
11. It’s possible to order flexible PCBs from PCB Way.

****

Some thoughts on the layers possible:

I have found a few 10mm OD bearings and will redesign the arm portion with these:

I’m not totally satisfied with the bearings in the design (McMaster has perfect 5mm bearings that are reasonably priced but they don’t ship out of the U.S.).

****

Calculating the balance point with help of this site: https://www.school-for-champions.com/science/gravity_center.htm#.X2B-cFUzaUk

CG = (aM + bN + cP)/(M + N + P)

Seems like I should try to keep the solar panel light in general (under 12 grams?), but that I have the option of adding some weight above the stepper in the rear. In the other axis I can shift the solar panel a bit to the side to compensate for the weight of the bearings in the arms. 

****

New version with arm bearings:

It was hard to attach the solar panel to that arm model so I switched it for one with mini bolts:

I don’t like the look of the three wide and narrow bearings so I am trying to hide one under the panel and switch up the second by putting the black bolt through it. One of these only would look great but three is too much.

A new design with McMaster 5mm bearings (I can in fact order them it would appear). In one I keep a single large bearing and in the other all the bearing are small:

Making a third prototype to test the following things:

1. Durable resin for everything but especially for the lead screw.
2. Adding flanges to hold the current bearings in place.
3. Slight tweak to the currently improvised lead screw design.
4. Fix angles again with shorter arm.
5. Hiding the other bearings a bit under the panel.
6. Making a third so that I can begin testing the “swarm” effect of the robots actually moving.

****

I began two stress tests based on Paolo’s advice:

Some things to note:

1. These are so much fun, people visiting see what you’re doing as Paolo suggested!
2. It fights anxiety – you know if it will work or not.
3. Working for 1 minute is not the same as working for two weeks 😉

Unfortunately there is a serious issue: The linear drive is drawing 600mA at 5V to move up and down…I should try to mess with the steps and speeds to see if I can get this down. The rotating motor is drawing less than 150mA. 

Looking on Alibaba, the most popular size of smaller panel is 156mmx156mm.  But also found some 47×47:

and some 55mmx14mm

37×21.8×1.1mm 

Here are the best links I’ve found so far:

https://www.alibaba.com/product-detail/55x14mm-3-0V-7uA-dim-light_60585863880.html?spm=a2700.galleryofferlist.0.0.43be4630X6CXwJ

https://www.alibaba.com/product-detail/Dim-Light-Amorphous-Silicon-Thin-Film_208238751.html?spm=a2700.details.deiletai6.5.561929devzX1BP

https://www.alibaba.com/product-detail/3V-10uA-Dim-Light-Amorphous-Thin_62187655652.html?spm=a2700.details.deiletai6.1.561929devzX1BP

https://www.alibaba.com/product-detail/37×21-8mm-6V-2mA-outdoor-used_60506651563.html?spm=a2700.galleryofferlist.0.0.2430367cO11E7R&s=p

I sent my first email: 

Hello,

I’m a research engineer at the Universite of Paris Sud in France and an M.I.T. graduate.

I’m working on a low-power solar follower product and reqiure small cells like yours to create a series of panels (with each an array of 5×2) to combine with an energy harvesting IC.

I am interested in your product and would like to request a sample if possible to test with my setup.

Thank you ,
Jonah Marrs

*********

Easy stepper motor driver can drive both steppers at around 150mA at 5V with no load. 

The DRV8833 with correct step and speed settings can drive the linear with the plastic lead screw found in the CD drive at around 360mA but has a super high idle current of 600mA. It gets super hot as a result. The DRV8833 cannot drive my lead screw setup however… Basically there is too much friction in my lead screw design currently. So, the conclusion is that it’s possible to drive this thing if I put the driver to sleep and I use the existing lead screw.

I am leaning towards using the found CD drive mechanisms (because they are perfectly made to minimize friction etc. already and look super cool) and add a second bar parallel to the first to improve stability and compensate for the rotating that the plastic lead screw wants to do.

I’m also adding another bolt to the bottom angle bearing, and looking for some 3mm bushings to add to the sliding portion. Here seem to be the two primary options:

The side by side bars on the left are less flexible with different found lead screws as the bolt location can’t move much to either side. It also makes the front part flatter and longer, whereas the bar behind makes the design feel more three dimensional and compact. 

I prefer the bar behind. 

Bending joints options:

I like the asymmetry of not having the top and bottom joints unaligned in elevation and in plan views, it feels more dynamic and optimized. I like the bottom bearing being centered with the cam. 

Hopefully this version will allow me to do some stress testing with the tilt mechanism.

Here are the parts laid out:

The assembly turned out well:

ERRATA:

1. The lead screw is a tiny bit too high above the threaded rod, I had to carve out some material with the dremel…
2. The elbow joint connected to the cam can’t work with a captive nut the way I originally concieved but it can work with the cap of the screw in the place of the nut.
3. The set screw for the sprocket needs to be almost flush with the sprocket surface to not hit the bearing squeezing screw. The bearing squeezing screw between the parallel bars needs to come from the top not the bottom or else it interferes with the chain. 
4. I think I need to shift the two bolts that hold in place the bottom motor 90 degrees. And I may need to add a little circular band to keep this motor straight.  A tiny drop of hot glue solves this…
5. The solar panel surface is not flat but tilts inwards.

I got the test set up working again with two Easy Stepper Motor Drivers (with Enables and 5V+ connected also) this time. Now the bottom motor is driving 100mA and the linear is pulling 200mA. Both are cool to the touch. However, there is a little bit of power lacking for the linear lifting motor and it is skipping some steps. Switching to 1/4 instead of 1/8 microstepping, and making sure all the bearings are set up smoothly, appears to mostly fix this though.

Some experiments taking nicer photos:

A with and without solar panel gif:

*****

I’m doing a next design based on the observation that the motor is struggling to pull up the solar panel and that the weight could be repositioned closer to the center of gravity and rotation axis. It’s more sunflower like, and the lead screw is now exposed as in version one. Nicer balance in terms of the bending joints which now aren’t all on the same side. One of the three bearings is hidden so the emphasis is more on the two side ones now. Far more sturdy rotation mechanism for the solar panel so no more warping and bending hopefully. The arm will have to travel far less distance to change the angle of the solar panel also.

This experiment is interesting to me because it’s an attempt to move towards a more robust design while trying to keep it visually interesting and maintaining the attention to form.

I adapted it for a mirrored version of the linear drive and new lead screws (it wasn’t too hard to do). Now I have right and left handed machines:

This is interesting as it shows how easy or not it is to adapt to the repurposed CD drive mechanisms with the current design and how much variation can be created organically. 

***

It looks like I should go with white Rigid resin and that I should use bushings for the sliding portions so no part of the print has friction.

These appear to be the key characteristics of the lead screw/nut setup.

****

Adding some grease to the rails:

*****

Here’s the tall version:

It has great tilt range.

It feels much taller and more slender. It also looks far more like a sunflower. It’s also lost its animate / cuteness quality that comes from being compact and now feels more like a machine. It does make more sense in terms of weight distribution, however.

It proves that the idea of adjusting for found CD drives works in principle. 

V.4 ERRATA:

1. The Durable resin is too flexible to make rigid longer parts. The whole assembly is flopping all over the place.
2. I need to modify the central solar panel hinge – it’s not possible with the hardware I have to make it function properly. Because the tilt arm pulls from the side, it has a tendancy to tweak the central hinge. I could use the large bottom bearing up top?

****

The new version features a pole that pushes up to tilt the solar panel, and lets the panel rotate down when it descends. This means fewer bearings and maybe less strain on the linear actuator stepper motor:

I’ve redesigned the control board. It now has a nicer spacing between the motor driver out pins and doesn’t have any other wires nearby to get in the way of these pins. It also has the motor driver sleep pins connected to the microchip, and can drive two steppers instead of one stepper and one DC motor as with the previous version. It also has more noise attenuating caps:

I am also considering using an Arduino Nano with DRV8834s and a mini lithium ion just to get this prototype running!

This works but it’s very heavy with the battery packs. I may need to glue the bearings in place or work with a more robust design for this phase.

I’m using the StepperDriver Arduino library and this is what my loop looks like:

if (analogRead(A0)-analogRead(A1)>threshold)
{
stepperTop.move(-MOTOR_STEPS*MICROSTEPS);
}

if (analogRead(A1)-analogRead(A0)>threshold)
{
stepperTop.move(MOTOR_STEPS*MICROSTEPS);
}

if (analogRead(A2)-analogRead(A3)>threshold)
{
stepperBottom.move(-MOTOR_STEPS*MICROSTEPS);
}

if (analogRead(A3)-analogRead(A2)>threshold)
{
stepperBottom.move(MOTOR_STEPS*MICROSTEPS);
}

And here’s the new print:

****

Just discovered why I may have been having issues with the DRV8833s…Their max soldering temperature is 260C, I have been using 300C!

****

I tried to get a full prototype running with the Arduino breakoutboard version but it’s surprisingly heavy and both attempts were unsuccessful. The second:

Without the weight of the circuit board everything is fine however:

I think I may have to admit that this thing is too janky to work beyond as a quick video. 

*****

Meanwhile I’m working on a DC prototype of the more complex 2DOF design:

The idea here is to have 2 1DOF solar engine circuits + a dark activated pummer circuit. The machine would then spend its days searching for the sun and charging up a bigger capacitor to then blink at night like a lighthouse. I’m not sure if I should make the blinking synchronise with other nearby blinkers using this circuit:

https://www.instructables.com/Synchronizing-Fireflies/

One DC motor (controlling the tilt) is so slow it’s barely noticable at all while the other one swings the machine round dramatically. The design has less magic than the servo version but is far easier to control and has no issues with the weight of the solar panels. 

Here is the final product:

After the relative success of the foam cutting machine, I would like to build a medium-sized robot arm which can actually be a useful tool in the lab and not just a toy.

The main questions appear to be: how to increase the torque of the stepper motors? Should we make a classic robot arm or a Selective Compliance Assembly Robot Arm SCARA?  Should the parts be 3D printed or CNC milled (or a combo)? and, Do I already have the parts necessary or do I need to order them in which case how much should I order?

**********

Stepper torque options:

1. Use our super beefy stepper motors. Unfortunately, none of the other hardware (like belt sprockets) fit the diameters of the shafts.

2. 3D print a planetary gear or buy one:

(but these make the front of the stepper bulky and a bit ungainly)

3. Get a large timing belt pully with a short belt drive: (unfortunately we don’t have anything like this lying around the lab).

4.  3D print a large gear to turn directly with the stepper:

A different concept that involves a motors not all at the base:

**********

SCARA vs. Conventional robot arm.

#SCARAs fold up easily and are faster for certain tasks than conventional robot arms.

But there are some neat conventional robot arm designs out there too:

*******

CNC milling vs. 3D printing:

CNC milling some parts (like the large gears) seems possible:

But I also need either to buy a large bearing or to make my own bearing…Unless I make a geared slew bearing:

Here’s a cool guide on designing gears: https://lcamtuf.coredump.cx/gcnc/ch6/

Some DIY slew bearings:

***********

Robot background information: http://www.societyofrobots.com/robot_arm_tutorial.shtml

Cool tutorial includes info about DOF, calculating torque for each joint (fewest joints possible with shortest lever arms the better): http://www.societyofrobots.com/robot_arm_calculator.shtml

Some simple arm linkage ideas:

**********

And these Five-bar linkage machines (aka Parallel SCARA robots), they appear to be known for being super fast:

https://en.wikipedia.org/wiki/Five-bar_linkage

**********

For the end effector I think either air pressure or electromagnet:

************

Some early models:

With only two rails (I’m not sure if this is sufficiently stable or not as many designs have 3 or even 4 rail):

Similar but with a larger motor at the bottom and less ugly mounting plate. 

A completely different SCARA design, I like the silhouette but it would involve tons of cut planar material that would need to slide into together and we might not have everything on hand to make this either: 

Quick attempts at 3D printing planetary gears:

https://www.thingiverse.com/thing:2114390

https://www.thingiverse.com/thing:3231908

(interesting belt option here: https://www.thingiverse.com/thing:2911407)

Using the 0.8 nozzle was not ideal and none of the pieces fit properly. I would love to try this as a cnc cut project but I think it would be highly technical and difficult and at the end would end up in a tiny box. (I’m going for medium scale machines at the moment not tiny intricate things).

We have 12mm HDPE in white and blue in the lab, I’m going to first 3D print then mill it. 

I’ve come to a compromise with the design. It will give me the opportunity to design with a Nema 23 a complex peice (geared slew bearing), to work for the first time with a 5 linkage parallel robot design, to CNC mill HDPE for a more robust machine, but also builds on the syringe pump linear actuator and the foam cutter designs. Most importantly, I have all the components I need to build the full prototype already in the lab. 

I added hardware to this model to make sure everything makes sense:

*********

Developement of the geared slew bearing:

Outlined this drawing in Rhino and then applied it to a circle:

To make everything fit (increments of 2mm) I changed the size slightly of the gear:

Here is the first prototype:

Here is a section showing the bearings cut through and how two layers of 6mm HDPE should come together to make the bearing. After assembling we’ll see if .1mm was too much spacing between the bearing and the walls, and also if there need to be two rows of 4mm bearings.

*******

Here are the 5 bar parallel robot 3D printed parts (view from underneath):

A combination of nuts, washers, 16mm bearings and socket shoulder bolts:

There is an offset in order to make everything work on the stepper motor shafts:

*****

With the final additions here is the final machine:

Here’s the 3D print file with all the parts: 

Here is the kit of parts (minus the parallel arm rods):

The geared slew bearing assembly is tricky because the bearings want to fall within the inner moat.

Adding the top bit:

Finishing it off:

Here is the drive mechanism with an idler I added:

Assembling the parallel robot arm components:

Hammering in the bearings caused splitting in the print…

I sawed the metal bar and deburred before assembly. 

The top threaded rod motor assembly (I broke one side hammering the nut in a little too vigorously)  

Despite checking and rechecking I somehow forgot to put holes in the middle of the rod bearings (!)

Here’s the linear actuator assembly:

With the parallel arms attached, just waiting for the base to finish printing:

With the base:

Errata with the bottom part of the robot:

-impossible to tighten hex nut to fasten gear to bottom motor axel. (Added slot for this purpose)

-not nut subtractions to help hold bolts which fix geared slew bearing to base plate. (Added captive nut subtractions to bottom of base plate)

-I subtrated a cylinder from the base for the motor gear but this makes no sense as it rotates around and does not stay fixed. (I filled this in)

-With current arrangement the belt between the drive shaft and geared slew bearing was loose. (Either I add a spot for an adjustable bearing or I change the location of the motor to pull it further away…I chose the latter).

****

CNC milling:

The top motor and rail mount:

I replaced one part of the 3D printed robot parts at a time:

The middle component:

Everything fits together nicely!

And here is the final result:

The CNC mill using HDPE is extremely fun to use. The only part that is not easy to make is the bearing assembly. This I will print in durable white resin on the Formlabs.

Here is the finished product:

And here is a quick video cutting foam:

Another video showing the stage testing:

Here are the files on Thingiverse: https://www.thingiverse.com/thing:4428184

We’ll be harvesting parts from an old Ultimaker 2.

The stuff we plan to use:

Based on what we found, we plan on making two threaded rod actuators and two belt-driven actuators.

Here is the prototype of the linear threaded rod actuator:

Here is the prototype of the linear belt-driven actuator:

Here is the prototype of the entire foam cutter assembly:

 Here are all the parts 3D printed:

Here are the 3D printed parts along with the hardware:

Here is the belt drive assembly:

Here are the two axes completed:

Here is the first of the two linear actuator drives:

Slight differences between the two based on different hardware but essentially the same:

Here is the full assembly minus electronics:

The electrical connections to the TinyG:

All plugged in and ready to go:

Using the webpage CNC controller Chilippeper :

Running local JSON script to allow the website to access the COM ports, if I understand correctly:

Chilipeppr Configuration (https://github.com/synthetos/TinyG/wiki/TinyG-Configuration-for-Firmware-Version-0.97):

To change the Motor – Axis assignment in Chilipeppr:

$1ma=0 Maps motor 1 to the X axis
$2ma=1 Maps motor 2 to the Y axis
$3ma=0 Maps motor 3 to the X axis
$4ma=1 Maps motor 4 to the Y axis

$1PO

• 0 = Normal motor polarity
• 1 = Invert motor polarity

To set X axis minimum and maximum end stop limit switches (the switches connect GND to XMIN or XMAX on the Tiny G).

$XSN 3 and $XSX 3

To change the distance for every movement of 1mm:

$1tr VALUE

To change max feedrate in X:

*************

Here is the video of the machine making its first moves:

**************

Here is a version two fixing some errors in the 3D modeling:

Linear actuator redesign (forgot to subtract the motor and threaded rod previously):

Here’s the finished belt-drive assembly:

I reprinted this part with 40% density instead of 20% (which broke last time when I tightened), corrected the diameter of the rods (which destroyed the rigity of the actuator), reoriented the embedded nut, and used shorter bolts:

Also 40% instead of 20%:

This was a bit tricky but using two bolts with washers I replaced the hot glue to fix the belt in place. 

I corrected the orientation of the holes and the two actuators line up perfectly:

Here’s the final assembly version 2:

*************

I’ve added some limit switches and have a preliminary setup for the hot wire cutting fixtures:

**************

Here is the first test cut:

Here’s what it looked like on the software side:

I used CAMBAM to take in a DXF and output the Gcode. 

I had to additionally make everything related to the Z axis zero, and set the start point.

Testing with another kind of BLDC and still not working…so is most likely my circuit?

This project is based on Gaudi Lab’s OpenDrop (https://www.gaudi.ch/OpenDrop/)

Here is the github for Fablab Digiscope’s iteration of the project: https://github.com/merlinmarrs/OpenDrop

We don’t have high voltage MOSFETs so we are using relays instead. In parallel we will be sourcing the components to make the high voltage power supply using a boost converter that takes 12V as input. In the meantime, we will be using a transformer that sources 100V directly to the board to test functionality. 

Here is the board cut:

To supply the minimum 100V necessary, I found this high voltage boosting circuit here: https://www.multisim.com/content/dUPNxLKfTuK3sYfGNjNxNg/9v-to-100v-boost-converter/

With what we have in the lab, it’s peaking at just under 80V. 

Testing the relay:

Testing the relay with a motor and 9V battery:

Here is the first full prototype:

What we need now is some hydrophobic dialectric like Teflon…

This device is intended to be installed within the 3D printed forehead mount of a visor. 

It’s being developed at this github: https://github.com/merlinmarrs/Fever-Meter

The top board is a boost regulator taking the 2V from a pair of miniature backup batteries, and the bottom side is an attiny85 with I2C temperature sensor and indication led. 

This project necessitated the use of rivets. I used a dremel to make a hole in the board then inserted the rivet and gave it a tap with our riveting tool.

The results are relatively clean:

This contactless temperature sensor has a POV display for the temperature readout. 

Here is the github: https://github.com/merlinmarrs/POV-fever-meter

Here is what it looks like in a dark room with long exposure:

The plan was to have the device spell out the message in reverse after displaying it normally to allow a certain frequency of waving the wand back and forth to display perfectly. Alas…this does not work well currently.

I am still waiting for the IR temperature sensor to arrive in the mail.

Developed by Fablab Digiscope.

A board to sense the temperature and illumination, and act as an interface, inside a disinfection device:

https://github.com/merlinmarrs/anti-viral-dispositif/

A main board and secondary board to control a disinfection chamber based on this tutorial: http://www.needlab.org/face-masks-disinfection-device

Here is the BOM:

Standard components:

7 segment display x2 595 Shift Register x2 LED x 2 Photocell Piezo Atmega 328p micro-swith (CHECK MAX VOLT + AMP RATING)

exotic components:

lampe UV-C à Amazon.fr:

https://www.amazon.fr/Germicide-Ultraviolet-st%C3%A9rilisateur-Submersible-radiations/dp/B07Y82SM36/ref=sr_1_4?__mk_fr_FR=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=uv+aquarium+sterilizer&qid=1587383305&s=hi&sr=1-4-catcorr

2. MLX90614 (pas en rayon a Mouser, Farnell, Sparkfun, Polulu ou Adafruit) à Digikey (ou c’est “hors prix”) ou Amazon.fr:

https://www.digikey.com/product-detail/en/melexis-technologies-nv/MLX90614ESF-DCA-000-TU/MLX90614ESF-DCA-000-TU-ND/2025323

https://www.amazon.fr/MLX90614ESF-MLX90614ESF-BAA-000-TU-ND-thermom%C3%A8tre-infrarouge-compatible/dp/B07JBKM2K3/ref=sr_1_1?__mk_fr_FR=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=MLX90614&qid=1587470750&s=hi&sr=1-1-catcorr

Still waiting for the temperature sensor to arrive in the mail. 

This is the stepper motor driver design we are hoping to use to control a syringe. Here is the PDF describing the assembly: etapes fab venti v2

And here is the github repo:

https://github.com/merlinmarrs/FabVenti

This is the syringe pumping prototype I developed. It uses 8020, a NEMA stepper with built in threaded rod, NEMA motor brackets, and linear bearings. The rest is 3D printed and uses M3 and M4 screws. 

The goal of this primer is to introduce people to mini DIY solar energy applications.

New solar product I just found out about: 

Here are some videos of the current prototypes:

I want to focus this project on the design of the 2 axis rotation mechanism. The electronics and code side has already been explored and I can’t offer anything new here as a designer.

(I’ll abstract the sensing and radio side of thing for a now and design the PCB to be sent to manufacture later. This will be a good exercise in applying the new PCB design best practices that I have since learned and for overcoming the limitations of PCB making in the lab. I could imagine this board having a compass and accelerometer to find out its own direction, and possibly an wifi connection to send its data to the internet.

To simplify things further, I could think of this design as an indoor weather station. Instead of the tpical arduino inside a plastic box though, this project would emphasize the dynamic quality of solar energy, turning solar tracking into an exciting technical spectacle. The design would make reference to off-grid technology and thereby embody the mythical appeal of the power-autonomous and the off-grid (tiny house movement, prepper phenomenon, etc.).

*************

I’m inspired by weather buoy design:

And also the possibility of some kind of Wes Jones inspired multi solar panel actuated louver system:

It could look like the MIT solar panel project but it would have a lower center of gravity and be motor controlled.

Some quarantine sketches:

As for the code:

https://www.hindawi.com/journals/js/2019/3681031/

According to the above article, loading the Astrologer’s Almanac onto a sensorless microchip appears to be even more efficient than giving a microchip light sensors in the classic approach (https://create.arduino.cc/projecthub/ioarvanit/dual-axis-solar-tracker-panel-with-auto-and-manual-mode-41cfd9).

Code has already been optimized for arduino: https://pdfs.semanticscholar.org/ffd3/bb8b5e85c796da0ae3eac3be11117291289f.pdf

*****

Here is the next version of this design:

The thinking is to look around and find existing parts of medium to high quality in the lab, and design something which works around those preexisting parts. (I have the gears, the chain, the 3mm rod, and the ball bearings. The bearings we have don’t have 3mm inner diameter so right now they just turn around a hole in the 3D print / CNC milled axle holders. 

Here’s a right angle design with only one bearing and less hardware (there may be a weight distribution argument for one of these assemblies):

Remaking the gear (less improperly this time) with Sweep1 and scaled outline which I bent into a circle:

Here’s the model ready for print:

lazy explosion:

The 3D printed parts:

The begining of the bearing assembly:

The alignment was impossible to get right here:

 I ended up hacking together something with Paolo’s bearing and some old prints. After some sanding and forcing of parts together, here is the prototype:

Errata: 

-ball bearing spacing not great enough.The bearing did not fit together, I’m guessing because there wasn’t a big enough gap between the ball bearings and the two sides of the bearing.

-the upper bearing needs more depth in order to comfortably rest in place, but it just bearly works.

-the motor holders required many minutes of sanding and filing to fit the motors, but now it fits perfectly.

-the gear should probably be a miter, also there is nothing holding the sprocket down in place.

******

Took apart a bunch of small stuff to have small screws and rods:

To fix the board to the bar I used a part I found in a floppy disk drive:

Showing the M1.6 screws holding the top 3D print in place and some M3 black bolts to keep the inner bearing off the ground.

I wired up the two motors as well to see how that would work:

*******

Here is an attempt at making something similar from stepper motors (of course they need to be powered to hold their position so they can’t really be weight bearing). The nice thing about steppers is the mini linear threaded drives which could be added to the pan-tilt to give the machine the ability to move around shadows? 

3D modeling the pan tilt with two steppers:

…and one stepper / one DC gearmotor:

Here is the design worked a bit more and ready to print:

Here is how the print and assembly turned out:

I like how the translucent print blends with the different metal and plastic shades. For the electronics I’m planning four LRDs and a super simple program (with batt for super reactive demo?). One could either imagine a whole array of the same sun tracking devices, or a series of different families of devices mixed together in an array, which would all react in the same way to moving a light bulb into the space above the robots….

Errata:

-Everything is still a bit too snug with 0.1mm offsets. I should have made the spacing for the rail even bigger because it needs to actually slide…

-I designed using a bearing I only have one of and was already using in another machine…

-The holes for the read DC motor mounting didn’t come through.

-The top part which holds the rod and attaches to the linear rail broke because it was super weak in the middle.

-The bottom brace is not long enough to force the panel into more acute angles.

-The tension in the rubber belt is not sufficient to turn the base…

-The threaded rod nut plastic piece is not pushed sufficiently into the threaded rod to grip effectively. It needs to be closer to the rod so the built-in spring is in tension.

****************

I have some new parts: M2 bolts and nuts as well as steppers with gear reductions.

Taking apart more DVD roms I had the idea of remaking this device entirely from e-waste parts. I have six kits so far:

The idea would be to make this design:

There are about four sets of the same components available from the 8 DVD drives I took apart. I am redesigning the 3D model with these parts in mind.

There is also the possibility of using the motor drivers from the boards themselves except that they require a 12V VCC…

Here is a post describing how they could be hacked: https://electronics.stackexchange.com/questions/341519/i-need-help-controlling-the-sled-motor-of-a-cd-rom-based-off-of-a-datasheet

Here are some details about this next design:

-it incorporates another found motor of the DVD rom device instead of the geared DC motor ordered from Polulu. 

-it has tracks instead of holes for sensitive spots (like the DC motor mount and the threaded rod nut) so that things can be adjusted and then bolted when they are just perfect.

-I replaced the central bearing for the correct diameter.

-I made the upper 3D printed peice more structurally sound so hopefully it won’t break this time. 

-I made larger offsets for inserts (except for the rod holders which I want to be snug) 0.2mm all around instead of 0.1mm this time. 

-I made a recessed track for the gear belt holder on the DC motor. 

-I fiddled such that the angle range for the panel is greater now. 

In parallel I’m working on the simplest version of a test board possible:

-super cap will need to be manually charged

-4 photodiodes for solar orientation will be manually wired to avoid challenging trace designs.

-only the most essential stuff for the motor drivers and microchip. 

The idea is that I can make a video showing the device tracking a light source in real time super “responsively”. This could then easily be modified to be the actual sun seeking circuit. 

I will have four little directional shaders which will cast shadows if the four photodiodes are not all pointed directly at the same light source. 

https://www.sciencedirect.com/science/article/abs/pii/S2213138818300080

I made a quick PCB then decided what I really need is an air wired arduino with motor drivers to test this.

Errata from second stepper prototype:

-The 3D printed piece that holds the leadscrew nut is too thick for my M2 bolts and so it cannot be bolted on.

-I forgot to subtract the bottom toothed part of the black gear belt wheel from the base.

-most of the offsets are too loose. 

-with the wider heavier DC motor the base is no longer stable enough.

-I forgot to subtract the flange of the DC motor (like a collar around the axle) from the bracket that it attached to.

Next I will get a quick mock up with some light sensors mounted on the four corners of the solar panel enabling an arduino to follow a light source. This won’t be embedded on a board yet, it will just be a test.

***********

I’m using a DRV8835 motor shield and an easy stepper motor driver for this mock up with the LDRs wired like this (but with 1Ks instead of 10Ks):

Here is the code I’m using to control the LDR sensing sun seeker;

#include <DRV8835MotorShield.h>

#define LED_PIN 13

DRV8835MotorShield motors;

//Declare pin functions on Redboard
#define stp 2
#define dir 3
#define MS1 4
#define MS2 5

#define BPHASE 10
#define BEN 9

#define EN 6

int sensorPin1 = A0;
int sensorPin2 = A1;
int sensorPin3 = A2;
int sensorPin4 = A3;
int sensorValue1 = 0;
int sensorValue2 = 0;
int sensorValue3 = 0;
int sensorValue4 = 0;

//Declare variables for functions
char user_input;
int x;
int y;
int state;

void setup() {

Serial.begin(9600);
pinMode(sensorPin1, INPUT);
pinMode(sensorPin2, INPUT);
pinMode(sensorPin3, INPUT);
pinMode(sensorPin4, INPUT);

pinMode(stp, OUTPUT);
pinMode(dir, OUTPUT);
pinMode(MS1, OUTPUT);
pinMode(MS2, OUTPUT);
pinMode(EN, OUTPUT);
resetEDPins(); //Set step, direction, microstep and enable pins to default states

pinMode(LED_PIN, OUTPUT);

pinMode(BPHASE, OUTPUT);
pinMode(BEN, OUTPUT);
}

//Main loop
void loop() {

sensorValue1 = (analogRead(sensorPin1) + analogRead(sensorPin1) + analogRead(sensorPin1))/3;
sensorValue2 = (analogRead(sensorPin2) + analogRead(sensorPin2) + analogRead(sensorPin2))/3;

sensorValue3 = (analogRead(sensorPin3) + analogRead(sensorPin3) + analogRead(sensorPin3))/3;
sensorValue4 = (analogRead(sensorPin4) + analogRead(sensorPin4) + analogRead(sensorPin4))/3;

if(sensorValue1 > 500 && sensorValue1 > sensorValue2)
{
StepForwardDefault();
}

if(sensorValue2 > 500 && sensorValue2 > sensorValue1)
{
ReverseStepDefault();
}

if(sensorValue3 > 500 && sensorValue3 > sensorValue4)
{
forward(10);
nomove();

}

if(sensorValue4 > 500 && sensorValue4 > sensorValue3)
{
backward(10);
nomove();

}

//StepForwardDefault();
//ReverseStepDefault();

//forward(50);
//backward(50);
//nomove();

}

void forward(int t)
{

digitalWrite(BEN, HIGH); //forward
digitalWrite(BPHASE, LOW);
delay(t);

}

void backward(int t)
{

digitalWrite(BEN, HIGH); //backward
digitalWrite(BPHASE, HIGH);
delay(t);

}

void nomove()
{

digitalWrite(BEN, LOW); //no movement
digitalWrite(BPHASE, LOW);

}

//Reset Easy Driver pins to default states
void resetEDPins()
{
digitalWrite(stp, LOW);
digitalWrite(dir, LOW);
digitalWrite(MS1, LOW);
digitalWrite(MS2, LOW);
digitalWrite(EN, HIGH);
}

//Default microstep mode function
void StepForwardDefault()
{

digitalWrite(dir, LOW); //Pull direction pin low to move “forward”
for(x= 0; x<100; x++) //Loop the forward stepping enough times for motion to be visible
{
digitalWrite(stp,HIGH); //Trigger one step forward
delay(1);
digitalWrite(stp,LOW); //Pull step pin low so it can be triggered again
delay(1);
}

}

//Reverse default microstep mode function
void ReverseStepDefault()
{

digitalWrite(dir, HIGH); //Pull direction pin high to move in “reverse”
for(x= 0; x<100; x++) //Loop the stepping enough times for motion to be visible
{
digitalWrite(stp,HIGH); //Trigger one step
delay(1);
digitalWrite(stp,LOW); //Pull step pin low so it can be triggered again
delay(1);
}

}

// 1/8th microstep foward mode function
void SmallStepMode()
{

digitalWrite(dir, LOW); //Pull direction pin low to move “forward”
digitalWrite(MS1, HIGH); //Pull MS1, and MS2 high to set logic to 1/8th microstep resolution
digitalWrite(MS2, HIGH);
for(x= 0; x<1000; x++) //Loop the forward stepping enough times for motion to be visible
{
digitalWrite(stp,HIGH); //Trigger one step forward
delay(1);
digitalWrite(stp,LOW); //Pull step pin low so it can be triggered again
delay(1);
}

}

//Forward/reverse stepping function
void ForwardBackwardStep()
{

for(x= 1; x<5; x++) //Loop the forward stepping enough times for motion to be visible
{
//Read direction pin state and change it
state=digitalRead(dir);
if(state == HIGH)
{
digitalWrite(dir, LOW);
}
else if(state ==LOW)
{
digitalWrite(dir,HIGH);
}

for(y=0; y<1000; y++)
{
digitalWrite(stp,HIGH); //Trigger one step
delay(1);
digitalWrite(stp,LOW); //Pull step pin low so it can be triggered again
delay(1);
}
}

}

***********************

To make an on-board version of the breadboard prototype I made, I think I can reuse a previous version of this circuit which has two motor drivers and even a couple of spots for LDRs (I would just ignore the radio and sensor side of things for the moment at least):

(I may need to add a CS pull-up resistor and a 0.1uF cap to power as these were two erratta from this version of the board.) 

This turned out to be a bad idea, there are approximately 3,590 jumpers between the two boards, so no practical at all.

I am thinking of making miniature smd light sensor pairs (we have smd photodiodes in the lab) that would attach to the outside of the board on 3D printed T-shaped things:

When light is straight ahead, difference between LDRs will be minimal. Moment that one is significantly darker than the other, the motor which turns the dark side towards the light needs to come on until they are equalized again. So more of a nested if loop?

if(sensor1-sensor2 > 200){// difference in sensors

if(sensor1>100&&sensor2<50) //turn motor CW

else()//turn motor CCW

****************

Because the board already has the radio built in, I wonder if I should reincorperate it into the project. I also recieved some female SMA board antenna connectors which I could incorperate into the new version.

************

New code:

#include <Stepper.h>

// change this to the number of steps on your motor
#define STEPS 200

// create an instance of the stepper class, specifying
// the number of steps of the motor and the pins it’s
// attached to
Stepper stepper(STEPS, A2, A3, A5, A4);

#define RED 3 // RED LED

int sensorPin1 = A0;
int sensorPin2 = A1;
int sensorPin3 = A6;
int sensorPin4 = A7;
int sensorValue1 = 0;
int sensorValue2 = 0;
int sensorValue3 = 0;
int sensorValue4 = 0;

void setup()
{

pinMode(sensorPin1, INPUT);
pinMode(sensorPin2, INPUT);
pinMode(sensorPin3, INPUT);
pinMode(sensorPin4, INPUT);

pinMode(6, OUTPUT); //

pinMode(7, OUTPUT); //

// set the speed of the motor to 30 RPMs
stepper.setSpeed(60);
}

void loop()
{

digitalWrite(6, LOW); //
digitalWrite(7, LOW); //

sensorValue1 = (analogRead(sensorPin1) + analogRead(sensorPin1) + analogRead(sensorPin1))/3;
sensorValue2 = (analogRead(sensorPin2) + analogRead(sensorPin2) + analogRead(sensorPin2))/3;

sensorValue3 = (analogRead(sensorPin3) + analogRead(sensorPin3) + analogRead(sensorPin3))/3;
sensorValue4 = (analogRead(sensorPin4) + analogRead(sensorPin4) + analogRead(sensorPin4))/3;

if(sensorValue1 > 500 && sensorValue1 > sensorValue2)
{
clockwise();
delay(500);
}

if(sensorValue2 > 500 && sensorValue2 > sensorValue1)
{

counter_clockwise();
delay(500);
}

if(sensorValue3 > 500 && sensorValue3 > sensorValue4)
{
stepper.step(STEPS);

}

if(sensorValue4 > 500 && sensorValue4 > sensorValue3)
{
stepper.step(-STEPS);
}

digitalWrite(6, LOW); //
digitalWrite(7, LOW); //

}

int clockwise()
{

digitalWrite(6, HIGH); //
digitalWrite(7, LOW); //

}

int counter_clockwise()
{

digitalWrite(6, LOW); //
digitalWrite(7, HIGH); //

}

I just destroyed a circuit I spent over a week preparing and I decided I would learn how to better protect my circuits.

Reverse Polarity protection:

A diode can be used to protect a circuit but it will drop 0.7V and will waste power. A shotky diode will only drop .3-.4V but it has the same issue. A P-Channel MOSFET set up where the gate is connected to ground will only turn on when the polarity is correct. If Vin is not greater than the maximum allowed voltage you can put accross the MOSFET from gate to source (Vgs max.), or the Vin is not less than the threshold required for the P-FET to turn on (Vgs th), then it doesn’t need any other components.

For overvoltage protection (https://circuitdigest.com/electronic-circuits/overvoltage-protection-circuit):

When the voltage is below the Zener Diode’s 5.1V reverse threshold, Q2’s base is HIGH  (through the 2.2K resistor) so the PNP is off. This means that Q1 is ON (because it’s PNP base is connected to ground via 6.8K) and the circuit is powered.

When the voltage is above the Zener Diode’s 5.1V reverse threshold, Q2 is connected to ground and is turned on. This connects Q1 with VCC and therefore turns it off, disconnecting the circuit from the power. 

For short circuit protection:

Q2 is a PNP, Q1 is an NPN. Here is my understanding based on the site https://circuitdigest.com/electronic-circuits/short-circuit-protection-circuit-diagram

First a small amount of current reaches the base of Q1 (via R5 and the D2), causing it to turn on Q2. Now current flows through Q2 into R4 and D1 while keeping Q1 on. Current is no longer flowing through D2.

When a short occurs, current passes directly towards ground from Q2 and therefore no longer turns Q1 on. This turns off Q2 and now current passes via R5 and D2, skipping D1 and still skipping R2 towards Q1, directly to ground. Instead of having a short, we now have current passing through R5 and D2. 

PCB Design (from https://www.youtube.com/watch?time_continue=5&v=NJKZZArjdg8&feature=emb_logo):

-rounded corner for logic levels, straight corners “round edges”. (Though not everyone seems to agree on this). 45 degree angles are good, 90 are bad.

-minimize trace lengths, components electronically close should be physically close too. Longer traces have higher resistance, capacitance and inductance. 

-Think in terms of a signal chain, with input on the left moving towards output on the right. Divide things into building blocks. Build each block separately and then throw it on the main board. 

-VCC should be connected via a star-like formation to sub systems, with branches of equal length, NOT in a cascaded or serial way where the last sub system is furthest away from VCC. This will make the later sub systems vulnerable to noise produced by the upstream ones.

-Mechanical parts (pots, switches, barrel connectors) fail before electrical parts.

-watch out for your ground returns (the path that a component’s ground path with take to make it back to the power regulator). If it is zig zaggy and not short this is not ideal.

-don’t forget to add test points! 

This website helps to calculate the correct width of traces for a given current:

http://circuitcalculator.com/wordpress/2006/01/31/pcb-trace-width-calculator/

This resource looks good for more in depth: http://alternatezone.com/electronics/files/PCBDesignTutorialRevA.pdf

Here is a table showing minimum trace widths for different thicknesses of copper:

•••••••••••••••

-work in mils, most components are designed with 100 mil spacing (0.1″). 

-For your Eagle grid, had a 25 thou alt grid with a 50 thou main grid. Or a 25mil/10mil for finer work. Use a SNAP grid.

-bigger traces are better generally, they have lower DC resistance and lower inductance.

-25 thou for signal traces, 50 thou for power, 10-15 for traces going in between ICs is a good place to start. 

-oval shaped pads for ICs, circular for leaded resistors and caps. 

-minimize the number of drill bits that will be required by the board house to make your circuit.

-check that when you actually add the components, screws, etc., it all fits and doesn’t cause potential shorts. 

-do not mix analog and digital sub systems in the same circuit, nor high current or frequency and low current and frequency. 

-leave a rectangle at the top of the solder mask so you can write something in pen on the board!

-for a two sided board, the bottom can be a ground plane. You should not have the ground plane extend all the way to the edge of the board. The more copper in your ground path the lower the impedance. 

-Use multiple vias to connect the same signal to ground to lower impedance. 

-One bypass cap per IC: 10nF or 1nF for higher frequencies, and 1uF or 10uF for low frequencies

-boards are typically made with 1oz. copper thickness and are 1.6mm thick fiberglass FR4.

-don’t forget to add a signature/logo to your board!

Visualizing your circuit before building:

https://www.falstad.com/circuit/

For a change, this is a video of me working on the boards for this project:

Radios are working, I’m struggling with the best way to poll the joysticks. I think I need to use Pin Change Interrupts (Interrupts for pins other than those dedicated for interrupting). The other option is just to have polling:

if (UP == HIGH){ Send(UP);}

if (DOWN == HIGH){ Send(DOWN);}

etc.

*Later realized that I messed this up, what I want is to check if the pin is LOW (i.e. if it is connected to ground and not internally pulled up) and then have an else at the end which turns to HIGH.

*I forgot to put pull-up resistors on the actual board so I used the avr’s internal ones. In arduino you do this like so:

pinMode(A0, INPUT_PULLUP);

I reprinted the drone frame with .1mm extra space around the circle and now the motors fit snuggly. 

Dissapointed that the joysticks only register an up or down when also pushed down…

Here is the joystick sending code:

********************************************************************************

// RFM69HCW Example Sketch
// Send serial input characters from one RFM69 node to another
// Based on RFM69 library sample code by Felix Rusu
// http://LowPowerLab.com/contact
// Modified for RFM69HCW by Mike Grusin, 4/16

// This sketch will show you the basics of using an
// RFM69HCW radio module. SparkFun’s part numbers are:
// 915MHz: https://www.sparkfun.com/products/12775
// 434MHz: https://www.sparkfun.com/products/12823

// See the hook-up guide for wiring instructions:
// https://learn.sparkfun.com/tutorials/rfm69hcw-hookup-guide

// Uses the RFM69 library by Felix Rusu, LowPowerLab.com
// Original library: https://www.github.com/lowpowerlab/rfm69
// SparkFun repository: https://github.com/sparkfun/RFM69HCW_Breakout

// Include the RFM69 and SPI libraries:

#include <RFM69.h>
#include <SPI.h>

// Addresses for this node. CHANGE THESE FOR EACH NODE!

#define NETWORKID 0 // Must be the same for all nodes (0 to 255)
#define MYNODEID 1 // My node ID (0 to 255)
#define TONODEID 2 // Destination node ID (0 to 254, 255 = broadcast)

// RFM69 frequency, uncomment the frequency of your module:

//#define FREQUENCY RF69_433MHZ
#define FREQUENCY RF69_915MHZ

// AES encryption (or not):

#define ENCRYPT true // Set to “true” to use encryption
#define ENCRYPTKEY “TOPSECRETPASSWRD” // Use the same 16-byte key on all nodes

// Use ACKnowledge when sending messages (or not):

#define USEACK true // Request ACKs or not

// joystick and leds

#define LED1 A0 // LED positive pin
#define UP1 A2//
#define LEFT1 A3//
#define RIGHT1 A4//
#define DOWN1 A5//

#define LED2 A1 // LED positive pin
#define UP2 8//
#define LEFT2 9//
#define RIGHT2 7//
#define DOWN2 6//

// Create a library object for our RFM69HCW module:
RFM69 radio;

void setup()
{
// leds and joystick init

pinMode(LED1,OUTPUT);
pinMode(LED2,OUTPUT);

pinMode(UP1,INPUT_PULLUP);
pinMode(LEFT1,INPUT_PULLUP);
pinMode(RIGHT1,INPUT_PULLUP);
pinMode(DOWN1,INPUT_PULLUP);

pinMode(UP2,INPUT_PULLUP);
pinMode(LEFT2,INPUT_PULLUP);
pinMode(RIGHT2,INPUT_PULLUP);
pinMode(DOWN2,INPUT_PULLUP);

// Initialize the RFM69HCW:

radio.initialize(FREQUENCY, MYNODEID, NETWORKID);
radio.setHighPower(); // Always use this for RFM69HCW

// Turn on encryption if desired:

if (ENCRYPT)
radio.encrypt(ENCRYPTKEY);
}

void loop()
{
//setting up variables for button states

int sensorVal0 = digitalRead(UP1);
int sensorVal1 = digitalRead(LEFT1);
int sensorVal2 = digitalRead(RIGHT1);
int sensorVal3 = digitalRead(DOWN1);
int sensorVal4 = digitalRead(UP2);
int sensorVal5 = digitalRead(LEFT2);
int sensorVal6 = digitalRead(RIGHT2);
int sensorVal7 = digitalRead(DOWN2);

// SENDING

// In this section, we’ll gather serial characters and
// send them to the other node if we (1) get a carriage return,
// or (2) the buffer is full (61 characters).

// If there is any serial input, add it to the buffer:

char buffer[5] = “z”;

//BUTTON READING AND SENDING

if (sensorVal0 == LOW) {
buffer[0] = ‘a’;
digitalWrite(LED2, HIGH);
}

else if (sensorVal1 == LOW) {
buffer[0] = ‘b’;
digitalWrite(LED2, HIGH);
}

else if (sensorVal2 == LOW) {
buffer[0] = ‘c’;
digitalWrite(LED2, HIGH);
}

else if (sensorVal3 == LOW) {
buffer[0] = ‘d’;
digitalWrite(LED2, HIGH);
}

else if (sensorVal4 == LOW) {
buffer[0] = ‘e’;
digitalWrite(LED1, HIGH);
}

else if (sensorVal5 == LOW) {
buffer[0] = ‘f’;
digitalWrite(LED1, HIGH);
}

else if (sensorVal6 == LOW) {
buffer[0] = ‘g’;
digitalWrite(LED1, HIGH);
}

else if (sensorVal7 == LOW) {
buffer[0] = ‘h’;
digitalWrite(LED1, HIGH);
}

else {
buffer[0] = ‘z’;
digitalWrite(LED2, LOW);
digitalWrite(LED1, LOW);
}

// END OF BUTTON STUFF

if(buffer[0]!=’z’)
{

static int sendlength = 3;

radio.sendWithRetry(TONODEID, buffer, sendlength);
}

}

********************************************************************************

And here is the receiver code:

*********************************************************************************

// RFM69HCW Example Sketch
// Send serial input characters from one RFM69 node to another
// Based on RFM69 library sample code by Felix Rusu
// http://LowPowerLab.com/contact
// Modified for RFM69HCW by Mike Grusin, 4/16

// This sketch will show you the basics of using an
// RFM69HCW radio module. SparkFun’s part numbers are:
// 915MHz: https://www.sparkfun.com/products/12775
// 434MHz: https://www.sparkfun.com/products/12823

// See the hook-up guide for wiring instructions:
// https://learn.sparkfun.com/tutorials/rfm69hcw-hookup-guide

// Uses the RFM69 library by Felix Rusu, LowPowerLab.com
// Original library: https://www.github.com/lowpowerlab/rfm69
// SparkFun repository: https://github.com/sparkfun/RFM69HCW_Breakout

// Include the RFM69 and SPI libraries:

#include <SPI.h>
#include <RFM69.h>

// Addresses for this node. CHANGE THESE FOR EACH NODE!

#define NETWORKID 0 // Must be the same for all nodes
#define MYNODEID 2 // My node ID
#define TONODEID 1 // Destination node ID

// RFM69 frequency, uncomment the frequency of your module:

//#define FREQUENCY RF69_433MHZ
#define FREQUENCY RF69_915MHZ

// AES encryption (or not):

#define ENCRYPT true // Set to “true” to use encryption
#define ENCRYPTKEY “TOPSECRETPASSWRD” // Use the same 16-byte key on all nodes

// Use ACKnowledge when sending messages (or not):

#define USEACK true // Request ACKs or not

// Packet sent/received indicator LED (optional):

#define LED 1 // LED positive pin

// Create a library object for our RFM69HCW module:

RFM69 radio;

void setup()
{
// Open a serial port so we can send keystrokes to the module:

pinMode(LED,OUTPUT);
digitalWrite(LED,LOW);

radio.initialize(FREQUENCY, MYNODEID, NETWORKID);
radio.setHighPower(); // Always use this for RFM69HCW

if (ENCRYPT)
radio.encrypt(ENCRYPTKEY);

}

void loop()
{

// RECEIVING

// In this section, we’ll check with the RFM69HCW to see
// if it has received any packets:

if (radio.receiveDone()) // Got one!
{
// Print out the information:

// The actual message is contained in the DATA array,
// and is DATALEN bytes in size:

// char message = radio.DATA[0];

// RSSI is the “Receive Signal Strength Indicator”,
// smaller numbers mean higher power.

// Send an ACK if requested.
// (You don’t need this code if you’re not using ACKs.)

if (radio.ACKRequested())
{
radio.sendACK();
}
Blink(LED,10);
}

}

void Blink(byte PIN, int DELAY_MS)
// Blink an LED for a given number of ms
{
digitalWrite(PIN,HIGH);
delay(DELAY_MS);
digitalWrite(PIN,LOW);
}

*********************************************************************************

Now just waiting for some new pager motors to arrive…

I’ve got some old drones which I have taken apart for batteries, motors and propellers. The motors are slightly larger to I have redesigned the 3D print. The motors are 8.5mm in diameter and I found that subtracting with an 8.8mm cylinder make for the snuggest fit.

Using the tool bin vis, which simply assigns a shade of grey for each byte in a file, it’s possible to represent the structure of pieces of a file. Check it out, these are found 3D files from various software programs:

Found a cool surprise when I uploaded a .BMP file, the bytes map almost perfectly onto the image;

I want to try other uncompressed formats like RAW. Loading PNGs and JPEGs are uninteresting so far, they are just noise.

I have tried some experiments processing this data. These stem from the observation that changing the width of the viewing window, which causes the binary data to wrap around the screen, changes the representation of the data dramatically. 

In this experiment I tried to adjust the window of the binary visualizing screen to get the data to make columns, to the extend that this was possible. Some of this info must repeat at a point in the middle of a byte and therefore not map onto a grid of pixels perfectly (?).

Here is an attempt to isolate just the modules which repeat in the above image and to display only them;

I am imagining a program which goes through the file and figures out the proper width for each chunk of data so that this process can be automated. 

Some experiments I would like to try:

-what does the same form look like (say, a sphere) in different software formats?

-is it possible to identify which part of the binary file links up with which part of the 3D file? Could you isolate the repeating element and figure out exactly what it’s composed of?

-what are the similarities and differences between different 3D objects saved by the same software? (I.e. what is the software grain?)

-what do the Rhino.exe, Adobe Illustrator.exe and Revit.exe files look like?

-show a before and after compression image.

-somehow look at a program’s operation by examining it’s buffer memory live somehow?

and here’s the view of just the pixels in the same file just changing the window width:

Essentially each eight bits (eg. 01101001) are transformed into a pixel with a value of grey between black (0) and white (255):

I just visited the Glasgow Botanical Garden and watched the film Aquarela. Both experiences reminded me about the diversity of patterns and permutation of simple rules at play in the cosmos.

Aquerela (2019) Screenshot

Glasgow botanical gardens (image from http://martinbrookes.blogspot.com/2018/06/the-botanical-gardens-glasgow.html)

Looking at a Rhino file in a text editor you get that same “grain” feel as with bin vis:

this is from https://developer.rhino3d.com/api/RhinoCommon/html/N_Rhino_FileIO.htm

but there is also: https://developer.rhino3d.com/guides/#opennurbs

It would seem a lot easier to start with a file format that is ASCII encoded though…

This is a RAW file opened in binview, it has several images contained in it, one for each color channel I guess:

Here is a Bitmap file saved with interleave:

An IGS file format, ASCII readable, visualized. Pretty boring unfortunately.

I found a head inside an example Rhino file :D!

Some tests with a single image saved in different formats:

Sphere test:

Cube test:

Zooming in to some patterns:

Some patterns I found in 3D files (would be cool to compare to image file observations!):

With red to help identify the patterns:

For comparison here are some samples from image files:

Comparing an all white vs. all black file:

Next experiment is to copy and paste pieces of one file into others. Possibly from a compressed file into a raw file! (Wait – why?)

Insight into what we’re seeing in these files: http://www.rumint.org/gregconti/publications/taxonomy-bh.pdf

when things line up into a structure, data is fixed length. When things don’t line up we get variable length data chunks. Repeating values seem to help align data regions. Nois is encrypted in some way typically which has scrambled the structure. 

*****

The problem with this visualization is that it does not represent TIME, like my other ones. It would be cool to stretch and compress these images based on the speed with which the files were written somehow. 

**************

Update: This software called HeapMemory (https://www.nirsoft.net/utils/heap_memory_view.html) allows you to see memory created by active programs. You can output the data and then visualize it with binvis. If you did this regularly while you worked on a 3D model, you could have a representation of the file you’re working on through the eyes of the computer program. 

Here is a gif of a rhino operation and the change in the 3dm file:

and here’s a timelapse of a rhino file with transformations taking place:

To “present my projects or any other insights on digital fabrication, education and architecture.” The context; “The class is the second part of an intensive course on 3d modelling and CNC milling to make an 1:1 architectural structure based on simple modules.”

Here are some questions I could respond to: What are the seams, the gaps, and the moments of translation, between various subsystems in our contemporary digital design workflow?
How has software engineering culture given form to our software?
How does the computer internally represent our work – how does it “see” our design files and “understand” our design work?
Does software have a “grain”, just like wood and other materials? What is the ontology of Revit and what is the world according to Rhino 3D, for instance?
Do technological artifacts, and the objects that designers make, have innate force in themselves, as Bruno Latour and Jane Bennett seem to suggest?

I am planning a revised lecture from my UdK workshop. I would also like to present some new research but my compression research is not leading to a tangible visualization yet, I need to ask for help from programmers to accelerate this process perhaps. The other solution appears to be to go towards simpler technology from further back in history. This has the added bonus of me not working on visualizing something that a million other people are already working on as with image compression visualization. Taking a look at my map of gaps diagram…

I would like to make a GIF of the Revit startup elements. I also want to incorporate Schlossman lecture material like the number of software programs that used to exist that have all been eaten by Autodesk:

OMG here is the mother lode for all things memory visualization, this is incredibly impressive: https://reverseengineering.stackexchange.com/questions/6003/visualizing-elf-binaries

downloaded bin vis from this link, it has an .exe in the debug file: http://www.rumint.org/gregconti/publications/binviz_0.zip

I could use the techniques from the following video to compare Rhino to Revit live, or look at types of files that architects use. At the very least I could make a nice slide showing the “grain” of these different programs! I could also make the argument that because computers are so much faster than us, they can see more data at a time than we can and therefore it looks to them like watching an image (I could get the speed of their reading to equal the number of pixels we can see at a given time). 

Here is a lecture which outlines the method of mapping binary to pixel shades and how you can begin to identify species of data: https://www.youtube.com/watch?v=h68VS7lsNfE

keywords:

memory map, visual reverse engineering

https://reverseengineering.stackexchange.com/questions/6003/visualizing-elf-binaries:

word document:

pdf:

http://actinid.org/vix/

http://binvis.io/

…I could look at things like scanners, or floppy disks?