Trying to make it work with other components

[mitarashki]

Hello Werner. First of all I would like to thank you for sharing this amazing system to all of us. It is a great way to film with cable cam more safely. I really appreciate your work. Thanks again

[mitarashki]

I am currently trying to make your system work with a bit different components like:

1) Instead of using ESC I am with : https://www.pololu.com/product/1372 It is a DC brushed motor controller 2) Instead of using Hall sensors I am using 500 P/R encoder connected the same way to the board like you described it for Hall sensors

Because I am not really a software guy I would like to ask you some questions about the problems I experience with my setup.

I am to a point where everything works but not exactly like expected :) When I power on the system its all good. I enter program mode where everything works fine (ex. motor is moving smooth in both directions, position 1 & 2 is recorded successfully) When I switch to "Operation mode" and give command above the end point it does not move (like it have to be), but when a command for moving to the first end point is given the motor starts spinning in pulses (not smooth) and when it reaches the end point stops. Also when applying command in "Operational mode" in the PuTTY lot of lines saying "Endpoint brake on" are displayed. If there is a possibility for you to help me with my problem I would be very grateful.

The other components I am using are: -Airbot F4 MPU6000 -S.bus receiver paired with Spektrum DX7s -60V DC Brushed motor

Thank you very much in advance Werner.

[wernerdaehn]

I am having troubles grasping the problem. Can you create a short youtube video?

One thought I have is the $r command, the rotational direction. But this is important only when you are over the end point. And that does not sound like your problem.

[mitarashki]

OK Werner, I will do it tomorrow morning and will send you the link. Thanks a lot for helping. Do you think that using a high resolution encoder instead of hall sensor might be a part of the problem?

[wernerdaehn]

We might find issues, but not the ones you are describing. No, would not expect that.

Reading your text again, maybe it truly is the $r command. Can you do me a favor and check what it is set at the moment? And reverse it. So from +1 to -1 or vice versa. I have checked the code sequence around the "Endpoint brake on". It checks if the current position according to the hall sensors plus/minus the calculated brake distance would go beyond the start or end point. If yes, it does engage the brake. Trouble is, if you are very close to one of the endpoints but driving away from it, above logic would still kick in the brake. So the controller needs to know if the current stick position drives the motor towards or away from the end point. That is what the $r command controls. Is a positive stick a movement towards the start or the end point.

Now imagine it would be the wrong value and you are close the end position. You start driving away, pick up some speed and now the calculated brake distance is high enough so that pos + brake distance > endpoint. Brake kicks in. Until the speed is low enough so that above condition is no longer met. It would accelerate again. With the correct $r value the controller would see you are driving away from the end point and hence test for the start point only.

[mitarashki]

It sounds to me that this might be the problem because I was trying it with just 5-10 rotations of distance between the two end points which is probably too close. I have already tried to change the $r value but there was no change in the behavior of the motor. Now it is set to +1. I will be back tomorrow morning in my workshop and try to set the end points with bigger distance between. Will update you with the result as soon as make the test.

-I am also wondering what might be the right value for $g, considering that I am using 500 steps per revolution? -When $p is applied it shows 1-----0-----0 . Is that what should be displayed

[wernerdaehn]

If $g would kick in, the console would say "Emergency brake". This $g is just a failsafe. Imagine something is totally wrong and slowly moving the virtual stick to zero does not have the effect of slowing down the cable cam to the degree needed. Then the controller gives up on everything and screams: Speed=0. Now. And hopefully the ESC stops the cable cam then.

$p is certainly wrong. It appears the start and end position is one and zero. Actually, there is something fishy, if that is the readout you get. The code reads:

case PROTOCOL_POS:
    writeProtocolHead(PROTOCOL_POS, endpoint);
    writeProtocolLong(activesettings.pos_start, endpoint);
    writeProtocolLong(activesettings.pos_end, endpoint);
    writeProtocolLong(getPos(), endpoint);
    writeProtocolDouble(getSpeedPosDifference(), endpoint);
    writeProtocolDouble(getSpeedPosSensor(), endpoint);
    writeProtocolOK(endpoint);
    break;

[mitarashki]

https://youtu.be/IXC9dJT70Vg Hello Werner. That is the link with the video of my problem.

[wernerdaehn]

After you have programmed the end points, what does $p say?

[mitarashki]

After recording the two endpoints, $p says -1 -1 -1

[wernerdaehn]

Encoder obviously does not update the position. Any idea why?

[mitarashki]

I have just tried 3 different encoders:

1 1024 steps/revolution

2 500 steps/revolution

3 100 steps/revolution

After recording the end points in programming mode successfully the $p says always one of those: 1 1 0 or -1 -1 0 or 0 0 1 or -1 0 0 never goes over 1 or below -1

I have no idea why is that happening. Any idea what I should try ?

[wernerdaehn]

Since the value does change, it does get signals. Let's assume that for a minute. Can you use the 100steps encoder and move it by hand very slowly. I'd like to know if the frequency is too high for it to recognize which input comes first.

I am not using any prescaler, filter or anything else. So it should not be that. Do you have an osscilloscope with two channels to see how the two pulses relate to each other? And the data sheet of your encoder might reveal something.

(main.c)

htim5.Instance = TIM5;
htim5.Init.Prescaler = 0;
htim5.Init.CounterMode = TIM_COUNTERMODE_UP;
htim5.Init.Period = 4294967295;
htim5.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1;
sConfig.EncoderMode = TIM_ENCODERMODE_TI12;
sConfig.IC1Polarity = TIM_ICPOLARITY_RISING;
sConfig.IC1Selection = TIM_ICSELECTION_DIRECTTI;
sConfig.IC1Prescaler = TIM_ICPSC_DIV1;
sConfig.IC1Filter = 0;
sConfig.IC2Polarity = TIM_ICPOLARITY_RISING;
sConfig.IC2Selection = TIM_ICSELECTION_DIRECTTI;
sConfig.IC2Prescaler = TIM_ICPSC_DIV1;
sConfig.IC2Filter = 0;
if (HAL_TIM_Encoder_Init(&htim5, &sConfig) != HAL_OK)
{
    _Error_Handler(__FILE__, __LINE__);
}
sMasterConfig.MasterOutputTrigger = TIM_TRGO_RESET;
sMasterConfig.MasterSlaveMode = TIM_MASTERSLAVEMODE_DISABLE;
if (HAL_TIMEx_MasterConfigSynchronization(&htim5, &sMasterConfig) != HAL_OK)
{
    _Error_Handler(__FILE__, __LINE__);
}

[mitarashki]

That is the datasheet of the encoder: https://www.mouser.com/ds/2/678/V02-1046EN_DS_HEDM-55xx_2014-11-20-909010.pdf

I have tried moving it slowly by hand and it says again 0 1 0

[wernerdaehn]

Do you supply it with 5V or 3.5V? It needs 5V. Are you using Ch.A plus Ch.B and not Ch.I as input to the cable cam controller?

[mitarashki]

Yes I am using Ch.A & Ch.B as input to the cable cam controller but the supply voltage is 4.3V not 5V. My motor controller output is 4.3V Is this a possible reason for the problem?

[wernerdaehn]

Unlikely but not impossible. Your encoder has an active circuit and it says as Recommended Operating Conditions: 4.5 to 5.5V. But as said, will work with 4.3V as well. On the other hand, what else?

Just to doublecheck, can you make photos so I can see the electrical connections from the encoder to the cable cam board?

[mitarashki]

This a test I did with the 100steps encoder using two light diodes and resistors https://youtu.be/AhPSVrRC7mA I will send you pictures in a minute

[mitarashki]

[wernerdaehn]

Hm. So it is not the encoder and the used pins are correct as well. What else could it be????

You have connected the LED with +5V and the yellow resp. white cable. So whenever the encoder pulls the yellow/white cable to GND the LED emits light. An opencollector circuit just like my Hall sensors have.

Let me solder a header to your flight controller, I got one meanwhile as well, and simulate the position input via switches. This will give us a another point of proof to isolate the issue.

If you have an idea, please let me know. I am a bit baffled at the moment.

[mitarashki]

Please excuse me but I couldn't understand that : "Let me solder a header to your flight controller, I got one meanwhile as well, and simulate the position input via switches. This will give us a another point of proof to isolate the issue."

[wernerdaehn]

Sorry, mixed up two conversations. Let me put it this way: I'd like to setup a test for you to follow in order to check if the problem is on the encoder side or the cablecam controller side.

[wernerdaehn]

I have a second board that looks just like yours. (Bought it because of another question we had previously) http://www.readytoflyquads.com/flip32-f4

I have programmed the firmware and tested the servo5&6 with switches and did not get position update either. Hence I measured if servo5=PA0 and servo6=PA1. Yes for servo5 but servo6 is connected to another pin on the MCU. The PA1 pin is connected to a pad on the other side's 3x9 header, the pad exactly in the middle of it. If I use that, the $p shows position updates.

So to cut a long story short: Hardware looks similar but the connector layout is not identical. Good to know.

[mitarashki]

OK, I am doing a test right away. Is that the correct pin for PA1 ?

[wernerdaehn]

No, one step to the left. It is really the center one, with four holes above and below and one hole left and right.

[mitarashki]

Hey Werner. Thank you very much for your great support. Now everything works perfect. I have tried it with two different encoders (100 S/R and 400 S/R) and with both of them the systems works. Thank you again. I am starting to assemble my cable cam and when it is all together I will keep you updated for the results on the rope.

I really appreciate you help end effort.

[wernerdaehn]

Yipeeeh! ;-)

[mitarashki]

YOU ROCK MAN :+1: :)