Auto takeoff & Alt Hold (with no GPS dependency)

[Zhen Liang Low]

Hi all,

I would like to ask if it is possible to edit the APM v3.2 code to have a new mode which allows me to perform automatic takeoff and then altitude hold. This is to implement on the 3-way aux switch instead of controlling through Mission Planner as I do not have the GPS attached to APM3.2 

(The principle work same as the DO_Takeoff in the Planning a Mission in Mission Planner)

[David Pawlak]

Through MavProxy and or DroneAPI you can do scripted sequences which should permit you to do what you are looking for.

It's what the GCS's use to implement their command sequences.

[Zhen Liang Low]

Hi David,

Is there any website guidance for this area as I do not have such a strong area in this field.

Thanks for the reply by the way!
Zhen Liang

[Zhen Liang Low]

Besides this two programs, Mission Planner cannot integrate together with DroneAPI?

[Zhen Liang Low]

Can I put the DroneAPI script in Mission Planner instead of MavProxy?

On Saturday, February 7, 2015 at 1:19:54 AM UTC+8, David Pawlak wrote:

[Linus Casassa]

I thinks you can use scripts in Mission Planner but I have not tried it.

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Linus Casassa
Fono: 56-9-97776941

[Zhen Liang Low]

Thank you, but i cant find any guide on this the guide in ardupilot seems pretty general

[David Pawlak]

Hi Xhen

http://dev.ardupilot.com/wiki/droneapi-tutorial/

This link should give a good start at installing the code. Everything is in python so it's comptible to most all operating systems.

Also

http://tridge.github.io/MAVProxy/

has more information as well.

Sometimes getting the environment set up is the most difficult. writing and testing the code is quite easy. MAVProxy is a bit lower level and Drone API gives higher level scripts to help with running the MAVProxy code.

You might have to look around a little deeper for more detailed specs on the various calls you may want to use, but it's all worth getting into.

This is often really the best "practical way" to make the interfaces you are looking for.

On Friday, February 6, 2015 at 7:53:30 AM UTC-3, Zhen Liang Low wrote:

[Zhen Liang Low]

Hi David,

The setup for this only shows MAVproxy command into the APM either via "USB, or telemetry(XBEE for mine)" can I open Mission Planner while using this commands? I believed that the Mission Planner will not allow me to connect APM as Mavproxy is connected to the comm port at that instance. So can MAVproxy shows me a data in Graphical form?

[Al B]

Hi David,

Can this also be applied to setup a Pixhawk module?

Thanks!
-Al

[Ankur Yadav]

Hi Zhen,

You can use both APM and MAVproxy simultaneously on the same port. It would be better if you use Linux instead of Windows and you can do graph plots using MAVproxy also.

[Randy Mackay]

 

    I’m not sure droneapi and MAVProxy is really the right solution for what Zhen is looking for.

 

     It sounds like he wants to be able to trigger this from a ch7/ch8 switch.  It’s possible to do that with mavproxy by monitoring the rc outputs from the main fligh controller but it’s pretty clunky.

 

     I think instead a new ch7/ch8 option would need to be added to switches.pde and defines.h. and then the take-off command in GCS_MAVLink.pde would need to be modified to accept the take-off command in other flight modes (i.e. AltHold).  Then modify the AltHold controller to always provide a climb to the z-axis position controller somehow until the target reaches the desired altitude.  Alternatively a new take-off flight mode could be created.

 

     By the way, I’m not too hopeful this feature would be added to master.  It seems that if you’re taking off in AltHold mode, the pilot would already have his/her fingers on the sticks.  It’s not immediately obvious why moving a switch to make it climb to a predetermined altitude is better/easier than just raising the stick until it reaches the right altitude.  The pilot still needs to control the roll and pitch as it climbs so why not do the throttle too?

 

-Randy

--

[Zhen Liang Low]

Thanks Ankur for the information.

Hi randy, because I'm trying to fly the quadcopter in a indoor area only (max 2.5m in height), therefore I would only like to fix a normal height to fly in as I'm not good with the transmitter stick and I will fumble the Throttle/Yaw stick thus dropping or raising the quadcopter in a short span of time. So what i thought of was to fix a height in the mode totally for me to fly in and landing after I'm done with it

[Zhen Liang Low]

If this function is capable, then next I would implement a voice recogniser such as EasyVR Shield 2.0

(http://www.sgbotic.com/index.php?dispatch=products.view&product_id=1624) to take off and land the quad via voice command.

Another side question: if I were to create a new flight mode, can I trigger the throttle hold at a fix value using this 

attitude_control.set_throttle_out(value, false); where value is the fix value in which the output is at the desire height?

[stdio9]

Would it be helpful to have more mission metrics appear within our various ground station mission planning tools? An example I'm thinking of is a rudimentary time counter since mission start. Because we know the target speed (when we're connected, could be hand jammed at other times) and because the mission planning software could report distance travelled, it could also report on the length of time required to fly a pattern (it need not be very accurate, the most basic figures would help for scaling a mission.)

As a feature like this became more accurate, it could be used for planning more complex missions, choreographing shots, or multi-vehicle flights, but the primary application of something like this is to help new fliers scope out their missions based on battery capacity .... It's too easy for new fliers to auto-layout a mission that, in very rough terms, would require at least 40 minutes (three hours, etc) of flight time. Remember that the same (looking) pattern, number of waypoints, as a reasonable mission for an aircraft at different scales has very different flight time budgets.

I could see any number of metrics being of value, a running tooltip of distance traveled, target altitude, and an estimate of target speed (harder, maybe) but the estimated time since launch might appear at key points, or as a tool tip, or even just a single value based on total path length and target speed, with some per-waypoint average penalty assigned (especially for multicopters)

While a basic calculation wouldn't be very accurate, at least one could get a feeling for the suitability of a mission and where to break up SAR, photography, survey missions .... If the planner calculates a 20 minute mission and you get 12 minutes flight time, you'd know to cut that mission into three parts, for example.

Thoughts?

[Jon Farhat]

Michael

You can use my flight planner for this at http://thermalsearch.com.  Once you create a flight plan, you can export a WP file to open in any GCS.

This planner was created for complex flightplan and SUPPORTS Mission Planner, APM Planner, Droid Planner, etc.

You can create accounts and save your paths.  (The simulator is currently being written).  You can see the old version using GoogleEarth, (instead of Cesium) which allows sim flight and KML tours of the flight path. 

I'm looking for beta testers.

enjoy.

j.

[Craig Elder]

Thanks Jon

I did not realized you had that capability in your GCS.  Good to know.

--