GOTO features

[Willyfan]

Dear Werner, This is not a issue but a request. I finished to write a windows app, for cablecam setting, just as my android app. But from PC I'm able to use also long range TX RX for serial, like this one: https://www.amazon.it/gp/product/B0722KH7HZ/ref=oh_aui_detailpage_o03_s00?ie=UTF8&psc=1

So, I want write a more complex app for the cablecam, something like a mission planner. To do this, I need only a simple faeture implemented in the cablecam formware. A GOTO command. With this command, I want send to cablecam the command like "goto XXXX" where xxxx is a point inside my end limits. When i send command, cablecam must start (with programmed acceleration and speed), go to requested point and decelerate and stop in this point, just as a end point. In this way I can program from my app all, and send command as request for move the cablecam from many programmed points. For programming all y points, there is a command to read the actual position, so I don't need nothing more. What do you think about? Can you do it?

[wernerdaehn]

So it starts and ends with speed = 0? Okay, will do that. $p reports the start/end and the actual position.

[Willyfan]

Ok, thank you. Just I finish my application I will share.

[Willyfan]

any news?

[wernerdaehn]

Still considering how to do that best. Should the code stay as is and it is more like a virtual movement of the end points + play? Simple but limited. Play runs in both directions etc. Another option would be to add a new logic, which would have the advantage the goto command can have individual speed ramps, e.g. goto position 5000 with maxaccel=0.01 and maxspeed=20.

Or don't do anything and use the ODrive Robotics controller, which has that built in already?

[Willyfan]

What is Odrive Robotisc controller? Anyway, is not important have individual speed and acceleration ramp. As I can send command to the cablecam, I can set also speed and acceleration every time I send a "goto". So, what i need is simply a command to go to a point with acceleration and speed in setup.

[Willyfan]

Hi Werner, I seen what you mean. So, you are designing a cablecam for another controller, very good. Have you more info about this controller for cablecam? I read that you implemented the ODrive ASCII protocol. beside, you don't need anymore of the position encoder?

[Willyfan]

I thought about it a little bit. In my opinion, an implementation that would also work with VESC or normal ESC would be appropriate. Regarding the use with Odrive Robotics, I read around and I will certainly try it. I also read that you are adapting your firmware to control that controller, and there obviously the goto is much simpler since it already exists. Just one thing I would like to ask you: I saw the cablecam direct drive to be used with that controller. Mine is already now direct drive and so it is very similar, but the question is, having the sensor on the motor, if it slips what happens?

[Willyfan]

I'm also redesign my cablecam in order to use Odrive Robotic controller. Only difference, for now I want use a different encoder, as I have designed a board for AMS - AS5047P (and I don't need for this a dual shaft motor). But actually the odrive boards are in backorder, So I must wait for test... Please let me know when version of CC3D controller with protocol for Odrive is ready, i wish test it.

[Willyfan]

Hi Werner, are you still alive? ;)

[wernerdaehn]

Yes. Was skiing a lot recently. Yesterday I started to add the odrive control code. Still at the early stages but at least some progress.

Things I keep thinking about:

• How much slippage is when using the odrive position control alone compared to the running wheel? Depending on the answer the implementation would be simpler or more complex.
• Need a way to send either position commands to the odrive via the app or the speed commands via the RC. Both at the same time would be contradicting information.
• Should I even use the odrive position or rather implement that in the controller? Depends a lot on the slippage question.
• When using the app to play previously recorded movements, every disconnect will cause an issue. I think I prefer uploading the "mission planner data" to the EEPROM of the controller and use the play button on the RC (or the app) to start/stop it. That will be a hell of work to implement.
• I'd like the mission planner to be very flexible, so target points, max speed and max acceleration can be set per step.
• Implement it in a way so other movements are possible as well, e.g. changing speed while moving.
• Does that mean I have to add a target position again, one that is moved according to the RC or the mission and the cablecam controller has to move to that point as quickly as possible? I think so.

[Willyfan]

About the 4th point: With the app I want use radio telemetry and not bluetooth. Disconnection is possible, but I must only send a command goto. I understand your idea about mission planner loaded on the eeprom, is used on drones but with cablecam maybe we must decide the target point during work. I explain: for example I wnat take a concert. I set some point (near stage, over people, far to the stage for a large take etc.). During the concert I need to go in one point but I don't know before the sequence. How you can use a only switch on the RC to transmit a "goto point x" command if i don't know x before? beside, I understand also that the implementation of "mission planner data" to the EEPROM is very, very complex. About point 5: If I can send command every time to tha cablecam, I can set everytime the speed and acceleration before send goto command. So, If I have a goto command to send to the cablecam, it is already very flexible. And I can add point during work, difficoult to do with a mission planner loaded.

[Willyfan]

Hi werner, ar you ok?