Developer

Ardupilot 2.5 Beta

This is a quick note to let everyone know that Ardupilot 2.5 is feature complete and can be downloaded via SVN. If you're on Windows, use TourtiseSVN and if you're on a OS X like me, try Versions. The code is located here.Once the Beta feedback is in I'll post a zip file of the final version. Information about using SVN can be found on the web. Please post any issues in this blog post, and I'll fix them immediately and re-upload.I'm also building a wiki manual to help with the configuration, but it's an early work in progress. I'll write a lot more this week, but there should be enough content up there to get you going.Use the Airframe tester to configure your new 2.5 header file and familiarize yourself with the startup sequence. Don't use the old 2.4 file, except to copy over your old gain settings. I've tried to keep as many of the values the same, but many values are new as well.By Default the control switch settings are 1 - manual, 2 - Autopilot, 3 - Stabilize. Feel free to change them to whatever you like.Good luck,Jasonp.s. Who thinks Ardupilot needs a logo?
E-mail me when people leave their comments –

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

Join diydrones

Comments

  • Moderator
    Why the clipping (is that joining or cutting) of pin 13 to the shield, I missed that somewhere?
  • Developer
    great news!
  • Jason,
    Problem solved! I guess that some how the D13 input got fried. I have continuity from CH3-in right up to the chip but nothing on the CH3-out signal pin. So I wired the CH3/D13 jumper on the other Ardu board that I have , clipped the pin to the shield, installed it and all is working fine now with Ardupilot_25_tester. Clipped the jumper on the problem board and now Ardupilot_24 works fine on it minus the status led on the shield.
    Thanks for you help. I now understand better what is going on.
  • Developer
    could you take some pics of the top and bottom of the main board?
  • Jason,
    1. I am using a shield V2, I clipped pin 13 to shield.
    2. I used a "y" cable to CH3 out with spare servo hooked to it and the ESC which powers the ArduPilot.
    No movement of the servo or motor! It has to be electrical because there is no signal on the CH3 out signal pin. Have to find out what I did wrong on the jumper (CH3 in/ D13).
  • Developer
    What stumps me is why your servo mux is not working. In manual mode you should get some action on that throttle. Again, please connect a servo to your throttle out channel to observe the output.

    The Fasst and CC Pheonix 35 combo is exactly what I use, so I know it works. I'm guessing there is an electrical issue on your board. Try the spare servo trick, or just use your rudder plugged into ch3. If that servo doesn't respond, then you know you have the connection wrong. If it does work properly, let me know.

    BTW are you using a shield? Did you clip the pin 13 to the shield? I would suggest that as well.
    Jason
  • Jason,
    I am not using reverse throttle in 2.4 header. I have managed to get Ardupilot_25_tester to work by using an Ardu board without the second jumper (Ch3/D13). The throttle is now active. In manual the motor follows the throttle stick, in FBW and stabaiize the motor is at about 75% power and does not follow the throttle stick. I have my FS set to control channel stabilized mode/ throttle normal and the tester recognizes the FS and goes into stabilized mode with 75% power.
    Seems to me that FASST / CC Pheonix combination does no like the CH3/D13 jumper because ESC does not arm using 2.4 or 2.5, but both arm without it.
  • Developer
    I have that same ESC. By default I believe it arms when the ESC detects a low throttle value. Mine arms at 1024µs. This should be self calibrating in the ESC.

    Like the previous version 2.4, 2.5 can start up entirely in Manual mode using the control switch and servo/failsafe mux. This is a complete pass through of the signal and should be identical to your radio to ESC direct connection. That means what ever throttle output is coming from your radio is output directly to the ESC.

    Do you have the throttle coming into channel 3 on the Ardupilot board and then jump to pin 13? It's important that the throttle input has a good connection to the ch3 input pin so that you can pass the signal directly to the servo mux. If you don't have the connections made properly, you may not be getting a signal out.

    A good way to test these things is to hook up a spare servo to channel 3 of your radio and note the positions of the servo as you go from low to full throttle. Then, hook that same servo to your ardupilot and do the same in manual mode at startup. Then after radio calibration, go into stabilization mode and see if you get the same servo response. Make sure you don't have the throttle outputs reversed.

    If you can, download the latest header file and make sure it's up to date as well.

    Keep me updated with your progress! and thanks for your help testing.
    Jason
  • Hello Jason. My ESC (Castle Creations Phoenix 35) will not arm. I have been using the Ardupilot_25_tester to set up. Today I wanted to fly it and set the THROTTLE_OUT to 1 in the header file and uploaded to the board. In the serial monitor I am getting throttle out response to throttle movement; however, the motor does not run. On power up the CC ESC gives the battery count beeps but never gives the beep for arming the throttle. I loaded Ardupilot_25 the same thing. Ardupilot_24 was working fine but that was with no throttle in jumper. Ardupilot_24 does not work with the jumper either. The ESC going to Receiver and not the ardupilot ch3 out works fine.
    Ardu red board Two jumpers as per wiki
    Shield blue board
    ESC CC Pheonix 35 set to fixed endpoints
    FASST R6008HS Receicer
    T10CAP/TM-10

    Nothing seems to help. Ardupilot_25 and Ardupilot_25_tester do not arm the ESC. Ardupilot_24 and Futaba PCM and another Ardupilot/Red shield work fine.
  • Jason,

    The GPS decoding bug is as follows: GPS_UBLOX: in function decode_gps, case 6, the received byte should be added to UBX_buffer and included in the checksum BEFORE the test on the payload counter to decide whether we have received the full payload and should move onto the next case (to check the checksum). In other words at present the last byte of the payload is dropped - although we are not interested in this byte in any of the messages that are decoded it means that the checksum is incorrect.

    case 6: // Payload data read...
    // We need to process the data byte before we check the number of bytes so far
    UBX_buffer[UBX_payload_counter] = data;
    checksum(data);
    UBX_payload_counter++;
    if (UBX_payload_counter < UBX_payload_length_hi) {
    // We stay in this state until we reach the payload_length
    } else {
    GPS_step++; // payload_length reached - next byte is checksum
    }
    break;



    At present we get away with the incorrect checksum because the actual check performed in case 8 is flawed, resulting in virtaully all messages passing the checksum test. There are two errors here:
    i) ck_b should be compared to UBX_ck_b (not UBX_ck_a as at present), and
    2) the comparisons are misscoded as assignments - i.e. "=" should be "==" (This means that the checksum appears OK as long as UBX_ck_a doesn't have the value 0).

    if((ck_a==UBX_ck_a)&&(ck_b==UBX_ck_b)) // Verify the received checksum with the generated checksum..

    Please can I make arequest for a future enhancement - please can you use a single define/variable to set the serial baud rate so that it only needs to be edited in once place to use something different to the default expectations - I have a uBlox module which I am using at 57600baud. Is there an official location to record requests like this?

    Good luck with finalising the release.

    Christopher
This reply was deleted.