CC3D-CableCam-Controller
CC3D-CableCam-Controller copied to clipboard
wernerdaehn
Deceleration problem
During some test on the rope, I found a little problem with deceleration near to the end points. I see this in autoplay, but it is the same if you drive the cablecam to end points at max speed. The problem is that the deceleration is not smooth, but a bit "choppy". I solved the problem rising the max allowed error parameters from 100 (default) to 300. Now the deceleration is smooth, but when the cablecam arrive to the end point speed is not zero (anyway is NEAR to zero) and it stop abruptly. My mind is that the calculation for deceleration have some kind of error, so, if allowed error is low the board try to adjust speed creating the "choppy" deceleration. When max error is higher, The deceleration go until the cablecam don't is on the end point, but because this error speed is not zero, so the board brake in order to don't go over the end point. My guess is that deceleration start too late, Or is less that we need. Maybe also cablecam inertia do something, anyway, is not possible to have a parameter for "anticipate" a bit the deceleration? Just for debug...
Соnfirm the same issue at high speed. May be that happens when the main wheel is blocked by the motor but the cablecam steel moving under the own mass.
We need to separate here between VESC and RC ESC. With the RC ESC there is not much I can do. I can put the stick slowly towards neutral - little brake force - or put it in idle - strong brake force. There is no proportional brake in forward/reverse mode. Hence the best is a narrow max-pos-error of 100 to switch between both brake modes more often.
With the VESC we have conflicting requirements. We want to stop at the end point, we want not to drive over the end point and we don't know the inertia of the cablecam. (Also the inertia is not static - driving up/downhill, rope tension etc). I have tried multiple things like setting the end point 100 step early and drive at low speed to the very end. Nothing really did work well.
Which of the two modes are we talking about and what is the suggestion? Also a video would be nice to agree it is the above or something that can be optimized.
I'm using vesc and not rc esc. I have a video on my phone. I'll publish it in the afternoon, but on video is not so clear what I mean.
And I am using esc from skyrc. From my side I can say that long acceleration and decceleration affect more choppy brake. Like abs on the car. When I put low accell and deccel value my cablecam slide on the rope at high speed while braking but there is no choppy effect discribed above. My suggestion to separate accel and deccel value for manual mode and for automatic braking near end points. Also it would be nice if we could independently adjust accel and deccel value.
Hence the best is a narrow max-pos-error of 100 to switch between both brake modes more often. What does it mean? In my cablecam construction there is big gear ratio and I am using 4-6s battery. So from the esc side the brake force is strong enaphf to hold the cablecam via big gear ratio.
This is a video where you can see that the Cablecam brake an go during deceleration. https://youtu.be/pfnLFQlCc9I As you can see, the Cablecam jump slightly near to the end point. No problem with accelleration. The video is with max error at default value 100. Raising at 300 (or more) the deceleration is always smooth, but when the camera is at the endpoint speed is not zero, so it brake abruptly. This is not a big problem, but if is possible reach speed zero without this effect (also if the camera went slightly over the endpoint, all is better.
Anyway, is better the results with hight max error value than the choppy deceleration, for quality of video.
What are the drag brake and initial brake settings on the ESC itself? Rather high values or low?
Imagine the following situation: CableCam is 5m away from the endpoint and according to the accel settings it has to brake now. In the next cycle it is 4m away and the speed has not been reduced significantly. The brake distance calculation shows it will overshoot the end point by 0.5m. As you see, moving the stick slowly to neutral does not cause the cablecam to brake enough. What signal should I send to the ESC?
A few cycles later, it is exactly at the endpoint but has some excess speed left. It will overshoot the endpoint by 1m. What should I send to the ESC?
What are the drag brake and initial brake settings on the ESC itself? Rather high values or low?
I'm using a VESC6, so I don't set drag brake and initial brake. Now, I tested the cablecam far from end point. If I move the stick at center, the cablecam decelerate very smooth and stop (after I released the stick). But I guess that this is a combination from deceleration and camera inertia, and I can't know how much distance the camera stop from where I released the stick. There is a difference from teorical distance based only on deceleration and true distance. A good results near to end point should be the same, move the stick at center (stop) just in time for stop the camera on the end point. Maybe with a corrector parameter?
About vesc6 I opened a issue about configuration some days ago. Maybe I'm using vesc6 in wrong way. I set it in FOC, How do you set your VESC?
I use high values for brake. Also I can very smooth stop my cablecam manually moving slow the stick to neutral. Also the braking distance from what I can see during my tests not longer than at operational mode. So the main question for me why under the same condition the result is too different?
Also I dont understand how the cable cam can know the speed if the diameter of the halls wheel and the distance between the magnets can be so different from cable cam to cablecam? What is the frequency of calculation the braking distance? One hall step or what?
@DmitriySurin The cablecam don't know the absolute speed in m/s, but at pulse/second. As also distance in measured in pulse and not metres, it's ok
@Willyfan Okay, will document my settings on the VESC next weekend.
@DmitriySurin The statement "I can smoothly stop my cablecam manually moving the stick to neutral" is not a fair comparison. The controller does not let the motor slow down with its settings but by the programmed acceleration value. A fair comparison would be you want to stop the motor faster than with drag brake alone, hence you have to put the stick in neutral once a while. This would obviously not be as smooth as the drag brake alone. I'd like to proof that by you setting a lower acceleration value in the controller. This should then never kick in the emergency brake. What I wonder about is the slow speeds and slow accel I see in your video. I hope it is not something else. Do you have bluetooth working meanwhile? Would be interesting to see the emergency brake output during the drive.
I try lower accell settings and have the same result. Actually I have to spikes during braking. After applaying emergency brake the board immedeatly realease brake to the actual or lower position of stick and let the cablecam moving and then cycles this one more time before reaching end point. The lower accell value the bigger distance between thoose two choppy spikes. But thoose spikes, errors, choppy braking or whatever it calls is still here. I have function called "servo speed" in my radio so I can emulate boards accell values. My bluetooth is working so I send you the log of the braking cycle. What video you mean?
I had some logs about my deceleration. I remember you that I'm using VESC connected in UART. I tried with tolerated error 100 and 300, and in left and right direction. This is the log
Tolerated error 100 - to left
Endpoint brake on. Distance= 866.000, calculated braking distance= 917.956
Endpoint brake on. Distance= 848.000, calculated braking distance= 908.956
Endpoint brake on. Distance= 830.000, calculated braking distance= 899.956
Endpoint brake on. Distance= 811.000, calculated braking distance= 940.453
Emergency brake on
Endpoint brake on. Distance= 789.000, calculated braking distance= 1077.946
Emergency brake on
Endpoint brake on. Distance= 765.000, calculated braking distance= 1163.941
Emergency brake on
Endpoint brake on. Distance= 743.000, calculated braking distance= 1055.946
Emergency brake on
Endpoint brake on. Distance= 721.000, calculated braking distance= 1044.946
Emergency brake on
Endpoint brake on. Distance= 699.000, calculated braking distance= 1033.946
Emergency brake on
Tolerated error 100 - to right
Endpoint brake on. Distance= 866.000, calculated braking distance= 911.739
Endpoint brake on. Distance= 848.000, calculated braking distance= 902.739
Endpoint brake on. Distance= 830.000, calculated braking distance= 893.739
Endpoint brake on. Distance= 811.000, calculated braking distance= 933.891
Emergency brake on
Tolerated error 300 - To left
Endpoint brake on. Distance= 854.000, calculated braking distance= 917.956
Endpoint brake on. Distance= 836.000, calculated braking distance= 908.956
Endpoint brake on. Distance= 817.000, calculated braking distance= 949.953
Emergency brake on
Endpoint brake on. Distance= 794.000, calculated braking distance= 1138.444
Emergency brake on
Endpoint brake on. Distance= 771.000, calculated braking distance= 1126.944
Emergency brake on
Endpoint brake on. Distance= 749.000, calculated braking distance= 1066.946
Emergency brake on
Endpoint brake on. Distance= 727.000, calculated braking distance= 1055.946
Emergency brake on
Endpoint brake on. Distance= 705.000, calculated braking distance= 1044.946
Emergency brake on
Endpoint brake on. Distance= 684.000, calculated braking distance= 986.949
Emergency brake on
Endpoint brake on. Distance= 634.000, calculated braking distance= 697.463
Emergency brake on
tolerated error 300 - to right
Endpoint brake on. Distance= 861.000, calculated braking distance= 864.998
Endpoint brake on. Distance= 843.000, calculated braking distance= 906.880
Endpoint brake on. Distance= 824.000, calculated braking distance= 947.762
Emergency brake on
What I not understand is that the braking distance aftewr a while seem to raise and not lower, and this is impossible because the cablecam slow the speed.
Analyze for example this log:
Endpoint brake on. Distance= 866.000, calculated braking distance= 917.956
Endpoint brake on. Distance= 848.000, calculated braking distance= 908.956
Endpoint brake on. Distance= 830.000, calculated braking distance= 899.956
Endpoint brake on. Distance= 811.000, calculated braking distance= 940.453
Emergency brake on
Endpoint brake on. Distance= 789.000, calculated braking distance= 1077.946
Emergency brake on `
At begin the distance to the endpoint and braking distance decrease, but not how much it need. Anyway, the error is less than 100. Note that distance decrease at double that braking distance, maybe is random? At the fourth cycle, the breaking distance increase suddenly. this is a no sense because to have this result the cablecam must accelerate. but I see that cablecam is in deceleration. At fifth cycle is increased again a lot, and so on for other 4 or five cycles. but at this point the brake stop the camera finally. I don't know what happen, but there is a error in braking distance calculation. I see no other explanation.
I agree. In order to narrow it down, I will add more information.
The distance is calculated in those lines:
float time_to_stop = abs_d(getStick()/controllerstatus.stick_max_accel);
float distance_to_stop = controllerstatus.speed * time_to_stop / 2.0f;
I suspect that the speed is not accurate enough. For example it might switch between the values 5 and 6 and that might be enough to cause that. I have a second way of measuring the speed, that is by measuring the time between two Hall pulses. This way it is not old_pos-current_pos every 0.02s and therefore never a decimal but a natural number.
Ok. I think that to do a complete debug we need for every cycle also: Virtual stick value, or the erpm sent to vesc Real speed. The fact is that the deceleration, when I release the stick at zero is very, very smooth, so I'm sure that we can have the same results at the endpoint. Please let me know, I can try again from next Monday. I have also some other ideas (like hyperlapse function), but I will explain later.
How is calculated the value for stick_max_accel?
Because, we input a value from 0.001 to 1, but in your code you transform it with line
activesettings.stick_max_accel = p[0]*CONTROLLERLOOPTIME_FLOAT;
What value is CONTROLLERLOOPTIME_FLOAT ? I found it in config.h:
#define CONTROLLERLOOPTIME_FLOAT 0.02f
but I don't understand how work ...
Ok, understood. The loop time is 20 ms, so if the input value is 1 (max) the cam decelerate in 1 sec. If the value is 0.5, the cam decelerate in 2 seconds ans so on. Stick can have value from 0 to 1, so you subtract every loop cycle the max_accel value in order to go at 0 in definited time (or, better with a definited ramp, time depends from stick_last_value). I want check if on my setup this is real. I will put max acc at 0.5, pot at max and try to release the stick, to see if the camera stop in 2 seconds, and how much distance. I can measure, roughly my setup is 175 pulse for meters. Just to have some more info.
Some test done. with max speed at around 0.25 and max acc to 0.5, when I release the stick the camera stop in 2 seconds (so, it's correct). In 2 seconds the camera runs 4metres and 20 cm, around 735 pulse in my config (so, I guess that speed read before I move the stick was 14 or 15 pulse in a cycle, not so much) unfortunately in my garden my rope is only 10 meters long, so I can't do better test. I tried also at lower speed (lowered with pot). Camera stop in similar time (maybe a bit less but I'm not sure) but runs less on the rope. In this situations the deceleration is always smooth. Goal is start with deceleration around end point with this value. As I don't know the speed read when I released the stick, I can't do more. Foa a complete debug we need a log with speed, and a more precise time (for this test, I'm moving the stick with a hand and start chronometer on phone with other, not so reliable).
Okay, I made a few changes:
- The more accurate speed measurement using the time between pulses instead of testing in 20ms intervals.
- The end point brake and the emergency brake print out all details now. Note that these print out something only the first time the brake kicks in. If you have multiple lines, that means that in one cycle it did brake because of the endpoint, in another cycle the speed was low enough to not reach the endpoint, another cycle it had to brake again.
- The command $d P enables to print out above position messages in every single cycle. Good for debugging. (A temporary setting only, not effected by $w)
Don't work... I tried at low speed, because with high speed the cam overshoot the end point a lot (some metres) and I have not so much rope in my garden. I tried at 2 different acceleration value, 1 (max) and around 0,5 (pot at mid). The cam seems not decelerate, or not in the same way when I put the stick in mid pos. $d P don't work, or I don't see any different result in debug. This is my log: with acceleration at 1:
Endpoint brake on. Distance= 321.000, calculated braking distance= abs( -0.958[%] ) / 1.000[%/s] * 666.667[steps/s] / 2 = 325.896
Emergency brake on. Distance= 139.000, calculated braking distance= abs( -0.698[%] ) / 1.000[%/s] * 666.667[steps/s] / 2 = 245.896
With acceleration at 0.5:
Endpoint brake on. Distance= 767.000, calculated braking distance= abs( 0.965[%] ) / 0.501[%/s] * 800.000[steps/s] / 2 = 779.358
Endpoint brake on. Distance= 712.000, calculated braking distance= abs( 0.965[%] ) / 0.501[%/s] * 800.000[steps/s] / 2 = 779.358
Endpoint brake on. Distance= 643.000, calculated braking distance= abs( 0.965[%] ) / 0.501[%/s] * 666.667[steps/s] / 2 = 649.465
Emergency brake on. Distance= 617.000, calculated braking distance= abs( 0.955[%] ) / 0.501[%/s] * 800.000[steps/s] / 2 = 779.358
Endpoint brake on. Distance= 535.000, calculated braking distance= abs( 0.925[%] ) / 0.501[%/s] * 666.667[steps/s] / 2 = 629.465
Emergency brake on. Distance= 510.000, calculated braking distance= abs( 0.915[%] ) / 0.501[%/s] * 666.667[steps/s] / 2 = 622.798
In last case, deceleration is choppy. the thing that does not convince me at all is the speed value read: 800 step or 666.667 step in this direction. In the other direction I have also some other values but always inconsistent:
Endpoint brake on. Distance= 324.000, calculated braking distance= abs( 0.955[%] ) / 1.000[%/s] * 666.667[steps/s] / 2 = 325.159
Endpoint overshot. Distance= -1.000, calculated braking distance= abs( 0.455[%] ) / 1.000[%/s] * 363.636[steps/s] / 2 = 82.814
I don't understand what happen, please let me know if I can do other test in order to understand.
$a value is 1, but I done test with pot at max (so is 1) and pot at mid, so is at 0.5 or so (I read 0,501 in debug, I think is correct value). If you like, I can disable pot and put a precise value for $a. Please let me know.
You are right, it was stupid asking. You said the accel is 1.0 at 100% poti, hence I could have known already. I would love to test that with lower speeds. Assuming the top speed is 50'000erpm for the VESC, a value of 1 would mean it stops from 50'000 to 0 in 1 second. That is significant. If your actual speed is just 5'000rpm and you drive against the end point it would stop in 1/10th of a second. That is a deceleration way more than physically possible. Hence I would like to set the baseline to something smaller. In my case I have $a 0.5 0.5 which is quite a lot as well and then the poti is at 50%. That gives an effective acceleration of 4 seconds from 0 to max erpm. More reasonable.
How about the following: You limit the max erpm in the controller, say $e 5000. Hence the UART output will be a speed command of 5000rpm at the most. Something you feel comfortable as top speed given the line of the rope. And then way play with smaller accelerations.
I agree with you that above readings are not what I want to see either. What I don't know is if they are a side effect or the root cause. If you want to stop 10kg of mass from 60km/h to 0 within one second, yes the deceleration will not look nice. Simply because you trip the failsafes constantly. Even if you drive just with 6km/h it will not look nice because you essentially stop within one controller cycle. Hence not much difference in output when printing the debug values in every control cycle or not.
Knot some towels at the ends of your rope so even if you drive over the end point, there is a cushion of some kind stopping the cablecam?
Tomorrow morning I will try with max ERPM at 5000 (actually is at 35000) but:
- My test was at not higher speed, but with pot at less than half. I don't know the exact value because the curve for this pot is not linear but expo (programmed in the radio). If I try with high speed the cam go some metres over endpoint, As I told before.
- If I release the stick in the mid of rope, the cam stop in 2 seconds (as expeted) with acceleration at around 0,5, without problem and very smoothly. Obviusly, it go more metres as the speed is higher. So, I think that the problem is not the inertia of the camera, it CAN stop at the speed I try.
- in my garden I have a 14 metres rope, not more. So, I'm unable to go at very high speed because the cam have not time for accelerate. Anyway, the goal is have the same stop at end points as when I release the stick.
- Today, at same speed that I test the end point, in the mid of rope when I release the stick the cam stop in 2 second and in around 2 metres or little more. As my cabelcam have around 175 pulse/metres, I expected the braking distance to be around 350 or 400 pulses, but it seems to be much more from debug info (800 pulse). Probably there is still a problem of calculating the speed. Tomorrow I try also to take a video, so you can see the speed of the camera.
The 400 pulses expected vs the 800 pulses calculated I can explain, I believe. I have configured the encoder so that one pulse is a rising and falling flank in either of the two Hall sensors. So when one magnets does pass, it is 4 steps, not two. (Encoder Mode X4)
Regarding the 2 seconds with a=0.5: Keep in mind, it should be two seconds from full speed (stick=100%), not from the current speed/stick.
Yes, I know, but my evaluation take account of this. I have 175 pulse / meters read from the board. A magnet pass every around 12mm, so if I count the magnets pass they are half then the 175 value. I will do some other test with low speed in the morning. I let you know asap. Also stick, I use stick at 100%, I reduced max speed with pot. When you say "full speed" you mean absolute max speed (for example 50000 erpm) or only stick at maximum?