MiruMod

AR.Drone v1.0 and v2.0 WiFi-less mod by miru

Older versions - change history


DRS022
  • SETUP mode shows switch- and mode-selection in sketch. Example: 1sM2 means one switch Mode 2.
  • Dropped MERX Macro, mechanism uses fixed 0.5 second timeout. The trigger of the mechanism will not initiate an auto land directly; it rather signals the companion program that RX/TX got disconnected. Added disconnect action deferral time to configuration parameters. The disconnect action is done by the companion program now, this way the auto land can be done even if the Arduino/MiruPCB gets physically disconnected from the drone.
    The default disconnect action is to land the drone after the timeout set in the configuration parameters. The disconnect timeout is cancelled should a reconnection occur within the timeout period.
  • Improved Arduino link failure check, this would NOT have been an issue if the mod would always be properly secured. The new 6 position connector with 5 pins making the connection is definitely not enough to hold the whole assembly from a mechanical standpoint!
    An Arduino/MiruPCB link failure is considered catastrophic and the drone is instructed to land immediately, there is no recovery from that!
  • Changed default climb speed in Standard configuration from 1500 -> 2000 mm/s.
  • Dropped supports for drone firmware 1.7.4 and below, those are the pre session concept versions.
  • Reworked my work around Parrots session concept. The connection to an iDev is much better now. Extended iDev communication failure timeout to 30 seconds, sometimes FreeFlight just goes to lunch when it starts up.
  • If you use the GSWO output (GSWO_ENA >= 0), there is a new macro GSWO_SRC which allows to choose between the GEAR channel status and BEEP. BEEP is a new signal intended to drive a buzzer on the GSWO output. Keep in mind, this output comes directly out of the processor, it uses 5V signaling and can source/sink 20mA without major problems. Don't kill the output, when in doubt use a transistor/FET to switch the load.
  • The new BEEP signal is designed to give audible feedback to the user. If the pilot is used as companion program it will beep once when it receives GPS data for the first time, 2 or 3 beeps when the GPS changes fix status. The pilot will also beep 3 times when it thinks it arrived at the target position.
  • Stick-o-magic of throttle stick has been extended. Stick right still sets/resets an EMERGENCY, but stick left action depends on throttle position:
    • left-up causes 5 BEEPs, if you connect a buzzer you have a 'find me' alarm
    • left-mid issues a flat trim to the drone (like before, except it will not set home)
    • left-down: tells the pilot, if running, to set the home position if the GPS is ok
Pilot companion program changes:
  • Added LAUNCH point, it is set on launch if the GPS is working. The "Return to Home" function (RTH) is called "Return to Launch" (RTL) now. The HOME point is set by the user (throttle stick down-left) and provides a fallback position in case the launch point can't be set at launch. FYI: The HOME point is not committed to permanent storage and does not survive a reboot of the system!
  • Pilot is monitoring iDev more closely; a start/land from FreeFlight is recognized by the pilot program and simulated in the NavData forwarded to FreeFlight. You should tell FreeFlight to take-off, which the drone will not do but FreeFlight will think it did. This way FreeFlight will communicate waypoints you set. If you have an onboard GPS you can switch to the Navigation screen in FreeFlight and set a waypoint by touching the map and pressing 'GO'. Opposed to the way FreeFlight behaves, this will only set the waypoint! You have to switch to FM3 for the pilot to engage and take the drone there. The pilot will consume the waypoint once instructed to use it; the next switch to FM3 will be a RTL unless you manage to set another waypoint.
    This feature is limited by the reach of Wi-Fi since the iDev needs to be able to communicate with the drone to set the waypoint. A waypoint can be set outside of Wi-Fi range; it has to be at least 10 Meters away from the current position, but must be within an 1100 Meter radius of the launch/home point. If the current position or launch/home point is unknown (bad GPS data) the waypoint cannot be set.
  • The pilot programs disconnect action might be different from the default auto land. If the GPS is working, the launch/home point is set and the drone is further away than 10 Meters from it, the pilot will take the drone up for 3 seconds at half power and then attempt a RTL. On a reconnect the pilot is aborted and the mod goes back to following the instructions from the TX. Don't put your TX on LAND if you see it happening, if RX/TX reconnect and the flight mode is LAND the drone will land, no matter what you do. If the pilot succeeds in reaching the launch/home point before a reconnect occurs, it will lower the altitude gently until an altitude of 2,5 Meters is reached and then lands the drone.
  • When the pilot is in command of the drone the 'running lights' blink with a one second period.
  • Added pickup of FlightRecorder GPS data from NavData TAG 27.
  • Pilot program fills TAG 27 if there is no FlightRecorder present and the Arduino/MiruPCB sends GPS data. This way the iDev navigational maps will work for you.
DRS021
  • Pulled RX_CON macro to front and set default to 0
  • AUX1 channel inversion controlled by macro IN_AUX, default set to 1 to match previous versions.
  • Added new macro NL_AIR to turn off LED when airborne, default is 0
DRS020

Due to mistakenly set default configuration it is recommended to skip version 020 of the sketch and use version 021 (or higher) instead


There were too many changes to document here. A lot of changes were prompted by the desperate search for code space. Here are the highlights:

  • Fixed rx_read() bug, FTTOT comparison needs to be done differently.
  • Fixed bug, Drone 2 max height limit 100000 -> 1000000 (can't turn it off).
  • Switching baudrate to 38400 before upload of companion program.
  • Dropped NMEA user input in SETUP mode
  • Dropped hardcoded inversion of AUX1 channel, you have to do that in the TX now.
    !! Make sure you run SETUP and check your flight mode switches !!
  • Dropped FSAF input, all RX units used so far do or can be set up to do something, to their pulses that can be detected by the sampling routines if the connection to the TX is lost. Detection of this failure initiates an auto land.
  • Dropped VLBA morse code signaling.
  • Dropped SOS code signaling, on detection of alternate controller.
  • GSWO enabled by default so GEAR channel always shows up in SETUP.
  • Optional Arduino LED off when drone is airborne
  • New error code signaling for companion program start failures:
    • 1+1 blink: shell not responding
    • 1+2 blinks: Problem with D=/data/video/usb command
    • 1+3 blinks: Problem checking for pilotXXX.arm program
    • 1+4 blinks: Problem checking for at2soXXX.arm program
    • 1+5 blinks: Problem with D=/data/video command
    • 1+6 blinks: Problem checking for pilotXXX.arm program
    • 1+7 blinks: Problem checking for at2soXXX.arm program
    • 1+8 blinks: Can't find a companion program to run
    • 1+9 blinks: Companion program detected other controller and terminated
    If the Arduino LED stays ON the sketch is waiting for the start character from the companion program. Failures 1..7 indicate something bad with the serial link between the Arduino and the drone.
  • Writing the pilot log to the USB stick on a drone 2 makes the drone very twitchy when video is recorded at the same time. at2so writes it's log to /tmp/at2so.log and pilot writes it to /data/video/P%d.txt, with %d replaced by the boot index of the Arduino modulo 5.
  • Turned out that feeding the firmware with AT*REF commands at 30Hz is not really necessary. Therefore the companion program now decides when to send these, making the 'sketch' on the Arduino less critical.
  • Some people get airborne hardware failures, like wire disconnects... Added a link check in companion program that detects if the Arduino got disconnected and lands the drone when this failure occurrs.
  • Added optional I2C port and optional drivers for BMP085 and HMC5883L.
    Note: at this point the data is not used for anything but is written to the log.
    You can use the data in the sketch or the companion program, ideas are altitude stabilisation and/or compass for drone 1.
  • Fixed FreeFlight 2.4.1+ forever 'Loading...' problem.
  • Fixed FreeFlight 2.4.1+ zeroing battery indicator on second piloting entry.
GPS
    Added RTH function in pilot for drone 2. You need a GPS connected to the mod. Beware that all GPS units I tested exhibit severe data jumps within the first couple of minutes of operation.
Hardware
    Added support for MiruPCB, a little board I designed with an Atmega32U4, a LLC and a drone connector.

DRS019

Due to time constraints (going on vacation and not having enough time to spend on this project) I am releasing rev 0.19, which has quite some improvements and additions but does NOT have a working RTH function.

  • Fixed bug in start up blink sequence (thanks Pawelsky for pointing this out).
  • RX sampling routine ignores unused signals.
  • Pilot program name changed from 'pilot.arm' to 'pilotXXX.arm'. XXX stands for the revision of the mod. The name is hardcoded into the matching version of the companion program 'at2so' so there can't be any accidental mixups by design. There is also a key exchange between the companion program and the pilot to make sure both come from the same revision of the mod.
  • Accommodating GPS units that can not store a setup for baudrate, frequency and content of reports as well as users that don't want to deal with it. 'rx2atp' attempts to setup the GPS 'automagically' with the parameters it wants. It will auto-detect the baudrate (not a choice any more), send 'PMTK' instructions to change the baudrate to 38400, the update rate to 5Hz and ask for a GGA sentence on every report and for a RMC sentence every 5th report (needed for the date). All other sentences are turned off. The sentences used for setup are:
    • "PMTK251,38400" to set the baudrate,
    • "PMTK314,0,5,0,1,0,0,0,0" to select data and
    • "PMTK220,200" for the update rate.
  • Moved interpretation of GPS data from companion program to pilot program. At this point there is no more GPS data insertion into the Navdata stream, nobody really made use of it and it costs precious code space to do it in the companion program.
  • Pilot program writes a log file to permanent storage on an external drive or the drone's /data/video directory (drone 1 or no USB stick on drone 2). The log file format is in ASCII, aka human readable.
    Pawelsky helped me a lot and wrote a wonderful piece of software that can pick up one of these log files and convert it to something Google Earth understands! This way one can display a recap of a flight on GE with all the things that happen.
  • Changed EEROM magic number, added boot counter 'bid' to EEROM data structure. 'bid' gets incremented before launch of the companion program and saved in EEROM if the companion program sends the start character. FYI, the EEROM does not get erased when you load a new sketch. The 'bid' is passed to the companion program as an argument (-l #). The companion program passes it to the pilot program. The pilot program uses the number to generate the file name for the log file. It is P%d.txt. The %d is replaced by the 'bid' modulo 20 on an external drive and 'bid' modulo 5 for storage on the drone in '/data/video'. The size of a single log file is limited to 4 Mb.
  • Redesigned data exchange between companion and pilot program to reduce the amount of data transferred to a bare minimum. There are two packets, TAG 82 from companion to pilot and TAG 81 from pilot to companion. TAG 82 is sent to the pilot every time new Navdata arrives from the firmware, TAG 81 is sent back to the companion as a response to it, it carries the GPS status and the steering instructions from the pilot program if it is engaged.
  • New feature: in LAND, if you move the throttle stick all the way down, the Arduino LED will show the GPS status:
    • 0 blinks - no GPS data or pilot program is not running
    • 1 blink - no GPS fix
    • 2 blinks - GPS has 2D fix
    • 3 blinks - GPS has 3D fix
  • New feature: the pilot program has a socket one can tap into to relay 'live' log messages as long as the drone is within WiFi range. The port is datagram port 12000 on <drone IP>, you have to send it a 'lbeg' message to start receiving log entries and 'lend' once you are done. Check a stored log for the interpretation of the messages.
  • Decided pilot is not ready for prime time -> disabled for now
  • SETUP GUI changes (click for details)
Note: I am still not happy with the pilot program's navigational skills, especially on a Drone 1 which has a problem reporting changes in it's heading when certain events occur. On a Drone 2 the challenge is that the heading data is referenced to magnetic North and the GPS data is referenced to 'true' North. The solution to this will have to wait until I can spend a lot more time on it, which is hard to come by at the moment. There seem to be some new GPS units out which don't use the SirF protocol, they have a way to report the magnetic heading, which would take out a lot of extra software.

DRS018

  • Cleanups in the Arduino code, eliminated usage of floating points.
  • rx_read() is checking the UP time of a RX signal against the current time and faults the channel if it is too long.
  • Limit of <rol>,<ptc>,<gaz>,<yaw> values to +-1.000 .
  • Added NSQUIET back in for boot (NSQUIET 5, NS_BOOT 18).
  • New config option 'record_on_usb' for D2 (ignored on D1).
  • D2, auto start/stop video recording on LAND->FMx/FMX->LAND if 'record_on_usb' is ON AND there is a stick with space for a video
GPS
  • Auto pilot program is not part of the compagnion program any more because the whole program became too big to fit as a 'piggyback' on the Arduino program. This means, you have to put the auto pilot program on an USB stick where the companion program can get it or you have to 'ftp' it to the drone (D1)
  • GPS serial port has auto baud rate detection now (4800...57600)
  • GPS data is processed by pilot program, FTRIM sets 'home' position, FM3 attempts to do a 'return to launch'. FM3 is cancelled by movement of ELEVATOR/AILERON stick.

DSR017

  • Fixed NS_BOOT macro, is 21 seconds now.
  • Moved generation of configuration commands to companion program.
  • Made changes to accommodate Drone 2.
  • New wiring diagram for Drone 2. You need to get a level shifter like BOB-08745 from sparkfun to make the Drone 2 I/O at 1.8V work.
    The resistor solution we have for Drone 1 will NOT work, you actually will kill the drone!
    The new wiring just changes the drone interface, nothing else.
  • Added animations. The sketch has an 'animation' trigger now. The activation works like this: fly in FM2, do a short switch from FM2 to FM1 and back to FM2, for the next 0.4 seconds you can trigger one of 4 animations with the elevator/aileron stick. If you happen to fly a Drone 2, it will flip in the direction you moved the stick, a Drone 1 will nod in the direction it would flip if it could. This feature can be turned off on a configuration basis, so you can have configurations that do it and others that don't.
GPS still in the works, Drone 2 was more interesting.

DSR016

Before uploading this sketch to Arduino set NS_BOOT in line 1713 from 10 to 21.
Otherwise the mod may not boot.
It will be fixed in the next release - see HERE

  • Replaced companion program flags -itf with single -w flag, if present it blocks any Wifi traffic.
  • The new companion program flag is set 'automagically' by the sketch, if the throttle stick is low or high right before the upload of the companion program, the -w flag to the companion program is set. This way, if you put your throttle stick low during startup, there will be no Wifi to worry about. If you want to access the drone's video, leave the throttle stick centered on startup.
  • Added support for recording/capture function of FreeFlight 2.0.
  • Companion program upload is done at 115200 baud now, the switch to 38400 baud is done after the upload. Also eliminated 'quiet' time requirement before upload, it turned out that the shell I need to upload is available much earlier and I can deal with the messages coming from the firmware. This change makes the 'boot' of the mod really fast.
I want to thank you all for the generous contibutions you make to my beer fund! It supplements the funding for all the new experiments I am doing with the drone.

GPS is still in the works, just found another one I want to try...

DSR015

  • added changes to make video on firmware 1.10.10 and FreeFlight 2.0 work properly. This also resolves the CONFIG_IDS issues I was having, it is now possible to change the video source from the iDev as well as from the TX.
  • added -i flag for companion program (settable in 'sketch), it blocks command, navdata, video and data port access from the outside.
Note: GPS still in the works...

DSR014

  • cleaned up some code (thank you Pawelsky for pointing things out).
  • added delayed 'failsave' action, the RX has to fail for 0.5 seconds before an 'auto' land is initiated, this feature can be turned off or elongated in the 'sketch' (look for the macro MERX).
  • added iDev presence detection on startup. If an iDev is present at start of the mod, the mod will bail out and signal SOS on the Arduino LED. The code to make FreeFlight 1.9.3 with firmware 1.7.11 happy is too large to fit in the Arduino FLASH, the only benefit would be that one can switch cameras from the iDev...
  • blocking outside connection attempts to TCP port 5559, which disables the iDev's ability to gain control and/or retrieve configuration information.
  • if firmware 1.7.11 or better is on the drone, the mod will enable the P264 codec, giving much better video performance. Be careful with iDev applications that can't handle P264, they usually crash...
GPS is still in the works, don't have enough field flying time to get it working to my standards...

DSR013

  • implemented new proposed pinout, see diagram
  • locking out all iDev CONFIG commands
  • using new CONFIG_IDS scheme if drone firmware is 1.7.11 or above
  • SETUP mode shows configuration setting, you can change and save it as well
  • an elevator stick right in LAND, sends a switch camera command to drone
  • increased control loop speed from 25Hz to 30Hz
Sorry still no GPS code. Made successful testflights with ProMini and Nano with drone firmware 1.7.4 and 1.7.11.
Used FreeFlight 1.9.3 for video observation, it shows battery status and emergencies, video is almost 'live'. cleaned up some code (thank you Pawelsky for pointing things out).

DSR012

  • bugfix, rx_loop() did not mask result of rx_read() with S_SIG -> no FTRIM, ESTOP display.
  • added recognition of 'dead' receiver (no signals).
  • added Arduino pin 12 as optional output to reflect TX GEAR switch status:
    /* You can route the GEAR channel status to an output to switch something ON/OFF.
    * Using pin labelled 12 on Arduino */
    #define GSWO_ENA -1 /* -1 disable, 0 active low, 1 active high */
I am still working on finding a solution to my GPS problems, currently there are two more on their way for testing.
I did install and use the new arduino-1.0-win.zip as well as FreeFlight 1.9.3, which updates the drone to 1.7.11. There were NO problems during a 15 minute testflight.

DSR011

  • Added optional use of pin labelled A3 as receiver signal loss input. This is for TX/RX setups where a 'failsafe' can not be programmed. The feature is disabled by default and can be enabled in the 'sketch':
    /* Receiver signal loss input
    * some RX/TX setups don't implement a recognizable 'failsafe', however in some
    * cases one can monitor the signal to the 'connected' LED to recognize a TX loss.
    * If you want to use this feature, connect the signal to the pin labelled A3 and
    * enable the feature below.
    */
    #define FSAF_ENA -1 /* -1 disable, 0 TX loss A3=0, 1 TX loss A3=1 */
  • Added morse code blinking capability to VLBA output. For now it will send a 'R' on FTRIM and transition to FM3.

DSR010

  • Arduino NANO integrated and tested. The reasons for integration were that the NANO has a beefier power regulator and provides 3.3V power for a LS20031 GPS.
  • Start sequence looks at 4 things in parallel now, you can tell what it is working on by observing the LED on the Arduino:
    • 1 blip -> radio not ready
    • 2 blips -> radio ok, but FMODE not LAND
    • 3 blips -> radio ok, LAND, waiting for drone to boot
    • 4 blips -> radio ok, LAND, drone booted, waiting for silence on tty
    After that, the LED goes sort of dimm during the upload and start of the companion program and turns bright while it is waiting for the 'magic' start character from the companion program.
  • Lock out WiFi telnet contacts and ftp write on drone by default. You can change the default behaviour by setting the macro AT2SOARGS in the 'sketch'. In this release AT2SOARGS in the 'sketch' is set to "-t" to allow telnet in, use AT2SOARGS "" to lock it out.
  • Added flight mode 3, it will be used in the future to trigger the various GPS based functions. FM3 is reached when you are in FM2 and shortly switch to FM1 and back to FM2. It is cancelled by either switching to FM1 or LAND or moving the aileron/elevator (elevator only for Mode 1,4) channel out of 0 position.
  • GPS serial interface supports 38400 and 57600 baud. Those speeds were a major problem in previous revisions. GPS (GGA record) data is added to Navdata (tag 80). Check the README for the binary structure.
  • Arduino pin D11 became an additional pin for SETUP. This makes the wireing of an Arduino NANO less painful and more elegant. UFO-DOCTOR is working on another good documentation piece for the NANO!

DSR009

  • Visual Low Battery Alert moved to program on Arduino. Added pin (9) as an output for the mechanism.
    • Thank you again UFO-DOCTOR for testing and adding to your tutorials as new features get integrated. UFO-DOCTOR will extend his tutorials to show you possible uses of the new output.
    • Thank you Candu1 for having the vision how this output could be used (blinking/steady, active high/low).
    /* Visible Low Battery Alert
    * the program can watch the battery capacity (percentage) on the drone, if it
    * goes below VLBA_THR the VLBA mechanism triggers. The drone's LEDs flash RED
    * and the VLBA gets activated (blinking/steady), set to 0 to turn VLBA off */
    #define VLBA_THR 15 /* 0 or > 60 turns it off */
    #define VLBA_POL 1 /* 1-active high, 0-active low */
    #define VLBA_BLINK 1 /* 1-blink, 0-no blink */
  • The move of the mechanism required a major change in the communication between the program on the Arduino and the program on the drone. The Arduino, running at 16Mhz, is challenged receiving data with it's USART at 115200 baud, which prevented the implementation of sending more than one byte at a time from the drone to the Arduno (it does work well the other way around). This revision changes the baudrate of the link to 38400 baud, which makes it possible to send multibyte data from the drone program to the Arduino progam. The choice of 38400 baud is based on the facts that the 16Mhz Arduino can do it with a very small error (0.2%) in clock frequency and the Linux on the drone does not support 76800 baud (my first choice) without making some handstands.

DSR008

  • Added support for transmitters with Mode 1, 2, 3 and 4. The default is Mode 2.
  • Added Visual Low Battery Alert, a feature requested by UFO-DOCTOR. The default threshold is 15% of battery capacity. Once reached the drone will start to blink the motor LEDs in red, to tell you it is time to land.
Thank you UFO-DOCTOR for the VLBA idea and testing the implementation of the feature in your lab. You are doing a great job writing the tutorials!
Thank you to everybody else for participating and giving me feedback, it is valuable to me and sprouts new ideas what could be changed.

DSR007

  • Auto unpair drone. This fixes a problem some people had using the mod. The unpairing is NOT permanent, it just takes care of things for the current session.
  • Four 'hot' selectable configurations for drone. After long deliberations, trials and helpful input from you guys, I decided on using the following scheme to get multiple configurations of the drone 'hot' selectable:
    The drone needs to be in LAND. Push the throttle stick all the way up and leave the pitch/roll stick centered, the Arduino LED indicates the current configuration with 1, 2, 3 or 4 blinks instead of the normal 12.5Hz blink.
    To select a configuration, use the pitch/roll stick:
    • down - configuration 1
    • left - configuration 2
    • up - configuration 3
    • right - configuration 4
    The Arduino LED will indicate the selection. To make it 'stick' hold the pitch/roll stick on your new selection and move the throttle stick down. This will store your choice in EEPROM on the Arduino and upload the new parameters to the drone. You'll see the drone blink the motor lights when the new configuration is received. The selection is permanent until you redo it, rx2atp reads the EEPROM on start. Configuration 1 is the default, the one we have been using up to here, configuration 2 has all variables set to max (really jumpy), configuration 3 is an indoor config and configuration 4 is even lamer than that. You can change the configurations in the 'sketch', just make sure you adhere to the format they need.

DSR006

Processed your input on the switches. The S_FMS macro is replaced by two macros S_LAND and S_FMOD.

/* switch setup, S_GEAR-(2 pos), S_AUX1-(2 or 3 pos) *
* S_LAND S_FMOD
* S_AUX1 S_AUX1 one 3 position switch (e.g. DX7)
* S_GEAR S_GEAR one 2 position switch
* S_GEAR S_AUX1 two switches (e.g. DX6)
* S_AUX1 S_GEAR two switches
*/

#define S_LAND S_AUX1
#define S_FMOD S_AUX1

Just finished test flight and it works good here. I could not flight test all possible configurations (lack of time), so feedback is greatly appreciated.
!Make sure you go into SETUP mode and check what the switches are doing!

DSR005

Lorenzo29, thank you for the explanation, I added comments in the source with the ranges you shared.

Actionplus, don't worry about the GPS, I don't have one yet either (had to send it back). Just don't connect anything to Arduino terminals A0 and A1. Rev 0.05 should help with your receiver (1460 midpoint), would be interrested what the new revision reads.

  • The receiver sampling is now +-800 points (0.5 microsecond resolution).
  • Editing NavData now. 'at2so' takes out tag 16 (120 bytes 0). Added request for tags 1, 2 and 3 (raw sensor data). Added tag 80 to transfer location data from GPS.
  • Redid the configuration dialog with the drone. It follows 'the protocol' now. Moved CONFIG commands of general nature to 'at2so'. The parameters you might want to change are macros now, they are in the beginning of 'rx2atp.c'.
    #define CFG_OUTDOOR "TRUE" /* TRUE or FALSE */
    #define CFG_NO_SHELL "TRUE" /* TRUE or FALSE */
    #define CFG_EULER_ANGLE_MAX "0.30" /* 0 ... 0.52 max pitch/roll angle [rad] */
    #define CFG_CONTROL_VZ_MAX "1500" /* 200 ... 2000 max climb speed [mm/s] */
    #define CFG_CONTROL_YAW "3.5" /* 0.7 ... 6.11 max yaw speed [rad/s] */
    #define CFG_ALTITUDE_MAX "10000" /* 500 ... 5000 altitude limit [mm], 10000 is OFF *

DSR004

Here is the latest....

  • Moved all AT command generation to drone program
  • Drone program looks at NavData now and automatically resets the dreaded COM_WATCHDOG which seems to cause the loss of control when flying over grass
  • Drone program does not lock out iDev anymore, just intercepts the command port and takes out any PCMD/REF messages. This way you can watch the video and make setup changes. Just make sure you start your iDev application AFTER 'rx2atp' is running, otherwise you loose NavData on the iDev.
    There is a downside to this... the drone is not that responsive any more if video is on, unfortunately there is no way to turn it off without rebooting it
  • Added a 'soft' serial port for a GPS receiver. The port can handle 1200 ... 57600 baud. The data is parsed according to NMEA rules and sent to the drone program, which at this point does not do anything with it yet (my GPS receiver is in the mail...)
  • The drone program backpack became rather large, it is compressed now
  • Pruned the number of files in the zip file down to the essentials. All you really need is 'rx2atp.c' for the Arduino
Let me know what should be different

DSR003

Here is the latest, I think I was able to incorporate most suggestions. Thank you Laurent for making me look into the 'no hover' fly mode, it works great, no more back-flips!

Rev 0.03 works with 5 channels, four for the sticks and the fifth as a flight mode switch. You have to choose in the 'sketch' which channel you want to use as the flightmode switch (GEAR or AUX1). GEAR is interpreted as a 2 position switch which gives you LAND/FLY choice. AUX1 is interpreted as a 3 postition switch, you'll get LAND/FM_1/FM_2. FM_1 is like FLY where the drone is told to go into hover if AILE+ELEV are centered, FM_2 does not tell the drone to hover if the sticks are centered. When the flightmode switch is on LAND, the RUDD stick works as a push button, move it left -> FTRIM/LED/COMWDG, move it right -> EMERGENCY signal to drone (needed to reset EMERGENCY flag in drone).

If you like the MiruMod and would like to buy miru a beer or two for his great work you can do so using the PayPal "Donate" button below

Website by Miru (2021)


Template Design by Download Website Templates