RPI Demo ./runBoth.sh

[aaronbuchwald]

I am having an issue running the runBoth.sh file after compiling the RPI demo.

I have made the RPI demo successfully, and am now trying to run the script runBoth.sh in the RPI directory. However, this is giving me the following error:

./scripts/run_pi.sh: 31: ./scripts/run_pi.sh: Syntax error: end of file unexpected (expected "fi")

And then the program just hangs and does not terminate. I looked at the run_pi.sh file and could not find the problem. Any ideas what I should do to fix the script or if I may have installed something incorrectly setting up?

[aaronbuchwald]

I found that this could be fixed because the if then statement was using the wrong syntax for the type of shell script I was running. After I changed the syntax of the if then statement, I am getting the error that the setenv command cannot be found. I found that this could be caused by using sh instead of csh, which I do not have installed and had not assumed I was meant to use.

Should I change to running csh instead of sh and is this the case throughout the use of fprime? It seems that this might be the cause of many of the syntax issues I've been having.

[LeStarch]

You should update to the devel branch of nasa's github repository. The "runBoth.sh" script for the RPI is now removed.

[LeStarch]

See: #38

[LeStarch]

On the devel branch, you should manually run "RPI/scripts/run_rpi_cross.sh" and manually run the RPI image.

[aaronbuchwald]

Should I be running run_rpi_cross.sh on a linux machine to run the GUI and manually running RPI on the RPI in order to launch the app itself?

I tried running both of these on the RPI. The RPI image fails because of two assert errors in file Drv/LinuxGpioDriver/LinuxGpioDriverComponentImpl.cpp (line 263)
and the file RPI/RpiDemo/RpiDemoComponentAc.cpp (line 2933).

I assume I'm not meant to run run_rpi_cross.sh directly on the raspberry pi, but I tried anyways to see if it might work. It results in the error that there is no module named Pmw.

Is it supposed to work if I run it directly on the RPI or do I need to cross compile from my machine and just run the binary on the RPI?

Also, in order to run from a linux machine and cross compile it is it required to set up port forwarding on the raspberry pi, the linux machine, both, or just make sure that both are using the same port?

[timcanham]

I have been able to run the GUI on the Pi, but it isn't reliable so I've switched to running it on a Linux machine and connecting from the Pi. You should run it as sudo on the Pi to get around the driver open() asserts.

[timcanham]

BTW, you will have to modify the addresses in the script to match your network.

[aaronbuchwald]

DIRNAME="dirname $0"
if [ -z ${BUILD_ROOT} ]
then
export BUILD_ROOT="cd ${DIRNAME}/../..; pwd"
fi
DEPLOY=cd ${DIRNAME}/..; pwd;
${BUILD_ROOT}/Gds/bin/run_deployment.sh --deploy "${DEPLOY}" --no-app "$@"

This is the run_rpi_cross.sh script, but I'm not sure where to modify the address in this script. Which files should I be modifying the addresses in?

[LeStarch]

Just pass in the arguments:

./run_rpi_cross.sh -a 127.0.0.1 -p 50000

Where 127.0.0.1 can be replaced with the IP of the host running the ground system, and 50000 replaced with the port the ground system is running on.

[LeStarch]

So typically your network looks something like this (IPs are invented):

Laptop with ground station: 192.168.1.101
RPI running APP: 192.168.1.102

Running Ground Station on Laptop

cd fprime/RPI
./scripts/run_rpi_cross.sh

Note: this defaults the address and port for you.

Running on PI

cd <location of compiled executable, uploaded to pi>
./RPI -a 192.168.1.101 -p 50000

Note: here we supply the IP of the laptop, and the default port 50000.

The RPI can do both jobs, but I would recommend you run it using 2 terminals as above. That way when you split to hardware and ground station, you are following the same process.

[aaronbuchwald]

Thank you, the GUI wouldn't run on the RPI but I got it to run on VirtualBox and connected to the raspberry pi.

Once I exited both programs I tried to reconnect and it sometimes gives me different errors.

First, every time I run the GUI (including successfully) it gives me the error:
Could not import WX GUI: : No module named wx.
Since it works anyways, would it be possible to remove this so that there are no warnings?

Also, sometimes when the GUI is booting it gives me the error that it failed to start the TCP server. It logs that it's waiting 5 seconds for it to start, so is it just failing every time that this times out?

Lastly, on the RPi, it sometimes gives me the error that it is being denied permission to open one of the GPIO files, but after a few more tries it rebooted again and started working. Do you think this is just an issue with the way that the program exits when it gets shut down and nothing to worry about?

[LeStarch]

The gui supports a "tk" mode and a "wx" mode. It will Warn when it cannot import those modules. In your case, you are running with "tk" and it cannot find "wx" so you are ok.

As for the TCPServer, if running on linux, the TCP socket used will enter WAIT2 state for 60 seconds after you shut down the application. This is Linux's way to prevent late messages from arriving into a restarted session. You'll need to wait 60 seconds between closing the TCP server and running a new instance.

I'd have to dig deeper into the RPI issue. @timcanham any thoughts as to why the RPI is holding on to the GPIO files?

[timcanham]

I know the best way to run RPI is as root as there can be issues opening the files that correspond to the drivers. I don't know what the delay issue might be, but I would see if it still happens when you run the RPI binary as sudo.

[aaronbuchwald]

The delay issue seems to be a deeper problem, I kept having this problem, so I waited a full 3 minutes before trying to run again and it doesn't seem to matter. I keep getting the same issue that the TCP server fails to start. I tried restarting my VM and it still gives me the same error on the first try. Is there anything else I can try?

[LeStarch]

Yes. In your RPI dirctory, there are logs for this server:

RPI/logs/<some date>/ThreadedTCP.log

This will contain the error for the server. Post the error here, and I can give you more advice. Here, some data is the date time of the last run.

[LeStarch]

Also, #53 will automatically print the log if an error occurs, exposing better errors to the user.

[aaronbuchwald]

Thanks Michael, the log file is giving me error(99, 'Cannot assign requested address')

I assume this means that there is a problem making the connection to the raspberry pi?

[LeStarch]

@aaronbuchwald this error typically means an issue grabbing the IP address that you have requested this run on. The ground system acts as a server, meaning it must listen on an address and port combination. If the address you request is not available to the computer you are running on, the above error is the result.

The default address is 0.0.0.0 as that will listen on any address the computer is assigned to, and just grab a port.

Therefore, I'll need to know the exact CLI you are running to start this. If it is exactly the below command, then do you have user permissions to listen to an internet port?

Is this what you are running?

./scripts/run_rpi_cross.sh

[brh68]

When I try to run the executable RPI on the rpi, I get this error:

[timcanham]

@brh68 Did you configure the RPI with the various I/O lines? Also, you should run as sudo.

[brh68]

I'm not exactly sure what you mean. It seems like there might be something wrong because my configuration screen has a lot fewer options, and I'm not sure how you had Serial enabled because it gets disabled when you disable uart through command line. Also, I have been using sudo.

Also, I'm not sure how the wiring is supposed to look:

[LeStarch]

You should enable that last serial checkbox too.

[brh68]

I originally had Serial enabled, but when I disabled UART it disables serial, if I re-enable serial it undoes the deletion I made to disable UART.

[brh68]

Where does m_fd come from? What is it checking is enabled?

[timcanham]

this->m_fd is set during the open() call. The FW_ASSERT is put in this function to make sure you didn't forget to call open().

[brh68]

That doesn't really make sense because we are running fresh downloads of the RPI release, and these errors only happen on some of the raspberry pies. I think it is related to out lack of a dev/serial0, but we can't figure out how to fix this.

[timcanham]

Ah - are you running with sudo?

[brh68]

Yeah, running without it ends in a segmentation fault, whereas we end with the program Exiting

[brh68]

I removed the RPIDemo component from our application because we use a different method of accessing gpio pins that works with our current settings, but I am getting a failure of this assert:

It looks like the command registration port is not hooked up correctly, but I'm not sure how its wrong. Here is the repository: https://github.com/brh68/Cislunar-Flight-Software/tree/RPIDevel/RPI

[timcanham]

That probably means you forgot to connect the command registration port to the CmdDispatcher.

[brh68]

I forgot to define an instance of the component.

[LeStarch]

I am closing this issue, as I see no updates. Please feel free to continue discussion on our mailing list: https://groups.google.com/forum/#!forum/fprime-community

Or open a new issue if you detect a new bug.