[treemark]

I am building a quad with 4 Graupner '3d' reversible speed controllers (link below). These are matched to the motors that ship with the Graupner 300 alpha. Does libre pilot support these stunt '3d' speed controllers?

https://www.graupnerusa.com/ULTRA-CONTROL-20A-3D-ESC-OneShot.html

[TheOtherCliff]

Yes and no.  LP supports reversable ESCs, but I suspect this has mainly been tested on cars.

There may be some people here that have done this.  I haven't.

Arming usually requires throttle stick at the bottom, which is full reverse power for this setup.  Making sure that all works safely and correctly would be at the top of the list.  I would guess that you want to set up arming on a switch.

[karla]

I am building a quad with 4 Graupner '3d' reversible speed controllers (link below). These are matched to the motors that ship with the Graupner 300 alpha. Does libre pilot support these stunt '3d' speed controllers?

Cool. Are you attempting fly inverted with a quad?
Why not?
Mystery why no one tried that before.

[treemark]

My principal reason for this is that I happen to have 4 of these graupner 300 alpha quads that I want to outfit with a FC that supports full flight operations via telemetry. This is so I can fly with a companion computer that will handle higher level flight functions, while delegating the whole keep it in the air thing to the FC. Here's a link to some old demo video of the project's GCS. Right now, I have an orange pi zero onboard and I've worked out all the UAVTalk protocol I need. But I only just started working with Libre Pilot and ran into this issue with it's reversible escs.


(Turn on Closed captioning for text commentary) (Cliff changed youtu.be to youtube.com so it would display in forum)

I've evaluated clean/beta flight and found MSP to be lacking, (it can't replace a transmitter). Then I moved on to arducoptor, which would probably work but I found MavLink to be a mess of poorly defined messages that vary substantially between copter/plane and GCS implementations. Then I found LibrePilot and UAVTalk, which seems much cleaner and organized, so here I am. I am principally a java developer and am weak in the C world, so any help you can offer is greatly appreciated.

Mark
(Having a hard time getting the forum to display my youtube link, cut and paste youtu.be/cCmRFS-1aY4 to see the demo)

[treemark]

Attached is a screen shot of my output configuration.. all the motors spin as expected when you adjust the sliders with live testing on. Still can't get the quad to arm via GCS joystick control. I've followed all the instructions given here..

https://librepilot.atlassian.net/wiki/spaces/LPDOC/pages/14221378/Control+vehicle+using+joystick

[TheOtherCliff]

Hey Cliff, I am waiting for a ESC reprograming cable to arrive for my graupner reversible speed controllers, but it will be several weeks. In the meantime, I was hoping you could point me in the right direction on dealing with them as they are. If I knew the name of the C file for example that governed the output channels, I could adjust them there. If you don't know, Is there anyone familiar with the code you could put me in contact with?

Mark

There are many ESC signal protocols and several have been implemented in LP.

You need to know what ESC protocol(s) your ESCs can support and then we can compare it to what protocols are available in LP.

I would guess that a fast PWM protocol is the most likely to be compatible and it is fast.  It is fast enough to be hard to impossible for a human to tell the difference between that and infinitely fast.

Human response time is on the order of 100's of milliseconds.  Fast PWM is 2ms.  Anyone saying they can feel the difference of JUST THE ESC SPEED is saying they can tell the difference between 300ms and 302ms.  RC control lag alone is 10's of milliseconds.  FPV picture lag is about 33ms best case.

16.09 supports OneShot* MultiShot

Next adds DShot.

I'm working on two goals. The first is to simply fly with these graupner stunt '3d' reversible escs and the Second is to fly entirely off of telemetry with no receiver.

I've made some progress on both. I can take this back to my original forum post.

Reversable ESCs can be used as normal ESCs.  For instance, a normal ESC running PWM uses about 1000 to 2000 (or maybe 1930) for min to max with neutral about 1070.  A reversible ESC running the same protocol would use the same range, but 1070 would be full reverse, 1930 would be full forward, and 1500 would be off.  All you would have to do to use this as if it were a normal ESC would be to set min=1500 (whatever is completely off) neutral=1550 or so (whatever is a slow steady spin), and 1930=max.

Using the telemetry link for control too is trivial on the aircraft side.  On the ground you will have to build some cables and do some research to put an OpLink into a transmitter, or to make a relay box.  A relay box does add some control lag because it uses a normal receiver that sends PPM to an OpLink which sends the control to the FC.  There is basically two times the normal control delay, one for the RC link and the other for the OpLink link.

[treemark]

Yes, since my original post, I've made good progress working with a traditional transmitter and receiver via s.bus and one shot for the ESCs. I think I'm out of the woods on that account. Now I have to workout the rest of my implementation of UAVTalk protocol. Do you know of anyone active in the forum with experience controlling an aircraft solely via the telemetry link on the flex port?

[TheOtherCliff]

There are many people who have put an OpLink into a regular transmitter, fed the OpLink with the PPM buddy box signal, powered the OpLink with a 5V BEC, added an antenna and done.

You can feed an OpLink the same PPM signal from an RC receiver and just make a relay box that receives from an unmodified RC transmitter and sends to the FC telemetry link.  You can use a joystick connected to the GCS and the OpLink connected to the GCS.  None of this requires coding.

Everyone that I know of that sends control directly to a Revo class FC via the 433 link, sends PPM to an OpLink.  You could also send UAV packets to the OpLink like the GCS / joystick does.

If not using an OpLink, you should at least use an RFM22B/RFM23BP to get the link level protocol correct, so why not just use an OpLink?

At the very far end of the spectrum of dev, you could use a different RF section and even have to write the code to handle the RFM link protocol.  That would be very time consuming and just not worth it in my opinion.

[treemark]

I want to control the cc3d via an onboard companion computer. If I complete my implementation of UAVTalk, shouldn't I be able to handle all flight operations as if the companion PC was a GCS via UAVObjects serialized over the flex port? or am I barking up the wrong tree? Ultimately, I don't want any radio link to the cc3d, the companion PC has it's own ground link.

[TheOtherCliff]

Ah.  Yes using UavTalk sounds like the way to go because you can do many things with it.  A simpler way might be to send PWM/PPM/Sbus/etc commands to the CC3D as if it were an RC receiver sending them.

[treemark]

Great! thank you. Last question, to reverse engineer some of the conversations the GCS has with the FC, I have had some success setting the GCS to use the UDP connection option, I then receive those packets in java, deserialize, re-serialize and forward them onto the FC. Doing the same for return messages as a proxy/man in the middle. Do you know of any reason this approach wouldn't work for all communication between the GCS and FC?

[TheOtherCliff]

If it were me and didn't cost me a lot of extra time, I would want the capability of doing UAVtalk without requiring a GCS in the mix.  That might allow you to make things more useful (not needing a GCS).  The LP flight and GCS code is difficult to wade into with the only reason being to make a UAVtalk implementation.  There are projects out there that have already done this and that is where I would start.  Of course they would need to be updated for the latest UAV id numbers and structures:
- wiki such as https://librepilot.atlassian.net/wiki/spaces/LPDOC/pages/8552471/UAVTalk#UAVTalk-Example%E2%80%93Logrecordingandreplay
- various language code examples in the source
- MinOpOsd
- MwOsd (for MinimOsd)
- LP2Go
- posts here in the forum
- Google: uavtalk examples (shows a lot of useful info)

I might even be tempted to start with the OpLink code and morph it into whatever I wanted.

[treemark]

Well, that's basically where I am. I used uavobjgenerator to create java code for all the UAVObject messages. The java classes these generated files reference are missing from the repo, but I found some old versions of them in a forked repo and after some effort got them working again (link to that thread below). I did look into Lib2go (it's to woven into android) and others, but ended up settling on uavobjgenerator -java.

My question about the GCS is purely for development purposes, simply having all the objects and serialization logic complete still doesn't tell you exactly what to send and expect in response to a message. Being able to eavesdrop on the conversation has helped me to understand the protocol. I don't intend to use the GCS at all in the end.

I'm worried about using the GCS in UDP mode is because I see that it is primarily intended for log replay and simulation. So I'm concerned that it won't support all operations available over a serial connection. Any idea about that?

https://forum.librepilot.org/index.php?topic=4561.msg30974#msg30974

[TheOtherCliff]

You are at or beyond what I have done with UAVtalk.  Hopefully someone else can help here.

My first guess is that UDP would handle all messages, but I can understand if some of the categories (e.g. acked, multiple instance) are not implemented.