[gon]

Hi,

As a college project, I want to develop a hardware-abstract programming language for drones: A simple programming language in which you have as basic operations "to move to pos", "to roll", "to land", etc. With it, you could write programs that can be executed in any drone model independently of the hardware and firmware if there's an implementation for it.

The language it's mostly finished. I compile the code to a very simple and custom bytecode. Now I wanted to write an implementation (prototype) for Librepilot. Firstly, I intended to connect an arduino through one of my Revo's ports. The compiled code would be uploaded into the arduino which is the responsible of execute it and send to the Revo the simple instructions through UAVO waypoints to the pathplanner.

The problem is that I've seen that I need to connect the aux mag of my gps to be able to flight autonomously. Now I'm using one port for the GPS and the other for the aux mag, so I don't have any free port for the arduino. I could buy a one-port gps or a OPlink module to solve the problem but I would like to save that money. And I'm thinking to modify the firmware to add a custom flight mode, which executes the bytecode interpreter and interacts with the plathplanner obtaining the same result as the solution with arduino.

Do you think this is feasible? I've never touched the Librepilot code before and I'm not sure if it would be fast enough to be worth it.
Any suggestion?

Thanks

[TheOtherCliff]

I am guessing you have a Revo.  I recall that Flexi-IO (RM_RcvrPort) (the connector with 10 pins but only 8 wires) can actually do two functions at once.

from shared/uavobjectdefinition/hwsettings.xml
                <field name="RM_RcvrPort" units="function" type="enum" elements="1" options="Disabled,PWM,PPM,PPM+PWM,PPM+Outputs,PPM+Telemetry,PPM+DebugConsole,PPM+ComBridge,PPM+MSP,PPM+MAVLink,PPM+GPS,Outputs,Telemetry,DebugConsole,ComBridge,MSP,MAVLink,GPS"

Note that you can do GPS and PPM (RC) at the same time.

Be aware that I2C mags often require two pullup resistors (say 2.5k from both SCL and SDA to +3.3V, best done inside the GPS shell) to work and that they also work best with short twisted cables.

Also note that at various times in the past, we have begun implementation of Python (deprecated) and Lua for scripting purposes to allow writing e.g. fixed wing landing approaches.

[TheOtherCliff]

So your Arduino could send RC-like (radio control) commands using PPM and you would still have GPS, AuxMag, and a port left over for something else (regular RC control, but multiplexing Arduino and RC commands would be needed).  See below for other, better ways of doing this.

What you doing sounds very interesting!

I think a better way would be GPS, AuxMag, and Telemetry.  Telemetry allows you to send commands (low level like bank left 5 degrees at 43% power or medium level like fly northwest at 5 meters per second while climbing at 1 meter per second or high level like fly to XYZ using velocity V) and also to receive status (like GPS position and velocity).  The Arduino would be connected to an RC receiver and one of the RC channels would switch from Arduino just being a pass-through to actually controlling the vehicle (Arduino reads RC somehow, probably PPM, and sends simple RC-like commands via telemetry).

If you are not using telemetry, consider using a Y cable on the GPS so both Revo and Arduino can know position and velocity.  One issue to consider is that Arduino sees GPS altitude (inaccurate) while Revo uses GPS+baro altitude (more accurate).  These two can differ by several meters.  Telemetry allows Arduino to see the GPS and also the GPS+baro altitude so they can be in agreement.

Learning how to read and write these UAV Object telemetry packets is a fairly difficult programming task.  If you are pressed for time, it would be better to just send RC commands to Revo via PPM, but you don't have a baro on the Arduino, so e.g. when flying laterally, the Arduino, only seeing GPS, may see some variation where Revo uses GPS+baro.

The following talks about using PPM to send RC commands to Revo.

The high level where you let the Revo do a lot of the work (including using Revo baro):  One flight mode (I think it is AbsolutePostion) translates stick position into compass direction and velocity.  Half forward stick always flies north (at current altitude) at half the max configured velocity while throttle stick position translates to vertical velocity (there is deadband on all sticks, so you can do simple position hold with no drift other than from GPS drift).

Or you could use less of the Revo smarts and control just bank angle and throttle, without Revo even knowing the GPS position (Arduino would be reading GPS).  You would need to develop a control loop (e.g. PID loop) to for instance handle flying in wind where you must hold a constant bank angle just to stay in one place.  You also need a control loop for vertical velocity and vertical position, and be aware that GPS is very inaccurate vertically.  That is why we fuse baro readings into the GPS vertical direction.  And Arduino won't have access to baro data...

FYI, LP has waypoint flight which allows flying lines and arcs from one waypoint to another and at different speeds (etc).  That can be combined with some flight mode yaw options to make a quadcopter point in a desired direction while flying in another direction.  I am guessing you are focused on quadcopters, which are easier to direct from a high level once you have them stabilized and flying

[gon]

Wow, thanks so much for your elaborated answer!

I didn't know that you can use the same port for RC+GPS, so that is solving my problem: Then I can use the free mainport to connect the arduino through telemetry. (I already connected it through telemetry using a library so it won't be a problem).

I think that using the waypoints to avoid implementing any kind of self-driving functions is key to maintain the project easy. So I'll avoid everything that doesn't involve the use of waypoints and telemetry.

Although I already have my doubt solved (with the RC+GPS that you mentioned), I still would like to know how hard the implementation in the LP firmware would be. I think it would be a cleaner approach to write the interpreter inside the LP since with the arduino, everyone who would like to try this language should have a free port and arduino inside the drone.

Also, I'm starting to think that buying the OPlink module would be worth it. I could "upload" the program in this invented language without having to connect the pc with the arduino through USB. In fact, I wouldn't be uploading it anymore: I would just have to write a computer program which interprets the program and sends the waypoints through telemetry over OPlink as the arduino was originally doing before, replacing it and freeing a new port. (Much more people have a LP+OPlink than LP+Arduino on board).

In conclusion: Firstly I'll try the implementation with the arduino using the "new" discovered port. Secondly, I will consider buying the OPlink and writing the interpreter for computer. Finally, to discard the LP firmware modification, would like to know if this would be very hard (I understand that the Python script approach is not supported anymore).

Thanks so much!

[TheOtherCliff]

So it sounds like in your approach, you want to have RC go into Revo and also send telemetry from Arduino which also has commands to move Revo (go to waypoint) in it via telemetry.  You may run into issues with Revo receiving two sets of commands.  If Arduino is always sending waypoints, then you would need to be careful to check that Revo ignores that when you expect it to ignore it.  Arduino could not be coded to try harder and harder when it is being ignored.  There probably is a way to make this work, to ignore the waypoint when in a simple flight mode, but

Personally I think it would be better to connect the RC receiver to the Arduino with say a 3 position RC switch and the first two positions map straight through and those positions also have the RC stick controls map straight through to Revo.  These modes allow you to fly it in Attitude mode (good for takeoff and learning) and VelocityRoam (good for testing GPS functionality)  or PathPlanner (our waypoint mode).  The third switch position would be recognized by the Arduino to mean for it to start doing it's autonomous thing, which may even need a different mode sent to Revo as a third switch position received by Revo.  Probably use AbsolutePosition mode or something that allows the use of waypoints.  There is some old functionality called magic waypoint where it flies to where ever you set the waypoint.  I have never used it and I am not sure if it still works.  Arduino always knows that Revo is obeying it in the current mode.

[gon]

Yep, something similar I thought to avoid sending commands from arduino and RC controller at the same time.

I was to only "activate" the arduino when it detects through telemetry that the flightmode switch was in position 3. Else, it wouldn't do anything letting the drone be controlled with a normal RC controller. What you are saying is a valid option too, I'll consider it!

Thanks