collapse

Author Topic: Dagu 5 encoders  (Read 8986 times)

MEgg

  • Sr. Member
  • *
  • Posts: 262
Dagu 5 encoders
« on: October 05, 2015, 06:22:39 PM »
I know that this has been answered in the LMR forum but this has all vanished there.
I am using the Spider controller
http://cdn.instructables.com/FOP/HB95/HZ3YCGC0/FOPHB95HZ3YCGC0.MEDIUM.jpg
and the 4 channel motor controller
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Robotics/4%20Channel%20instruction%20manual.pdf  .
I measured the encoder values of (currently) 2 motors with a program like this (I just post a sceleton, I measured already all 4 motors):
Code: [Select]
volatile unsigned long encodercountHR = 0;
volatile unsigned long encodercountHL = 0;
[...]
void encodercountHR_intproc()
{
    encodercountHR++;
}

void encodercountHL_intproc()
{
    encodercountHL++;
}

[...]

void setup()
{
[...]
  attachInterrupt(digitalPinToInterrupt(MOTOR2INT), encodercountHR_intproc,CHANGE);
  attachInterrupt(digitalPinToInterrupt(MOTOR1INT), encodercountHL_intproc,CHANGE);
[...]
  time = millis();
  time2= 0;
  time3= 0;
}

void loop()
{
  if (Serial2.available())
  {
     // setting the motor to direction and PWM-duty cycle with certain keystrokes
  }
  time2=millis();
  if ((time2 - time)>=1000)
  {
     time3=time3+(time2 - time);
     Serial2.print("Time: ");
     Serial2.print(time3);

     Serial2.print(", encoder-HR:");
     Serial2.print(encodercountHR);
     Serial2.print(", encoder-HL:");
     Serial2.println(encodercountHL);
               
     time = millis();
   }
}

Thats how I simply get the time/encoder values for a certain PWM duty cycle.
Since the loop with non serial input available is very short with the 
  if (Serial2.available())
  {
  }
(unless Serial2.available() itself is very slow which I did not measure) the measurement should be ok.

There might be a slight delta of time and encoder between
time2=millis();
and
Serial2.print of the encoder values, but if I would miss encoder values,
then there would not be a straight line that one can produce out of the values, but jumps.
The two motors show straight lines with different PWM duty cycles but the gradient is different which fits to the different
encoder values for one turn per motor.
In LMR they say my Dagu 5 is broken,
on some other forum the deviation from 333 per turn was marked as "OK".

The measured encoder values for 1 turn are:
Motor 1 (backwards left) : 320
Motor 2 (front left): 236
Motor 3 (front  right): 320
Motor 4 (backwards right): 280

What is true?
« Last Edit: October 05, 2015, 06:31:47 PM by MEgg »
1st project: Dagu 5 Rover + Dagu - 4 Channel DC Motor + Red Back Spider robot controller + Raspberry B+
Chassis + wheels: https://picload.org/image/dggroior/20150831_028.jpg
current: https://www.keepandshare.com/userpics/m/a/r/k/usegg/2016-04/sb/img_3480-79682018.jpg

Duane Degn

  • Mr. 101
  • Member
  • *
  • Posts: 105
Re: Dagu 5 encoders
« Reply #1 on: October 06, 2015, 01:56:58 AM »
This is very strange.

You have magnetic encoders right?

Are these values consistent?

I always got the exact number of encoder ticks expected with my Rover 5 bots.

One thing I suggest is to try some quadrature encoder code. Even if it's just for one motor. Hook up the encoders and turn the wheels by hand (with the motors disconnected from power). If you can confirm these results with different software and without using the XOR circuit, then I think you could be more certain if something is broken.

I don't suppose you have access to an oscilloscope or a logic analyzer?

MEgg

  • Sr. Member
  • *
  • Posts: 262
Re: Dagu 5 encoders
« Reply #2 on: October 06, 2015, 03:27:31 PM »
This is very strange.

You have magnetic encoders right?

As far as I know the newer ones are with hall sensors.

Are these values consistent?

At least my encoder values measured over some time give a straight line where the motor with more encoder "ticks" has a higher gradient than
the one with less encoder ticks.
I interpret this as "consistent".

I always got the exact number of encoder ticks expected with my Rover 5 bots.

One thing I suggest is to try some quadrature encoder code. Even if it's just for one motor. Hook up the encoders and turn the wheels by hand (with the motors disconnected from power). If you can confirm these results with different software and without using the XOR circuit, then I think you could be more certain if something is broken.

I don't suppose you have access to an oscilloscope or a logic analyzer?

Which software can you recommend?
I mostly found
http://www.pjrc.com/teensy/td_libs_Encoder.html
and a lot of various stuff here:
http://playground.arduino.cc/Main/RotaryEncoders

I have a cheap osci from Peaktech and there also seems to be a way to
get Raspberry to do that:
http://abyz.co.uk/rpi/pigpio/piscope.html
1st project: Dagu 5 Rover + Dagu - 4 Channel DC Motor + Red Back Spider robot controller + Raspberry B+
Chassis + wheels: https://picload.org/image/dggroior/20150831_028.jpg
current: https://www.keepandshare.com/userpics/m/a/r/k/usegg/2016-04/sb/img_3480-79682018.jpg

MEgg

  • Sr. Member
  • *
  • Posts: 262
Re: Dagu 5 encoders
« Reply #3 on: October 06, 2015, 04:41:15 PM »
I included the library from here:
http://www.pjrc.com/teensy/td_libs_Encoder.html
and with the example code given there I printout the XOR Encoder count and the encoder values from the library accumulated.
I did this only for one motor.
The accumulated values from the library say 1580 whereas the XOR encoder value says 4594 after some run with full speed.
A run with lower speed gives values like 1340 from the lib and 2691 from my code, so the error of the library depends on speed.

The encoder A and encoder B are both on interrupt lines which would be "Best Performance" (according to the library authors).
But it looks like my own code for the XORed encoder values on another 3rd interrupt pin seems to be faster.

According to specification the encoder library should produce half of the XORd encoder values.
So the library should report 2297 and not 1580.
ENCODER_OPTIMIZE_INTERRUPTS gives a plain compiler error and I do not want to debug this now.
Therefore I come to the conclusion that this library does not help me.

Does anybody know a better library for testing?
1st project: Dagu 5 Rover + Dagu - 4 Channel DC Motor + Red Back Spider robot controller + Raspberry B+
Chassis + wheels: https://picload.org/image/dggroior/20150831_028.jpg
current: https://www.keepandshare.com/userpics/m/a/r/k/usegg/2016-04/sb/img_3480-79682018.jpg

Duane Degn

  • Mr. 101
  • Member
  • *
  • Posts: 105
Re: Dagu 5 encoders
« Reply #4 on: October 06, 2015, 05:29:10 PM »
It would be good if we could use the same microcontroller and the same code to compare results.

I have a Teensie somewhere but I haven't installed the software to use it and I'm not sure my current computer would survive having any additional software installed (I'm shopping for a new PC now).

I have an Arduino Uno. Do you have an Uno or something similar?

I don't suppose you have a board with a Propeller microcontroller? (Since you're relatively new you might not know I'm a big fan of the Propeller.)
If you have a QuickStart board or other Propeller board, I'd have an easier time suggesting diagnosis software.

Still an Arduino should work.

MEgg

  • Sr. Member
  • *
  • Posts: 262
Re: Dagu 5 encoders
« Reply #5 on: October 07, 2015, 04:52:29 PM »
It would be good if we could use the same microcontroller and the same code to compare results.

I have a Teensie somewhere but I haven't installed the software to use it and I'm not sure my current computer would survive having any additional software installed (I'm shopping for a new PC now).

I have an Arduino Uno. Do you have an Uno or something similar?

I am using the Spider controller and the 4 channel motor controller as shown here:
http://robosavvy.com/store/dagu-rover-5-arduino-kit-4-motors-and-4-encoders.html
The Spider controller is a Arduino Mega 2560 in fact, the description on the webshop is wrong, it's not a Arduino Mega 1280.

I don't suppose you have a board with a Propeller microcontroller? (Since you're relatively new you might not know I'm a big fan of the Propeller.)
If you have a QuickStart board or other Propeller board, I'd have an easier time suggesting diagnosis software.

Still an Arduino should work.

I am just thinking of mounting an additional encoder like
https://www.sparkfun.com/products/12629
on the motor with the low 236 encoder ticks.

Yes I am new to this but I knew that it is not that easy.
;-)
1st project: Dagu 5 Rover + Dagu - 4 Channel DC Motor + Red Back Spider robot controller + Raspberry B+
Chassis + wheels: https://picload.org/image/dggroior/20150831_028.jpg
current: https://www.keepandshare.com/userpics/m/a/r/k/usegg/2016-04/sb/img_3480-79682018.jpg

Duane Degn

  • Mr. 101
  • Member
  • *
  • Posts: 105
Re: Dagu 5 encoders
« Reply #6 on: October 08, 2015, 12:09:47 AM »
I don't don't have a Mega or a clone of a Mega. I was thinking we could both try the same software and hopefully nearly identical hardware to make sure it's the encoder hardware which are causing the trouble. If you had an Uno or board which used the same I/O pins as an Uno, we could both run the same program for testing. I doubt it would be hard to modify code which works on one Arduino to work on a different model so hopefully we could compare notes even if we don't use the same processor.

From what you've described it sure sounds like the problem is faulty encoders. Have you contacted the sellers of the Rover 5 to see what would be needed to exchange? Is this an option?

If exchanging the Rover 5 isn't an option, you could try opening the gearbox and attempt to repair the encoders. I think the optical encoders had some trim pots on the board to make adjustments. Perhaps there is a way of adjusting the magnetic encoders.

I don't suppose you have a magnetometer like the HMC5883L? If you do, you may be able to check the encoder's 8-pole disk. Perhaps the magnets in the disk are too weak and a new disk would fix the problem.

I think you'd have a hard time adding the encoder you linked to a Rover 5. I can't think of how you'd mount the encoder.

I'm not sure if it would help, but since you mention being new this sort of thing, it might be helpful to post a photo of how you've wired the encoders.

MEgg

  • Sr. Member
  • *
  • Posts: 262
Re: Dagu 5 encoders
« Reply #7 on: October 11, 2015, 09:03:00 PM »
I don't don't have a Mega or a clone of a Mega. I was thinking we could both try the same software and hopefully nearly identical hardware to make sure it's the encoder hardware which are causing the trouble. If you had an Uno or board which used the same I/O pins as an Uno, we could both run the same program for testing. I doubt it would be hard to modify code which works on one Arduino to work on a different model so hopefully we could compare notes even if we don't use the same processor.

From what you've described it sure sounds like the problem is faulty encoders. Have you contacted the sellers of the Rover 5 to see what would be needed to exchange? Is this an option?

If exchanging the Rover 5 isn't an option, you could try opening the gearbox and attempt to repair the encoders. I think the optical encoders had some trim pots on the board to make adjustments. Perhaps there is a way of adjusting the magnetic encoders.

I don't suppose you have a magnetometer like the HMC5883L? If you do, you may be able to check the encoder's 8-pole disk. Perhaps the magnets in the disk are too weak and a new disk would fix the problem.

I think you'd have a hard time adding the encoder you linked to a Rover 5. I can't think of how you'd mount the encoder.

I'm not sure if it would help, but since you mention being new this sort of thing, it might be helpful to post a photo of how you've wired the encoders.

I am in contact with the seller robosavvy where I bought my bundle.
They answer quite quick.

If I open the encoder case I'll lose my warranty so I am just talking to them, what is possible.

I wired the encoder XOR to interrupt pins of the spider controller.
Since all 4 motors have been tested on the same channel, the error is not in software or connected pins, but quite surely within the encoder somewhere.
« Last Edit: October 11, 2015, 09:08:30 PM by MEgg »
1st project: Dagu 5 Rover + Dagu - 4 Channel DC Motor + Red Back Spider robot controller + Raspberry B+
Chassis + wheels: https://picload.org/image/dggroior/20150831_028.jpg
current: https://www.keepandshare.com/userpics/m/a/r/k/usegg/2016-04/sb/img_3480-79682018.jpg

Duane Degn

  • Mr. 101
  • Member
  • *
  • Posts: 105
Re: Dagu 5 encoders
« Reply #8 on: October 11, 2015, 10:36:43 PM »
Since all 4 motors have been tested on the same channel, the error is not in software or connected pins, but quite surely within the encoder somewhere.

It sure sounds like there's a problem with the hardware.

I remember OddBot saying something about the magnetic encoders were supposed to be more reliable than the optical encoders.

Hopefully you'll get this straightened out soon.

MEgg

  • Sr. Member
  • *
  • Posts: 262
Re: Dagu 5 encoders
« Reply #9 on: November 02, 2015, 05:10:15 PM »
Since the helpful robosavvy guys said that I should test the Encoder A output and the encoder B output additionally to the quadrature output of the
Dagu 4 Channel motor card I did this now without library for the motor delivering the worst values.

Approx 3 turns show:
Encoder A:617  Encoder B:618
and quadrature output: 735

approx. 10 turns show:
Encoder A:2049  Encoder B:2051
and quadrature output:2490

One of the other motors shows 4286 quadrature counts for the 10 turns.

Which in my opinion shows two faults:
1) the encoder of  the worst motor is broken and delivers lower values than the other 3 motors
2) the CD4030B XOR circuit on the Dagu 4 channel motor controller is broken.

Therefore in my opinion I will have to exchange the Dagu Rover 5 and the 4 channel motor controller card.
1st project: Dagu 5 Rover + Dagu - 4 Channel DC Motor + Red Back Spider robot controller + Raspberry B+
Chassis + wheels: https://picload.org/image/dggroior/20150831_028.jpg
current: https://www.keepandshare.com/userpics/m/a/r/k/usegg/2016-04/sb/img_3480-79682018.jpg

MEgg

  • Sr. Member
  • *
  • Posts: 262
Re: Dagu 5 encoders
« Reply #10 on: November 09, 2015, 04:50:34 PM »
The support of robosavvy.com is very good.
I got a new Dagu 5 kit after doing some more measurements.
They also said that it is a hardware problem.
Now I have to dismantle the old robot and build up the new kit.
1st project: Dagu 5 Rover + Dagu - 4 Channel DC Motor + Red Back Spider robot controller + Raspberry B+
Chassis + wheels: https://picload.org/image/dggroior/20150831_028.jpg
current: https://www.keepandshare.com/userpics/m/a/r/k/usegg/2016-04/sb/img_3480-79682018.jpg

OddBot

  • Member
  • ****
  • Posts: 47
  • Have fun every day!
Re: Dagu 5 encoders
« Reply #11 on: November 15, 2015, 10:25:49 PM »
I doubt very much it is a hardware problem. Your encoder A and B outputs sounded correct. The Quadrature output is wrong but that is more likely a software fault. The output of the XOR should be equal to encoder A + Encoder B.

Using just simple code to count A and B can cause some errors because when you start and stop turning the wheel you can get a "vibration" error on one pin or the other. That is why after 10 turns you had a difference of 2.

When you use the correct code to use the outputs A and B together it can recognize and cancel out the vibration error because it will take direction into account. Any backward / forward vibration is cancelled out.

I discovered this when I was trying to get OB1 to move precise distances. Bad code = Bad result.

« Last Edit: November 15, 2015, 10:34:38 PM by OddBot »

MEgg

  • Sr. Member
  • *
  • Posts: 262
Re: Dagu 5 encoders
« Reply #12 on: November 20, 2015, 10:42:48 AM »
I doubt very much it is a hardware problem. Your encoder A and B outputs sounded correct. The Quadrature output is wrong but that is more likely a software fault. The output of the XOR should be equal to encoder A + Encoder B.

Using just simple code to count A and B can cause some errors because when you start and stop turning the wheel you can get a "vibration" error on one pin or the other. That is why after 10 turns you had a difference of 2.

When you use the correct code to use the outputs A and B together it can recognize and cancel out the vibration error because it will take direction into account. Any backward / forward vibration is cancelled out.

I discovered this when I was trying to get OB1 to move precise distances. Bad code = Bad result.

The same code is ok for the other encoders so I think that it is not a software problem.
Normally I only use the Quadrature output and that is where I realized that 2 of the encoders produced wrong counting with the same software code.
The other 2 encoders are ok.
I have got now a 2nd kit since robosavvy acknowledged that is a hardware problem after some tests.
1st project: Dagu 5 Rover + Dagu - 4 Channel DC Motor + Red Back Spider robot controller + Raspberry B+
Chassis + wheels: https://picload.org/image/dggroior/20150831_028.jpg
current: https://www.keepandshare.com/userpics/m/a/r/k/usegg/2016-04/sb/img_3480-79682018.jpg

MEgg

  • Sr. Member
  • *
  • Posts: 262
Re: Dagu 5 encoders
« Reply #13 on: November 27, 2015, 06:54:38 PM »
Got the 2nd Dagu5 set.
This time the encoders are ok.
Not exactly 333 encoder ticks per turn, but no deviation like the last time which was something like the lowest value being around 73% of
the highest.

1st project: Dagu 5 Rover + Dagu - 4 Channel DC Motor + Red Back Spider robot controller + Raspberry B+
Chassis + wheels: https://picload.org/image/dggroior/20150831_028.jpg
current: https://www.keepandshare.com/userpics/m/a/r/k/usegg/2016-04/sb/img_3480-79682018.jpg

 

* Search


* Recent Topics

The unnamed (yet) quatruped spider project by tinhead
[July 01, 2020, 04:22:11 PM]


"1984 Nixie Time" by 1 what
[May 08, 2020, 01:04:18 AM]


2D Side Scroller Cyberpunk themed by Killer Angel
[February 06, 2020, 06:39:40 AM]


A new wing design for model aircraft / drones by OddBot
[February 06, 2020, 04:42:06 AM]


SDR (Software Defined Radio) by Gareth
[February 02, 2020, 06:15:42 AM]


Circuit Math by ZeroMax
[January 31, 2020, 01:50:18 PM]


NanOMeter by Protowrxs
[January 01, 2020, 12:59:44 PM]


Investigating the VL53L0X Laser Rangefinder by erco
[December 30, 2019, 10:45:44 PM]


PS4 Single Handed Controller Deployed (part 7 of 7) by Gareth
[December 30, 2019, 09:52:29 AM]


"D" -Pad Workio just like Magic (Will Merlin stay or Go) (part 6 of 7) by Gareth
[December 30, 2019, 09:51:27 AM]


PS4 Joystick Digitals 4,5,6,7,10 - Analog's Lx,Ly,Rx,Ry Workio (part 5 of 7) by Gareth
[December 30, 2019, 09:50:37 AM]


Menu Workio ! (part 4 of 7) by Gareth
[December 30, 2019, 09:49:49 AM]


L1 trigger design Workio (Hori controller) (part 3 of 7) by Gareth
[December 30, 2019, 09:48:50 AM]


Hori aka PS4 Joystick Mappings (part 2 of 7) by Gareth
[December 30, 2019, 09:47:17 AM]


PS4 Single Left-Handed Controller (part 1 of 7) by Gareth
[December 30, 2019, 09:44:58 AM]

* Recent Posts

Re: The unnamed (yet) quatruped spider project by tinhead
[July 01, 2020, 04:22:11 PM]


Re: The unnamed (yet) quatruped spider project by jinx
[July 01, 2020, 04:06:19 PM]


Re: "1984 Nixie Time" by 1 what
[May 08, 2020, 01:04:18 AM]


Re: "1984 Nixie Time" by tomasp
[April 13, 2020, 06:03:28 PM]


Re: 2D Side Scroller Cyberpunk themed by Killer Angel
[February 06, 2020, 06:39:40 AM]


A new wing design for model aircraft / drones by OddBot
[February 06, 2020, 04:42:06 AM]


Re: "1984 Nixie Time" by Gareth
[February 02, 2020, 06:23:01 AM]


Re: SDR (Software Defined Radio) by Gareth
[February 02, 2020, 06:15:42 AM]


Re: SDR (Software Defined Radio) by ZeroMax
[January 31, 2020, 01:54:21 PM]


Re: "1984 Nixie Time" by ZeroMax
[January 31, 2020, 01:52:29 PM]


Circuit Math by ZeroMax
[January 31, 2020, 01:50:18 PM]


Re: 2D Side Scroller Cyberpunk themed by ZeroMax
[January 31, 2020, 01:45:33 PM]


NanOMeter by Protowrxs
[January 01, 2020, 12:59:44 PM]


Re: Investigating the VL53L0X Laser Rangefinder by erco
[December 30, 2019, 10:45:44 PM]


PS4 Single Handed Controller Deployed (part 7 of 7) by Gareth
[December 30, 2019, 09:52:29 AM]