Writing Endpoints into the EEPROM right after are set

[zond-media]

Add an opportunity writing Endpoints into the EEPROM right after are set

[Willyfan]

Is a good Idea, in the firmware on the old card I modified for save in eeprom also the points just after setting.

[wernerdaehn]

I'd like to discuss the procedure to make sure we have a common understanding:

1. Enter programming mode, set both endpoints, exit programming mode. Now I write the end positions into EEPROM.
2. You use the cablecam for a couple of hours and then swap the batteries.
3. The point where you reconnect the batteries has to be the exact same point where you did that when starting the cablecam the first time, because that is where pos=0 is.

Correct so far?

Question: Should I execute a $w command and write all settings or move the end position variables to a separate EEPROM page and store just the position?

With $w you write the current speed and accel limiter, if changed via the RC, as the new limiters. You would save potentially temporary settings as fixed now, e.g. in case you played with $i. I believe I would need to store the position separately. And above pos=0 worries me for a) safety reasons - what if somebody does not know or remember and repowers the cablecam anywhere? - and b) practically - how do you know where you started the cablecam the last time?

[Willyfan]

The 3 points are correct. I remember this problem also with old board, and I modified the firmware in order to save position. Now is less necessary because you can save it with $w write in eeprom, but I used this feature many times before. Sometimes, non only for swap batteries, that it live many hours. But I worked on a 3 days event, so at morning was very simple turn on cablecam in the same point and have all setting done. I understand your worries about safety, but normally, in the real use, the cablecam is mounted on cable and turn on at one side, where you have easy access. So is not a problem remember it (and normally if 0 position change of 20 cm is not a problem). If someone not remember the point he must reset the endpoints, but I think that this is not a normal case. No difference if you save all settings or move in a separate position, but in my modify of your old firmware I save in separate position. I think that other settings as acceleration don't need to be saved, because we have the control on RC, or by the app. The app, when you change some settings ask for save in eeprom when you close it if someone changed. For logical, I think that the better solution is take positions and setting separate.

[zond-media]

Totally agree with you, @Willyfan Additionally, I suggest adding the $P parameter. If it = 0 (default), the recording does not occur, if = 1 auto-record is enabled. Or, alternatively, add a button (maybe we can use Boot?) to store and load position.

1. Enter programming mode, set both endpoints, exit programming mode. Now I write the end positions into EEPROM.
2. You use the cablecam for a couple of hours and then swap the batteries.
3. The point where you reconnect the batteries has to be the exact same point where you did that when starting the cablecam the first time, because that is where pos=0 is.

everything is correct, only my suggestion - add $P

I am for "move the end position variables to a separate EEPROM page and store just the position"

[wernerdaehn]

+1 But I don't understand the $P statement. You want it to "Play" automatically? That's the opposite of what I aim for - Play only when you can be sure all is setup and the user can exit at any time. Example: Lost connection with the RC for >2 seconds? Stop Play immediately.

[zond-media]

Sorry, I forgot that $P it's for Play.. The letter is not important, let it be $z ;)

[wernerdaehn]

You mean a separate command in parallel to $w for writing just the positions?

[zond-media]

No, I mean, it's a key to enable (=1) or disable (=0, default) write the end positions after exit programming mode.

[wernerdaehn]

I can't find a reason why you would NOT want to store the end points. In my world last setting counts, hence saving the endpoints to eeprom always now. Agree?

I have implemented it, currently testing it.

[wernerdaehn]

Firmware uploaded.

[zond-media]

I can't find a reason why you would NOT want to store the end points

excellent, I agree, it will be good I will test tomorrow and write the result here

[Willyfan]

For who need a point zero different from actual access to cablecam, I suggest a command for reset to 0 only actual position. So, I can go in this point using pass trough mode and reset position. Another useful command is a offset of end points. I added this in last firmware because sometimes when the pulley slip the actual position is not accurate and We need to offset to left or to right both end points during work.

[zond-media]

Today I tested the new firmware. Excellent work, thank you @wernerdaehn ! There was a problem with braking at high speeds. Can you add a parameter to adjust the brake stages? At high speeds, I need to brake much earlier than at slow speed. It would be great to have such possibility of adjustment. p.s. command $A still doesn't work..

[wernerdaehn]

Can you show me what high speed braking looks like in your case? You are using a RC car ESC, not the VESC, are you? I recall that from the last video but want to make sure.

In theory the controller calculates the brake distance at any time and if there is the danger to overshoot the endpoint, it reduces the stick signal in a linear fashion. With the VESC the stick translates directly to a speed and hence the speed is reduced nicely. With a car ESC you cannot control the speed, only the energy level plus the amount of slow down is programmed as drag brake into the ESC. What might happen now is that the drag brake is not enough at high speeds, the brake distance calculation figures it will stop beyond the end point plus the max error distance ($g) and hence go into an emergency brake, meaning setting the output signal to neutral. If this brake is way more powerful then the drag brake when reducing the stick signal, the speed might drop so the end point is no longer overshot significantly and continue with the normal braking. Result is an uneven braking. You can test that theory by setting $g to something significantly higher. Just keep in mind that the end point might now be overshot by a greater degree and allow for that when setting the end points. Sooner or later I would recommend using the VESC.

[zond-media]

Yes, I’m using car ESC but in Play mode I can change the speed. I assigned the maximum speed to the knob and for 3-4 meters to the end point I reduce to a minimum. It’s work! Is it possible to do this automatically?

[wernerdaehn]

As said, you don't have to reduce the speed by hand.

The controller knows the speed of the cablecam. The controller has a maximum acceleration defined. Hence it can calculate the brake distance and if that is so high it is over the endpoint, the speed signal is reduced linear. Example in metric units: Speed = 10m/s Accel = 1m/s² Hence it does reduce the stick from the current position (say 50%) to zero in 10 seconds (=speed/accel). It would reduce the stick signal by 5% per second.

If the stick is 10% and the speed = 1m/s, it would reduce the stick by 10% per second.

Give it a try. Set the acceleration to a very low value. You will see it does start breaking really early and the faster you go the earlier it brakes. Just as above example with 10m/s and 1m/s has shown.

[zond-media]

I understand, thanks for the detailed explanation of the algorithm of work and for your time! perhaps you can close this issue ;)

[Willyfan]

I have a question for Werner related to the algorhitm above: As you say (and I'm agree) with normal (car) ESC you can't control the speed by input but only energy. But as you know the real speed of the cablecam (from cablecam sensor input) what is the difference from this ESC and VESC? I mean, the controller can manage energy in order to have desidered speed. Or not? I understand that VESC is better when you need to take braked the cablecam on a slope cable, But car ESC have a lot more power, also 120-150 A vs 80A max for VESC. Perfect ESC will be a VESC with more power.....

[wernerdaehn]

My initial goal was to use a PID control loop in the cablecam controller that sets the power according to the sensor wheel. I mean, everything is there. Sensor wheel says the speed is too low, hence the PID controller does increase the power signal for the ESC and vice versa. Generally speaking that worked okay. But not good enough.

• Problem 1: While you can increase the ESC signal to go faster, decreasing the signal does not engage a proportional brake. The ESC did either slow down the motor based on the drag brake value or the full brake if the speed signal is neutral. You cannot control the brake to the same level you can control speeding up.
• Problem 2: The resolution was not high enough. At neutral you expect the cablecam to stand still. In reality it did move around the target point.
• Problem 3: Low speed movements near neutral. One thing you have to do is eliminating the neutral area of the ESC. So if the ESC has 1500us+-30, the controller should not output 1520, the value should jump directly to 1530 or 1470. No problem if setup correctly. But even a signal of 1550 would not mean necessarily a motor movement. It would power the motor a bit, you can hear it, but the power is not enough to actually turn the motor. Such non-linear behavior does not work well with a PID controller.
• Problem 4: The PID values change constantly. Different camera, different hill steepness, tension of the rope.... you had to spend a lot of time to tune in the parameters and the next time different ones were needed.
• Problem 5: For proper resolution at low speeds you had to program a throttle curve. Only then you can control the low speeds and reach the top speed. Again, a non-linearity the PID logic cannot cope well with. Worse, all ESC I tried did use the throttle curve on the forward side only. In reverse the throttle was linear.

So at the end it did work at slow to high speeds. But did not work for very slow speeds and standstill. Two videos that show that it did work in general. But because I was never satisfied I removed that code when the VESC turned out to be so much better and none of the RC vendors were willing to implement a speed mode in their ESC. https://www.youtube.com/watch?v=yxlcmSTsAeA https://www.youtube.com/watch?v=SgqjXSWjWp0

[wernerdaehn]

@zond-media Regarding $A: I removed that command, it is now $j a 14 This would map the aux output to whatever input channel #14 provides. See $i to validate the input and the servo1&2 outputs.

Just validated that there is an output signal.

[zond-media]

Ok, thanks!

[wernerdaehn]

implemented