wernerdaehn / CC3D-CableCam-Controller

CC3D and STM Cube based CableCam controller
Apache License 2.0
37 stars 15 forks source link

Automatic Mode #16

Closed zond-media closed 6 years ago

zond-media commented 6 years ago

add a new mode: automatic cablecam movement at a given speed (by the Pot via RC or(and) variable in settings) back and forth without moving the stick with the start and end position (set before). This mode is needed for working alone, so that there is a possibility of controlling the gimbal with another RC.

zond-media commented 6 years ago

is there any news on this proposal?

wernerdaehn commented 6 years ago

Considering it heavily. Problem 1: While forth mode would make the most sense, the RC sender has 3 position switches only. Hence best would be to request the limiter+endpoint mode and then use another switch to turn automatic travelling on/off. Problem 2: When to turn off the automatic mode? Obviously when the switch is flipped, also when there is no more signal. Any other failsafes? Problem 3: This will not be the only request. You could also record a movement and ask to repeat it over and over again. Or execute specific Point of Interest movements later. How to implement that so it suits future enhancements? More switches?? Certainly not. Problem 4: Should we really start with this mode? How about starting with a record/playback mode for automatic movements?

What would be your take?

zond-media commented 6 years ago

I think you greatly exaggerate the problem at this stage. I agree with you, the best would be to request the limiter+endpoint mode and then use another switch to turn automatic travelling on/off (possibly Endpoint Button), but this mode must start with delay ~3-5sec and stop when the switch Endpoint Button is flipped OR when there is no more signal. This is quite enough for RC ! To extend the functionality it is better to use the application for Android or iOS, but this is a completely different story..

wernerdaehn commented 6 years ago

Okay, I can live with that.

Willyfan commented 6 years ago

If you want, I can add these features in my android app. I need only to have a additional command set in order to set the automatic mode and start it. For zond-media: you can download the app here: http://william-fanelli.com/wp-content/uploads/myupload/ID_CablecamSetup_5.apk Obviusly, no automatic mode is implemented for now... But I have a lot of ideas for the app. The problem is the bluetooth range, only some metres. not so much.

wernerdaehn commented 6 years ago

I just found this BT module with 100m range SparkFun Bluetooth Mate Gold

Trouble with turning on the automatic movement via the app is, how do you turn it off when the cablecam is out of range? Or in case of emergencies? I would need add a timeout - if the app was not in range for longer than n seconds, stop immediately. I think I will do that.

zond-media commented 6 years ago

Look at this lovely set, about 2 km range: XRock 915MHz and Internal shots

wernerdaehn commented 6 years ago

I have used XBees in the past as well, equally nice as UART replacement. But they all need something attached to the tablet/phone, and that is the point I don't like. BLE 5.0 might be the answer long term. Or Wifi?

zond-media commented 6 years ago

What doesn't suit you in this module? If I understand correctly, there is a Bluetooth bridge from Tablet(phone) and Ground Station

wernerdaehn commented 6 years ago

I have tried it manually but not on the rope yet. So be very careful. There is one area of concern, that is that the cablecam never reaches the endpoint but stops right before it. This would break the automatic reverse.

Command: $j p 13 This is a new command and can be used to set all channel assignments one by one. Hence an alternative for $i. But while $i only supports the important commands, $j does all. In above example I want to set the p...Play function to channel 13 of the RC where a two position switch is assigned to.

In order for the Play button to be used, many conditions need to apply:

Note: It is absolutely fine to change the max speed/max accel while it runs by itself.

The implementation is to set the stick(!) to max_speed. If the endpoint is reached, wait for 5 seconds, then set the stick to -max_speed. As I change the stick values, it looks and feels to the controller as if you make those movements on the RC and hence the acceleration limiter, autobrake before the end points,... all is done.

cofhal commented 6 years ago

How does the play option work?

wernerdaehn commented 6 years ago

Isn't the post above clear enough? You assign a switch to a channel in the RC and tell the controller about that channel via $j p <channel#> Then by flipping that switch, the cablecam starts to move automatically between the endpoints, assuming those had been set and you are in the correct operation modes.

Willyfan commented 6 years ago

If I understood right: you can start automatic mode from RC with a new switch, or from the App with command $P 1 (this last way is to so clear...) but from the app I need to send the command every second or so or the cablecam stop. We can control speed in automatic mode with pots, or setting by the app, anyway automatic go to the max speed allowed. When the cablecam reach the end point stay in stop for 5 seconds. I'm right?

wernerdaehn commented 6 years ago

100% correct.

Willyfan commented 6 years ago

There is a reason for not to add the automatic switch in tail to $i command? For my app this is the best (use $i instedad that $j), but if it is a problem I will review the layout, but is not easy to have backward compatibility.

wernerdaehn commented 6 years ago

Usability mostly. Imagine you have a RC with 4 channels only and the ch#4 should be used for the last parameter in $i. You would need to type a lot of 256 numbers. But actually, these people can use the $j command, nothing wrong with adding it to the $i command in addition. Will do.

wernerdaehn commented 6 years ago

Done. $i now accepts one more parameter.

Willyfan commented 6 years ago

Perfect. I'm really busy in this days, but I will try to find d some times for adding this changes to my app. Have you a suggest in order to know the fw version?

cofhal commented 6 years ago

The automatic mode works fine, with PWM, but with the VESC with the Serial port it does not work.

zond-media commented 6 years ago

wernerdaehn, thank you so much for this work! unfortunately I'm now busy until about the end of April.. I can carefully check only at the beginning of May and will write the result here. keep it up!

wernerdaehn commented 6 years ago

@Willyfan $V prints out the version string. Version string is a date in format YYYYMMDD.

Willyfan commented 6 years ago

Ok, I'll modify the app asap.

Willyfan commented 6 years ago

I modified the app. It is a new version, for now this app don't work with old firmware. www.william-fanelli.com/wp-content/uploads/myupload/ID_CablecamSetup_7.apk

cofhal commented 6 years ago

The automatic mode works fine, with PWM, but with the VESC with the Serial port it does not work.

wernerdaehn commented 6 years ago

Can you check again or elaborate. Today I tested it, no firmware update, and the Play function did work with the VESC. Frankly I would be surprised if it does work with PPM and not the VESC as the entire Play function creates a speed signal in percent and then this percent value is converted by the PPM output and the VESC output into the corresponding output value for each. I cannot see a reason why the PPM should work but the VESC not. Unless the VESC does never work of course.

zond-media commented 6 years ago

Hi, wernerdaehn! hurray, there was a time and I checked out Play function. unfortunately, it did not work ... I set the Start and the End points, I checked in manual mode with a stick - fulfills as expected, beyond the boundaries of points does not come out. I switch to Play - nothing, stands still without moving ... I try using a stick to go a little forward and the cart automatically goes to the End of the point and stops (the blue LED flickers at a frequency of 0.5 hertz). With the help of hands I pull back a distance, but the cart again returns back to the point and stops ... what am I doing wrong?

wernerdaehn commented 6 years ago

Okay, so I will add debugging information.

Couple of questions: $r shows +1 or -1? start/end points are significantly apart, e.g. > 2 meter? checked with the $i command that flipping the play button does change the channel value to (near) max? (max is the value full throttle represents)

These are the relevant code lines in https://github.com/wernerdaehn/CC3D-CableCam-Controller/blob/master/src/controller.c

        if (controllerstatus.safemode == OPERATIONAL &&
            controllerstatus.play_running != 0 &&
            activesettings.mode == MODE_LIMITER_ENDPOINTS &&
            value == 0.0f &&
            activesettings.pos_start != -POS_END_NOT_SET &&
            activesettings.pos_end != POS_END_NOT_SET)
        {
            if (HAL_GetTick() - controllerstatus.play_time_lastsignal < 2000L)
            {
                if (controllerstatus.play_direction == -activesettings.esc_direction)
zond-media commented 6 years ago

$r shows +1 or -1? -1

start/end points are significantly apart, e.g. > 2 meter? yes, > 2 meters

checked with the $i

I can not check it without bluetooth-module... but, when I turn on Play-mode, the cart moves to one point and stops there forever. if the cart moves, the throttle-level changes, it's logical, right? and I can even adjust the speed...

wernerdaehn commented 6 years ago

Hmm. When it moves towards the one point and stops there, can you push it by hand a bit more over the end point?

The implemented idea is that the play button moves the stick for you. Say it is in the middle between start/end point. Play is engaged. The play function puts the stick at +100% and because of the speed ramp and end point it accelerates towards the end point and stops there, although the stick is at +100% still. The actual stopping position can be before the precise end point, up to 100 steps earlier. If it is within that range, the play function waits for 5 seconds and then puts the stick into -100%.

Hence the only explanation short of an error in the code is when it stops significantly before the endpoint and not within that 100 steps area. If you push it manually over the end point, we would know if that part is the problem or not.

PS: I did not understand that in your case the play moves it to one direction and then stops. I read it as "nothing happens at all".

PPS: Bluetooth module would be nice. I switched to the Sparkfun Mate Gold.

zond-media commented 6 years ago

When I push it by hand a bit more over the end point nothing happens at all... I recorded a short video, so it will be easier to understand. I show the work in Limit mode. Then I define the points. I switch to Limit mode with endpoints. I check in manual mode, everything is ok. I put the cart in the middle of the road and turn on the play mode. The cart moves to a point and stops. With my hands I move the cart through the end point. Then the other way. The cart returns to the point. The same thing happens with the help of the stick. https://drive.google.com/open?id=1DSH0z6M5C4GuSWLpG9uP8EMHyu5dFhZq

wernerdaehn commented 6 years ago

Got your point. It moves to one endpoint but never does reverse. I'd like to check the $r again. If you put the stick forward und read the position with $p, does the position value increase or decrease? $r -1 means it does decrease.

You don't have to do that on the rope, you can simulate it by turning the sensor wheel manually. Just make sure you got the direction correctly. Check in what direction the drive wheel turns and then turn the sensor wheel in the (opposite) direction, as if it would be on the rope.

zond-media commented 6 years ago

wernerdaehn, I did not read parameter $p, I immediately tried to change the reverse on the motor (esc - "Reverse", it was "Normal") and in the controller ($r = 1, it was "-1"), hung the cart on a rope and... a miracle happened - it worked! ))

wernerdaehn commented 6 years ago

Glad we looked into the proper direction. I don't like the $r parameter either, tried in fact multiple things to live without but ended up with it being necessary. Its function is clear, I assume. Somehow you drove over the end point. a stick movement further over the end point has to be prevented, reversing out of the overshot end point should be allowed. $r tells me what stick direction causes what drive direction. I experimented with setting that automatically and actually it does, but there are limitations. For example I might push the stick forward a bit and the result is rolling downhill slowly. Only if the stick is moved a lot forward it drives uphill. At the end it was too dangerous for me.

zond-media commented 6 years ago

well, we solved this problem. now, it would be great to store these points in memory so that when replacing the batteries, they do not have to re-define them. p.s. not all commands are written in the Command Reference table, please correct ;) p.p.s. $A didn’t work

Willyfan commented 6 years ago

Dear all, I have a lot of work to do in these days but I will upgrade the app as soon as possible with command for auto mode. Please let me know if someone tested it (the app), Anyway the last version is working ok for settings, on my cablecam. A question for Werner: I see a update of firmware, what changes? What mean "Endpoint handling improved"? Thanks!

wernerdaehn commented 6 years ago

Just the way it looks and feels, when the CableCam does stop. The brake distance was calculated and if the end point is in danger to be overshot, it does slow down. And if it really does overshoot, stop immediately. As result it does slow down nicely and in the last centimeters the inertia drags it over the endpoint and therefore stops abruptly. Now I have a range of 100 steps. The brake target point is 100 steps (20cm) before the end point and the motor has 20cm to stop smoothly. Only if that is not enough, it would overshoot the end point and stop asap.

zond-media commented 6 years ago

wernerdaehn! can you make it possible to save points in memory right after the endpoints are set?

Willyfan commented 6 years ago

@zond-media: the points is saved in memory just now...

zond-media commented 6 years ago

Are you sure? I have zero points when turning on the power They are only saved with the $w command, but this is not always convenient those, they are of course stored in memory, but only in RAM is not in the ROM

Willyfan commented 6 years ago

I will try again, but I remember that end point are saved. I don't know if something changed in the last firmware, I don't tried yet.

Willyfan commented 6 years ago

...anyway, is very easy save it with my android app...

zond-media commented 6 years ago

Oh sure! but I would like to have such an opportunity with a minimum set of equipment. Thank you for the app!

wernerdaehn commented 6 years ago

It is risky. Writing into the EEPROM takes a few seconds and does block the entire MCU at the moment. I am not sure if that is just the implementation I have used, the library I have used or just for simplicity. But lets assume I can solve that, I would need to save that to a different address. So more changes. Please create a new issue for that and I will look into it.

zond-media commented 6 years ago

ok, thanks!

wernerdaehn commented 6 years ago

Lengthy conversation alread. I am closing this one. Feel free to create new issues in case I forgot an aspect.