Tri-track/Rover with Basic Micro Roboclaw+++

Lynxmotion Rovers, Sumo, and Tracked
1

I was asked if I would like to try out a new Basic MicroRobo-Claw]motor controller, which sounded like a lot of fun. Well it arrived late last week, so yesterday I started to integrate it into my Tri-track robot, which I purchased with motors with encoders. The Robo-claw is a very interesting motor controller. It starts off as being compatible with the Sabertooth controller I just removed. It supports several different ways for the robot to control it, including the standard PWM signals, plus Analog, Plus a simple serial and a Packet serial mode. It then goes beyond that and supports two quadrature encoders.

In addition to this I am using a Zeus 3Amp power regulator to power up the BAP from the 12v Battery, plus a Cylon Blue LED display and later I may move one of my guns from the Mech-brat to the tri-track and control the gun using a Bit Switch.

Please pardon that I have not cleaned up the wiring and there is still some dust… But here are a few pictures.Tri-track-front.jpg

Tri-track-front.jpg
Tri-track-front.jpg600×554 34.7 KB
I installed both the BB2 as well as the motor controller on top as I will be doing lots of wiring changes and changes the switches I wanted to make it simple.

So far with the code, I stripped down an earlier version of the rover with an Arm code (IE I removed the arm) and is controlled by a PS2 controller. Currently I have under #ifdef code three different ways to work with the controller (PWM, simple serial, packet serial). Now that I have these working, I will now stick with Packet mode as I am about to start playing with the encoders!

Kurt

tri-track-back.jpg
tri-track-back.jpg600×520 38 KB

2

After frying my first set of encoders (accidentally reversed power wires), I have my replacements and am starting to play with them

I have it that the R1 on PS2 clears the encoders and R2 prints out current values. Not very far yet, but using a tape measure and rolling the tri-track forward about 37.5 inches I got measurements around 71000 or about 1900 units per inch. So I can go about 1.25 million inches before overflow.

Next experiment may be something like have it roll forward under my control and then when I press a button have it try to roll back under the roboclaws control.

Kurt

3

1.25 million inches = 19.7285354 miles 8)

4

Well the beauty is that even when it overflows the RoboClaw flags which direction(underflow or overflow) so the next time you read you can check if it just overflowed. So as long as you read it atleast once every 19 miles or so you will never lose position pulses with this setup. :slight_smile:

5

Yep, needless to say that won’t be a problem, my 12v 1600mah battery won’t make it that far :laughing:

Back to experimenting: I borrowed the LCD display that I had on the rover toput on the tri-track so I can display things like encoder counts…

So I thought I would try some of the use encoder to set speed and distance (commands 40-47). So I have tried a couple of variations, but the current code tries command 44, which says drive move motors forward. It currently looks like:

	IF (DualShock(2).bit2 = 0) and LastButton(1).bit2 THEN	;L1 Button test
		; lets try to go forward about a feet, under the control of the encoder.
		REncoderCnt = 1900 * 12	;  lets see how close this is
		RencoderSpeed = 2500	;	It appeared like maybe 4700+ was max so lets try this.
		CRC = (RCLAW_ADDRESS + 44 + 255 + REncoderCnt.Byte3 + REncoderCnt.Byte2 + REncoderCnt.Byte1 + REncoderCnt.Byte0 + |
				REncoderSpeed.Byte3 + REncoderSpeed.Byte2 + REncoderSpeed.Byte1 + REncoderSpeed.Byte0 + |
				255 + 1) & 0x7f
		; motor 1				
		serout RCLAWSeroutPin, RCLAW_BAUD, [RCLAW_ADDRESS, 44, 255, 	|
				REncoderSpeed.Byte3, REncoderSpeed.Byte2, REncoderSpeed.Byte1, REncoderSpeed.Byte0, |
				REncoderCnt.Byte3, REncoderCnt.Byte2, REncoderCnt.Byte1, REncoderCnt.Byte0, |
				255, 1, CRC] ; go forward the specified distance at the specified speed and stop when we get there.
		; can I query to find out this is done?
#if 0 ;// try mixed mode above
		; motor 2				
		CRC = (RCLAW_ADDRESS + 42 + 255 + REncoderCnt.Byte3 + REncoderCnt.Byte2 + REncoderCnt.Byte1 + REncoderCnt.Byte0 + |
				REncoderSpeed.Byte3 + REncoderSpeed.Byte2 + REncoderSpeed.Byte1 + REncoderSpeed.Byte0 + |
				255 + 1) & 0x7f
		serout RCLAWSeroutPin, RCLAW_BAUD, [RCLAW_ADDRESS, 42, 255, |
				REncoderSpeed.Byte3, REncoderSpeed.Byte2, REncoderSpeed.Byte1, REncoderSpeed.Byte0, |
				REncoderCnt.Byte3, REncoderCnt.Byte2, REncoderCnt.Byte1, REncoderCnt.Byte0, |
				255, 1, CRC] ; go forward the specified distance at the specified speed and stop when we get there.
#endif				
		sound p9, [50\4000]
		pause (REncoderCnt/REncoderSpeed)*1000 + 500	; pause until we think the command should be done.
		sound p9, [50\5000]		
	ENDIF  
  
  	IF (DualShock(2).bit0 = 0) and LastButton(1).bit0 THEN	;L2 Button test
	ENDIF

My thought from earlier displays of encoder outputs that this should move the tritrack forward about a foot. But so far I have found that not to be the case. Each attempt appears to do differently. So I tried running this with the tri-track off of the ground so little friction. I then setup the debug cable, used my R1 button to clear out the encoders, the pressed R2 to display the counters, hit L1 to run the above code, and then hit R2 again to see the counters after it completed. The results were:

Left Encoder: 1 80 Speed: 0 0 Right Encoder: 0 80 Speed: 0 0 Left Encoder: 257214 80 Speed: 0 0 Right Encoder: 225744 82 Speed: 0 1

I was expecting counts of about 22800 and they appear to be off by a lot and the two motor values differed by a considerable amount. Not sure what to do here.

I am also wondering if instead of pausing, if instead I could do a query to find out maybe the current speed or count to decide that this previous command was completed. Will play more later.

The other side effect of the pause of several seconds is the PS2 dropped out of analog mode and things stopped working. Changed the code to now check the mode and reinit the ps2 if wrong…

Kurt

6

I’m very interested in your results and am going to be following this thread closely. I’m considering the possibility of using two RoboClaw 2x5 controllers for WALTER because I like the fact they have the encoder hardware built in. I’ll have the QME-01 encoders on at least two of WALTER’s four independently steerable GHM-04 motors. It’s time for me to go look more closely at the RoboClaw documentation. :slight_smile:

Hmmmm, no real documentation seems to be available right now. I really want to know more about the RoboClaw and am now thinking I may want to have encoders on all four motors.

8-Dale

7

I am having fun playing with it, will continue to update as I learn more.

There is a almost 50 page PDF available on the roboclaw. You can download it from the product page: basicmicro.com/Robo-Claw-2x10A_p_45.html

8

Ahhh, OK, I was trying the link for the RoboClaw 2x5 and that PDF link does not work.

I’ll assume for now the 2x5 works the same way as the 2x10. :slight_smile:

8-Dale

9

What motors are you using with the RoboClaw? I have GHM-04 motors. So far, I haven’t found any indication that the RoboClaw will work with other than 12v motors. I’d be getting a RoboClaw 2x5 if I use them.

8-Dale

10

I have GHM16 motors I think, which are 12V and I use QME01 encoder. Not sure which Roboclaw I have as I don’t see any model number on it. My guess is a 10 or 25 as it has large capacitors and heat sink. My quick look at the spec looks like it can handle voltages between 6 and 30 so a 7.2 should not be a problem.

Kurt

11

Very good! This means I should be able to use RoboClaw 2x5 controllers for WALTER. Right now I have a Sabertooth 2x5, so will have to work with it until I can get a RoboClaw. I’ll need two motor controllers for the final 4WD version of WALTER. I alead have a pair of GHM-04 motors with QME-01 encoders installed and ready to go. :smiley:

Do you have code you could show for the RoboClaw??

8-Dale

12

Not much yet, just what is in the basic file I uploaded a couple of posts back.

Kurt

13

I read through the RoboClaw docs, especially the Packet Serial and Quadrature Decoder sections. It looks like some calculations will be in order to convert between real world units, which is fine. That’s what micros are for! :smiley: I am definitely interested in getting one of the RoboClaw 2x5 units and think these will get me where I want to go with WALTER just fine. :slight_smile: I’ll eventually need a total of two of them for WALTER, since each wheel will be independently controlled as well as independently steerable. Using the Quadrature Decoders and QME-01 encoders, I should be able to detect wheel stalls and everything else I would want to do in a closed loop locomotion system.

I’m definitely exited about using the RoboClaw controllers now!! :smiley: :smiley: They will definitely simplify what I want to do. :wink:

8-Dale

14

This morning I am playing round some more to see if maybe I will use the use encoders to set speeds of both motors, then do a query to see how far it has gone and then stop when I reach a certain distance. But first I thought I would double check a few things to see if they make sense.

I think that maybe the speed calculations of the robo-claw may be having some issues. If I run both motors at about 3/4 speed, with commands like:
maybe:

serout RCLAWSeroutPin, RCLAW_BAUD, [RCLAW_ADDRESS, 0, 95, ((95 + RCLAW_ADDRESS) & 0x7f)] ; Drive forward serout RCLAWSeroutPin, RCLAW_BAUD, [RCLAW_ADDRESS, 4, 95, ((95 + RCLAW_ADDRESS + 4) & 0x7f)] ; Drive forward

When I query the encoder counts and speed I am getting values like:

Left Encoder: 161298 85 Speed: 53875 0 Right Encoder: 195705 85 Speed: 56835 0 Left Encoder: 248166 80 Speed: 54065 0 Right Encoder: 275300 80 Speed: 56755 0 Left Encoder: 269927 80 Speed: 53840 0 Right Encoder: 309312 80 Speed: 56350 0

But when I up the speed to full speed (127 instead of 95) I get really mixed up encoders speeds like:

Left Encoder: 533196 80 Speed: 1819 0 Right Encoder: 562246 80 Speed: 65130 0 Left Encoder: 626617 80 Speed: 899 0 Right Encoder: 668097 80 Speed: 65000 0 Left Encoder: 746483 80 Speed: 1084 0 Right Encoder: 788122 80 Speed: 1634 0 Left Encoder: 812027 80 Speed: 60790 0 Right Encoder: 841178 80 Speed: 65445 0

The encoder speed at the 3/4 speed appears to be rather consistent with a speed of something around 53000-56000, but I don’t understand these values.

I am using a GHM-16, that may go 200RPM. The QME-1 as 100 cycles per revolution or 400 quadrature cycles per revolution. So my first guess is that I would have a maximum of 200*400=80000 cycles per minute or about 1333 per second. Could the fact that the motor has a 50 to 1 reduction play into this?

Also trying to figure out how to use the ramp up and down speeds. That is if I want to set the encoder speed to near what the 3/4 speed, maybe like 50000, and use the max ramp up speed of 255, it will take: 196 seconds to get up to speed, which does not make sense. Need to work on this.

Kurt

15

You may have to somehow incorporate the real world speed of your motors and distance per revolution of your wheels with the quadrature counts per revolution to get reasonable base distance and speed values for other calculations. Once you know how far per revolution your wheels travel, you should be able to figure out how many encoder counts it is for that distance. Then you can figure out the smallest unit of distance you can use per some number of quadrature counts.

I think the above may also come into play here. With that, you should be able to figure out what the smallest unit of speed per some number of quadrature counts is. You should also be able to relate some number of quadrature counts to 1 unit of controller motor speed (1 - 255).

These are just some ideas based on various things I have read about encoders. I could probably help with this stuff, but don’t have a RoboClaw to work with yet. I do also have an Atom Pro to tinker with and could temporarily put it on WALTER.

8-Dale

16

Thanks Dale,

My first step to understanding this is by hooking up the logic analyzer to it. I hook it up to one of the two encoders (both channels) and the results are:Encoder-logic-scan.jpg
From this I see that each of the encoder channels are cycling about 6825 cycles per second * 4 for the 4 logic changes between the two channels is something like:
27300 cycles per second, which is maybe half the number roboclaw is reporting. Running at full speed the logic showed the cycle at about 8700 4 = 34800. So my guess is that the 30 to 1 comes into play: 20030*400/60=40000 in theory max encoder counts per second. So it is making some sense.

But there may be problems with their speed calculations.

Kurt

17

Making sense is good! :smiley:

After looking at the diagrams in the docs on board layout, it looks like there is a clock generator chip that provides the clock for the micro and the quadrature decoder. There is a possibility a problem here could be causing clock stability issues in the quadrature decoder, which certainly would affect measurement and calculation accuracy. Even with this possibility, I really hesitate to point fingers at the hardware. A more realistic possibility could be in the micro’s firmware, which would be much easier to correct.

I wish I could try out some of my ideas, but will have to wait until June to aquire at least one RoboClaw 2X5. I’m extremely interested in working on this, since I will have to figure all this out for WALTER anyways. :slight_smile: I am a MUCH better programmer than I am a hardware person. :wink:

8-Dale

18

Just to clarify. The quad encoders on most motores are direct driven from the motor so the gear ratio reduction does matter. If your gear head motor has 50:1 ratio and runs at 200rpm and your encoders are 100 per rev then your calculation is:

50 * 200 * 400 / 60 = 66667 pps at full speed

We are working with another user right now that has a similar setup. He is reporting pulse rates over 40k per second dropping pulses. This could explain the problem you are having at high speed. We are setting up a similar setup for testing. If it turns out to be the case we plan on making it switchable between 1:1 counting and 4:1 counting.

Could you explain your reasoning here? We use a common clock to make syncing the 3687 to the CPLD easier. Not sure how that could cause a stability issue. If you know something we don’t we definitely want to know.

19

Thanks Nathan, I believe the motors I have ( lynxmotion.com/Product.aspx? … egoryID=11) have a 30 to 1 reduction so:
20030400/60 = 40000

My speed looking at the encoders through the logic analyzer at about 3/4 speed, looked like the encoders were returning a value of maybe: 27300 which loooks reasonable. Which implies the motor is turning at about 137rpm which makes sense.

But the output from the roboclaw reported about 54000, which looks almost like a factor of 2.

I have been following the other thread as well.

Also have you had a chance to look at the commands that allow you to set a speed and a distance? So far I am not getting very good results with this. Will play more.

Kurt

20

Thanks much, Nathan, for the clarification.

I was merely speculating on possible causes for calculation errors. I did say I am hesitant to point fingers at the hardware. :smiley: :smiley: I would much rather deal with software problems that are more easily corrected. :wink:

I’m already looking forward to June when I can order at least one RoboClaw 2x5A for WALTER. :slight_smile:

8-Dale