APM 2.5 with EzUHF and Attopilot Current Sensor

This is how I did the wiring between EzUHF and APM 2.5. I'm using 5s lipo so I have to use the Attopilot current sensor. I'm not sure this is the right way to supply power to APM.

It would be nice to have a 3DR current sensor up to 6s or an Attopilot sensor which could also supply power to the board because now it is only a sensor.

I wanted to do the radio calibration last evening and it worked good at the beginning but after it started to loose connection with the computer and then it was completely unable to connect.

I hope I didn't fry anything. Could somebody please check the wiring if it is correct?

Thanks.3691274448?profile=original

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • And I have another issue. It's not related to this topic but maybe James can help me out.

    I wanted to setup failsafe but when I went into that menu there is no "failsafe option" where you can select what APM has to do in failsafe mode (RTL, Loiter, etc.). Do I need to disarm to do this?

    • That's quite an open ended question.  Have you read through and followed the instructions here?  http://plane.ardupilot.com/wiki/apms-failsafe-function/

    • Hi James,

      Yes, I red through the instructions but it's not working with ezuhf.

      I was able do setup failsafe in a very easy way: set RTL on transmitter and push failsafe button on ezuhf Tx.

      Dont't have to mess with throttle failsafe and PWM numbers.

      The failsafe option (where you can determine what to do in case of failsafe) is not available any more (or at least in my case) in Mission Planner and APM Planner. There is only a "short failsafe" and "long failsafe" option (it doesn't matter if it's armed or disarmed).

      You can set these up under FS_SHORT_ACTN and FS_LONG_ACTN.

      The firmware update also worked this time it was a port setup thing in Win7 device manager:

      setting for the port: speed 115200, 8, N, 1, XON/ XOFF.

      I'm powering the board and Rx from Output rail with BEC and JP1 is installed.

      Everything seems to work properly on the ground.

      Thanks!

    • Throttle failsafe is different than what you are setting up.

      From the sound of it, you're setting up your failsafe output from your Rx to output a mode change to APM, changing the flight mode to RTL when control drops out.

      With that setting, you have no options.  When your radio loses connection to home, the plane will drop into RTL mode, when you regain signal on your Rx, you will pop back into the mode your mode selector button is set to.  It may create rapid mode changes, and is not optimal.  APM only thinks that you are purposefully switching to RTL mode and doesn't understand that control is cutting out.

      If you want to set up throttle failsafe, you can set the failsafe output from your Rx to drop the throttle signal down to the minimal PWM output.  APM reads this as your signal dropping out, because it is not a normal PWM signal, and not within the normal trim levels.

      When APM gets this low PWM signal, it then switches to the short action, if set.  If the low PWM signal continues, it will set the long action (normally RTL).

      Hope this helps to clarify the throttle failsafe function.

    • Yes, You are right. throttle failsafe is different. What I did is not a real failsafe from APM side. It is only a mode change as you said.

      I also tried to setup throttle failsafe but it is a little bit complicated than in the manual because with ezuhf I can't go lower than -100% with trimming the throttle down. I have to set -100 to -90 as zero throttle on the transmitter so -100 will be the failsafe trigger value. I'm not sure if I want to do that because everything is working fine now. I set up RTL for both short and long action.

  • I have just found this:
    https://storage.ning.com/topology/rest/1.0/file/get/3702182529?prof... it make any difference to connect the signal wires only of each channel (plus on one channel the power supply of course) instead of all 3 wires (s,+,-)?

    • It shouldn't.  The power and ground on both components are on their own common bus, so a single power and ground is the same as having all of the power and grounds connected.  Electrically it should not be any different.  You'll see people wire their systems like that to simplify things and reduce the number of wires needed.

      When you lose connection, do your functions still operate (lights and servos both?).  It could be only a usb connection issue.  There are many threads here about usb connection troubleshooting.

    • Yesterday I tried to update the firmware to 3.5.0 upload went well but the validation failed.

      I also noticed that powering only through USB the ezuhf rx sometimes loosing connection with the tx and the red light on it starts to be solid or blinking randomly not like the normal heartbeat blinking. Don't know if it is a wire connection, APM or ezuhf issue.

      I tried this with another cable as well. When it lost connection it still had power and the rx as well.

  • I'm not super familiar with the attopilot sensor.  Sounds like it does not provide power to the board?

    Which of your lines include power and ground wires?  All?

    Have you reviewed this page?  http://plane.ardupilot.com/wiki/common-powering-the-apm2/

    • Basically I'm using this option:

      No Power Module and using Servos with BEC power from two ESCs

      • If you do not have a power module and you are using servos remove JP1.
      • Provide APM and receiver power via 1 pair of ESC-BEC power wires connected to the APM INPUT connector power pins.
      • Also connect another of the ESCs power wire pair to the OUTPUT connector.

      The only difference is I provide power from the same BEC to the INPUT and OUTPUT rails.

      I hade to connect the second cable from BEC to EzUHF because when I connected it to the INPUT rail EzUHF didn't work properly so it didn't have connection with the radio (solid red light on RX instead of blinking).

This reply was deleted.