Week 17

The focus this week was mainly on the encoders, as they are the last important piece of the puzzle, but there was also some small progress on mechanical parts and improvements of the drives.

Encoder

Now the magnets and TLE chips had finally arrived and I could continue.

First I finished soldering the breakout boards.

Then prepared the wiring between the main PCB and breakout boards. It is so much easier, when you have the right tools for this job.

Because the seat for the magnets, is in the hex head of the bolts, I needed to remove the embossed marking (A4-70) and drill a pocket for the magnet.

Here I'm working on the machining:

Once finished, the magnet sat nicely into the pocket and I glued it in place.

As you can see on the picture, the mounting plate has different pocket depths, because the AS5048B and TLE5012B don't have the same height, but need to be placed in similar distance to the magnet's surface.

I machined the bolts both for Ø6 mm and Ø8 mm magnets to see if there is a difference.

Note

It is necessary to use diametric magnets for this encoder applictions.

========================

Next was to connect the AS5048B encoder and see if I could get it running. I used the AMS_AS5048B library.

My first attempt wasn't succesful. No response from the encoder. I decided to run an I2C scanner and see if I could find the address - it didn't seem to work and I got no response. After that I decided to connect an OLED display parallel to the encoder and suddenly I found two devices.

Question

I don't understand what is going on, but when I have the OLED display connected, I can get a reading from the encoder. If I disconnect the display, the encoder stops working as well.

For now, I will continue with the OLED connected...

Here is the output from the Serial Plotter, when rotating the bolt.

And the next screenshot shows the noise of the signal. It is around ± 0,07° and I think averaging might be useful.

Another thing I have to take a look at is the bus address of the sensor. There two hardware pins, that should be used to change the address, but when I set the corresponding pin to HIGH or LOW - it doesn't seem to make any difference. The chip always has the same address (0x40).

Here is the code I used until this point:

#include <SoftwareSerial.h>

#include <ams_as5048b.h>
#include <Wire.h>

//unit consts
#define U_RAW 1
#define U_TRN 2
#define U_DEG 3
#define U_RAD 4
#define U_GRAD 5
#define U_MOA 6
#define U_SOA 7
#define U_MILNATO 8
#define U_MILSE 9
#define U_MILRU 10

AMS_AS5048B mysensor;

// Encoder Pinout
#define A1 PIN_PF1
#define A2 PIN_PF0

// Pinout other
#define TTL_TX PIN_PF4
#define TTL_RX PIN_PF5

SoftwareSerial mySerial(TTL_RX, TTL_TX); // Serial for debugging

void setup(){
  mySerial.begin(9600);
  delay(1000);
  mySerial.println("VÍ SKÖLL");
  mySerial.println("Sun Tracker");
  mySerial.println(".........");

  digitalWrite(A1,LOW);
  digitalWrite(A2,LOW);

  Wire.begin();
  delay(100);
  mysensor.begin();
  delay(100);
  mySerial.println("Setup complete");

}


void loop(){

  mysensor.updateMovingAvgExp();

  mySerial.print(">");

  mySerial.print("angle:");
  mySerial.print(mysensor.angleR(U_DEG, false), DEC);
  mySerial.print(",");
  mySerial.print("avg:");
  mySerial.println(mysensor.getMovingAvgExp(U_DEG), DEC);

  delay(200);

}

Eventually, after a lot of troubleshooting, I found out that the wiring harness was damaged. One crimping was faulty (no connectivity), but for no obvious reason.

I checked the other harness and there I found two more faulty crimpings!

After having doublechecked and fixed all wiring issues, the pins A1 and A2 could be used to set the I2C address. Because I shorted A1 and A2 on one breakout board and not on the other, it is ensured that I will always get two different addresses, with the address pins set HIGH (0x41 and 0x43).

Next I looked into zeroing the angles. This should be possible, by sending a zeroing command to the encoder.

First I tried setZeroReg(); and it did indeed zero the angle, but only until the next reboot.

After more trial & error, I decided to use the avr/eeprom.h library to save the zero values there, instead of trying to correct the angle directly on the encoder.

Because the EEPROM is organized and addressed in bytes - I had to use the eeprom_write_word command, where word means a two-byte (16 bit) memory. I only use 14 bits, because that is the resolution of the encoder.

Here is the loop example for zeroing the azimuth encoder. It is for now, triggered by the push button on the PCB.

void zero_az(){
  az_zero = az_enc.angleRegR();
  if(az_zero > 16383 || az_zero <= 0){
    mySerial.println("az zeroing failed");
    az_zero_ok = false;
  }else{
    mySerial.println("setting new az zero");
    eeprom_write_word(0,az_zero);
    if(eeprom_read_word(0) == az_zero){
      mySerial.println("success");
      az_zero_ok = true;
    }else{    
      mySerial.println("az zeroing failed");
      az_zero_ok = false;
    }
  }
}

The next step is to combine the encoder reading together with the motor control and have the axes move into a certain position.

Reducing friction

I realized, that the motors are barely powerful enough to run the drives. There seems to be a lot of friction and therefore I decided to take a better look and improve them.

The first thing is wanted to improve is the flex spline. It requires some force to flex it and the current design doesn't have the same circumference all over, because of the the way the flexure is designed. I made two more iterations on and the latest one is much smoother and easier to flex.

Another improvement point is the shape of the spline teeth. I don't need the round shape of the timing belt anymore, so more sharp / triangular shaped teeth may also contribute to reducing friction. This is an improvement for the next prototype.

Another point where I could reduce friction was in between the components of the drive. In some areas the tolerances between parts rotating at different speeds where to small and when using the main bolt to held everything together, friction increases because of the parts being pulled together. I was able to improve that with some manual machining / sanding.

Balancing the Arm

To reduce the required torque of the zenith drive, I decided to utilize the protuding end of the carbon tube to add some counterweight.

I removed the drive and places the arm in a horizontal position. Then I measured roughly what weight would be required to balance the arm. About 1 kg seems to be appropriate.

Next I tried to come up with a clever way to make a counterweight that could be clamped to the hex tube and adjusted.

As lead weights are not easily available in the shape and size I have in mind - I might go for stainless steel and just cut a Ø40 mm shaft.

Here is the idea in Fusion with a plastic clamp for mounting and lateral adjustment.

And here is the latest 3D model in the viewer.