Build Library for Pixhawk 4 - serial outputs can't be displayed

ArduPlane Plane 4.0
1

I have been successful uploading the firmware to a Pixhawk 4 using ./waf and connecting to Mission Planner. Now I was following the tutorial on the wiki explaining how to build an example library and I haven’t been able to get that to work right

I run the commands in a windows linux terminal:
$ ./waf configure --board=Pixhawk4
$ ./waf build --target examples/INS_generic --upload

and the build seems to execute successfully and ends with the output

Build commands will be stored in build/Pixhawk4/compile_commands.json
‘build’ finished successfully (3m39.033s)

However, when I try to connect to a serial terminal on PuTTY (COM9, 57600) to view the output it fails to connect. I have also tried mavproxy with the command

$ mavproxy.py --master=/dev/ttyS1 --baudrate 57600 --setup

and the output that I get is

Connect /dev/ttyS1 source_system=255
Log Directory:
Telemetry log: mav.tlog

and no other output, not the output of the library that I was expecting. Additionally, in case its relevant, when I try to run

$ mavproxy.py --master=/dev/ttyS1

I get the output

Connect /dev/ttyS1 source_system=255
Log Directory:
Telemetry log: mav.tlog
Waiting for heartbeat from /dev/ttyS1
MAV> link 1 down

MAV>

Doesn’t seem like that is working either. Any ideas what I am doing wrong? Thanks

2

That example does not output MAVLink data. It outputs plain text over serial. You’ll need to connect via a serial console instead.

Something like Putty would work under Windows.

3

Thats what I would have thought as well, however when I try to connect to to the serial port with PuTTY (COM9, 57600), it fails to connect. Am I missing a driver or something? Have you gotten the example library to work with a Pixhawk 4?

4

Please see the video of the process I go through to build the example and then how the serial terminal won’t open after that.

Screen Capture Video

Is there anything wrong with what I am doing? Thanks for any help

5

I’ve tried the examples/INS_generic on both my KakuteF4 and Pixhawk2 - both exhibit the same issue of rebooting every 5 seconds or so.

Building and running SITL works OK though.

Maybe a buildchain or HAL issue? … will keep investigating.

6

Ya thats what I am thinking. We actually got some serial output on a friends computer, although that hasn’t been repeatable. It could be a driver issue since I had been experimenting with Dronecode PX4 before Arduplane and I might just need to clean up my computer some. Either way I have got some long hours ahead of me figuring this one out

7

So, I’ve managed to fix this issue: https://github.com/ArduPilot/ardupilot/pull/12802

@sdeal3 - I’d be interested if this solves your issues

8

Awesome, thanks @stephendade ! I will test these changes out soon.

I was also able to make some progress with the issue myself. I was able to get the example/UART_test sketch to work on the pixhawk4 if I make the delays small (<100ms) and also had it print to the other auxiliary uarts. Strangely, the uart that came through the usb to the serial terminal on my computer was uartH. I also tried it on the pixhawk4 mini and uartG came from the usb. This was strange, as I thought it was supposed to be uartA coming over the usb to the terminal. I then thought I could get uartA perhaps though the debug port, and I think I accidentally fried my pixhawk4 in the process. Then I was motivated to test the mRo pixhawk1 and when I uploaded the same modified example/UART_test sketch, I got uartA and the consol printing in the serial terminal. I’m still not sure what was going on exactly since I fried the pixhawk4, but definitely still more testing is in the works. I then tried a more advanced sketch, the example/INS_generic sketch, and that one has yet to work on the mRo pixhawk1, and I have not tried it on the pixhawk4 mini because the consol is not yet printing on that one, just uartG.

Sorry its a lot, but I have been working on this for a while. I want to get working on some more technical controls implementations soon, so I am sure there will be more challenges to get ready for.

9

Just tested out the changes that @stephendade made. They did seem to fix the main issue that I was having with running the UART_test example. One weird thing that seems to be going on is that on the mRo Pixhawk1, it serial prints through the USB with uartA, while the Pixhawk4 mini prints through the USB with uartG and the Pixhawk4 prints through the USB with uartH. Seems like maybe a configuration and definition issue between the boards, so not sure what is going on there. The serial data does seem to be coming reliably now though. Thanks