I'll preface by saying that I'm not a C++ developer. There are multiple references to APM2/2.5 support for UART2 on the forum. Most references don't seem to come to conclusion. I think we have quite a bit of flexibility on how to utilize the HW assets (great stuff). In my case I wanted to utilize custom TM and an external data recorder in addition to and OSD.
Previously I had followed the Wiki instructions on routing serial3 to the board edge connector. This also works, but doesn't allow the OSD and tailored stream to be used at the same time. On my last flight I disabled the GCS writes and used this method to collect TM. Worked great.
On the flight before that one I tailored log.pde to write custom data to flash. Again, worked great.
Utilizing UART2/Serial2 is also easy. I did not change the jumper. The mods for arduplane were this simple:
FastSerialPort1(Serial1); // GPS port
FastSerialPort2(Serial2); // Aux TM port; LDG
Serial2.begin(map_baudrate(g.serial3_baud, SERIAL3_BAUD), 128, SERIAL_BUFSIZE); // LDG
Log.pde (note this is just test code, but you get the idea)
Serial2.printf_P(PSTR("GPS ")); Serial2.printf_P(PSTR(" "));
My board edge TM port came alive and started sending data at the Serial3 rate. Hope this post is useful to someone.
Larry D. Grater
Thank you! I was looking for something just like this. Going to give this a whirl for writing out GPS data to an onboard computer, hopefully it works out.
Hi, I don't quite get it, where is Serial3 declared?
Serial3 is initialized in System.pde. I'd have to look to see where the rate is declared. In my case I wanted the serial3 rate, so I didn't bother to create a serial2 rate. You can set up as you wish.
I've been using serial2 a bunch lately to debug in HIL.
Bill makes a good point here, but there's always more than one way (for anything). I tend to agree if no testing is performed to monitor performance. The other point here is that HIL does not provide complete SW coverage. I guess that's a good general comment for any changes to APM SW.
Sorry I don't quite understand what you are getting at. I set up Serial2 at 9600 BUAD to connect to an onboard Carambola embedded linux computer, which involved soldering on RX/TX/GND wires for UART2. Everything *seems* to work perfect and it flies fine, but now your comment worries me!
Please excuse my serial communication incompetence, but are you saying that all the little delays involved with sending out data over this extra serial connection has caused flight problems for you? If so, could you elaborate on what APM problems you had / did it mess with the PID etc?
Edit: I added my serial config below as a response to Mr. Kuula.
If what he did is confusing, perhaps this can help. For ArduCopter v2.8.1, all the serial ports are declared in ArduCopter.ino (if you are using the updated file extensions) at line 140, it looks like this:
FastSerialPort0(Serial); // FTDI/console
FastSerialPort1(Serial1); // GPS port
FastSerialPort3(Serial3); // Telemetry port
You can then add 'Serial2' to do whatever you want. You will have to solder on wires to the APM board where the UART2 is, one for RX, one for TX, and one for GND.
FastSerialPort2(Serial2); // UART2 connection to MyDevice
Then go to UserCode.ino and you can read/write by doing the following:
There is also a parallel thread to this one here http://www.diydrones.com/forum/topics/setting-uart2-on-the-apm2
In it Vernon Barry makes some excellent points about serial port comms on an 8 Bit mirco-controller.
Personally, I have not made this change to my APM, so I do not have any issues. I am commenting from my experience of programming 8 bit micro-controllers. (which means low frequency, small memory devices) The biggest challenge here is that adding extra serial comms requires extra clock cycles from the processor. This will have an impact on the timing. The main firmware is tested to make sure that it works, when you make a change to main processing loop, the firmware needs to be retested. And has you have found, currently it works, but in future it may not as features change or extra features added. changes to timing are hard to test and detect.
Strangely, AFAIU setting the baud to 9600 probably has the largest impact as the data takes the longest to send, taking over the micro-controller. (somebody please correct me if this statement is wrong)
I don't want to say categorically don't do this, just helping with understanding what the impact is, so you are looking out for unexpected behaviour. And how potentially you can minimize that impact.
Hope that helps :)
This is very cool. Since you guys seem to be able to modify the APM code successfully, I'm wondering if any of you know if this method could be used to send telemetry data from my Arduino Due to the APM and then have Mission Planner display it (~ 10 extra 8-bit data items at ~ 1Hz rate). It looks llike the APM (aircraft end) may be fairly easy but what about modifying Mission Planner to display the extra data? I haven't been able to find where anyone talks about doing that in the forums yet.
It should work. Actually, ideally that's what I wanted to do as well, but I didn't want to alter the source too much as I am relatively new to this. Please reply here if you get it working!
Something tells me this is going to be a lot of work ... but still fun (or at least educational). On the Mission Planner end, it looks like there may be some "data slots" where extra telemetry could be placed such as on the items on the Status tab of the Flight Data page labeled "hilch" 1 thru 4 and rcoverridech... the text is cut off and I can't read the complete words and I have no idea what those are and am unable to find any info on them. But if one can figure out Mavlink commands, maybe they can be kidnapped and used for other purposes? I suppose the unused R/C channels could also be abducted and forced into submission ;)