Posted by Jason Short on January 14, 2010 at 5:00pm
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?
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.
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?
Jason, I need help with subversion client svnX for mac, Is there general tutorial on u tube for svn ? I think svnX finnally connected to repository but, I don,t see folders or files? H
ere is a screen shot... It takes to long to manually copy each file, then unlock, Thanks
Okay, here's one clue. The behavior totally changes depending on whether I've got the serial monitor open or not. I get that servo jamming with the serial monitor open. But when I close the window, I get nothing--no jamming. but also no RC passthrough.
So:
Serial monitor open: jamming the moment I open the window, and then jamming in RTL and Waypioint, although the rudder/aileron RC control passthrough works in those two modes.
Serial monitor closed. no jamming, but also no RC passthrough in either mode.
Jason, FWIW, I've tried it on the older FM Futaba and the effect is the same. As best as I can tell it only affects the elevator servo, but the effect is constant across multiple ArduPilots, airframes, and RC systems. Totally weird.
Comments
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
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.
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
It's expensive, but has a 30 day demo. Maybe try that first?
ere is a screen shot... It takes to long to manually copy each file, then unlock, ThanksSo:
Serial monitor open: jamming the moment I open the window, and then jamming in RTL and Waypioint, although the rudder/aileron RC control passthrough works in those two modes.
Serial monitor closed. no jamming, but also no RC passthrough in either mode.
Needless to say, RC works fine in manual mode.
This very much sounds to me like a timing issue.
What variables would you like me to Serial.print to help you diagnose?
-
4
-
5
-
6
-
7
-
8
of 9 Next