Sunday, 25 May 2014

TODO

1. Ask for change throttle position of transmitter, singahobby?
2. Buy TBS bulletproof ESCs.
3. Wiring and fixing the hardware components

Thursday, 22 May 2014

Rebuilding

When changes to the source code are made, the firmware must be rebuilt. Not all changes require a full rebuild, however; several scenarios are shown below.

If changes are made remotely to the PX4 firmware or NuttX that you would like to use, first ensure that you have a clean working copy (git checkout – . or git stash save –keep-index or git commit) and then:

cd Firmware
make distclean
git pull origin master
cd NuttX
git pull origin master 
cd .. 
make archives
make

If changes are made to anything within the Firmware/nuttx folder, everything must be rebuilt:

cd Firmware
make distclean
make archives
make

If changes are made to any headers within the Firmware/src folder, NuttX does not need to be rebuilt, but clean before rebuilding the firmware:

cd Firmware
make clean
make

Changes to any other part of the source code do not require rebuilding NuttX:

cd Firmware
make upload px4fmu-v1_default

To upload the newly-built firmware to the FMU:

make upload px4fmu-v1_default

Any time two make commands follow each other, the second one can be run automatically after the first one completes successfully by adding && between the two commands on the same line. Also the -j8 flag can be added to parallelize the build across 8 cores. When combined, this command may be a useful replacement for rebuilding the archives above:

make archives && make -j8

Monday, 19 May 2014

Navigation Framework

Friday, 16 May 2014

POLL!!

POLL() is a system call in linux used to watch multiple file descriptors and see whether they can read from or write to one or more open files . These calls can also block a process until any of the file descriptors that are being waited on, become available for reading or writing.
Here BLOCKING does not mean BUSYWAITING i.e. if any process waiting for an event on a file descriptor, it will go to sleep and will be added to wait queue by kernel. It will be interrupted by kernel if any event occur otherwise there will be timeout(passed while calling POLL(), -1 as timeout value means infinite waiting). POLL() is generally used in network programming and gives very good performance, as there are no of sockets to watch there. and we can watch them all by a single call without blocking to each other .POLL() and SELECT() work in same manner, but POLL() is easy to use.

Hardware in the Loop Simulation Setup

Hardware in the Loop Simulation Setup

Connect PX4Flow to Pixhawk then to PC

Pixhawk Setup

Update the firmware on PX4Flow using QGroundControl (in the top left menu, click on CONFIG, then on Firmware Upgrade)
Connect PX4Flow UART3 to any available serial on the Pixhawk, recommended is TELEM2

Put a file /etc/extras.txt onto the microSD card, with this content:

mavlink start -d /dev/ttyS2 -b 115200 -m custom
mavlink stream -d /dev/ttyS1 -s OPTICAL_FLOW -r 2

TELEM2 is the default port, but any other serial port can be used too. Found here.

Data Output

The PX4FLOW module outputs MAVLink packets on USB and serial port. Use QGroundControl to read data from the module. An I2C interface for sensor data reading is offered as well.

USART3: MAVLink at 115200, 8N1 baud: OPTICAL_FLOW message, HEARTBEAT message
USB: Baud rate is not relevant (USB ignores it): OPTICAL_FLOW message, HEARTBEAT message, image.
I2C1 22 Byte Data Packet (send 0x0 to PX4FLOW module and receive back 22 Bytes data)

7 Bit I2C Address of the Flow Module: Default 0x42 (user selectable bits 0,1,2)

Open the Terminal Connection

Now plug in the USB cable of your adapter.

Use this shell command to start the connection (Mac OS: type 'terminal' in Finder to start the shell).

screen /dev/ttyUSB0 115200 8N1

screen: The screen program
/dev/ttyUSB0: The name of the USB to serial adapter (Mac OS: type 'ls /dev/tty.*' to see the serial ports, FTDI adapters show up as something like /dev/tty.usbserial-A7005rOd)
115200: The connection is 115200 baud
8N1: 8 data bits, no flow control, 1 stop bit

NuttX UART	PX4FMUv1 UART	PX4FMUv2 (Pixhawk) UART
/dev/ttyS0	UART1 (NSH console)	IO DEBUG (RX only)
/dev/ttyS1	UART2	TELEM1
/dev/ttyS2	UART5	TELEM2
/dev/ttyS3	UART6	GPS
/dev/ttyS4	N/A	N/A (IO link)
/dev/ttyS5	N/A	SERIAL5 (NSH console)
/dev/ttyS6	N/A	SERIAL4

How to redirect both stdout and stderr to a file

If you want to log to the same file:

command1 >> log_file 2>&1

If you want different files:

command1 >> log_file 2>> err_file

The simplest syntax to redirect both is:

command &> logfile

If you want to append to the file instead of overwrite:

command &>> logfile

What does int argc, char *argv[] mean?

argv and argc are how command line arguments are passed to main() in C and C++.

argc will be the number of strings pointed to by argv. This will (in practice) be 1 plus the number of arguments, as virtually all implementations will prepend the name of the program to the array.

The variables are named argc (argument count) and argv (argument vector) by convention, but they can be given any valid identifier: int main(int num_args, char** arg_strings) is equally valid.

They can also be omitted entirely, yielding int main(), if you do not intend to process command line arguments.

Try the following program:

#include <iostream>

int main(int argc, char** argv) {
    std::cout << "Have " << argc << " arguments:" << std::endl;
    for (int i = 0; i < argc; ++i) {
        std::cout << argv[i] << std::endl;
    }
}

Running it with ./test a1 b2 c3 will output

Have 4 arguments:
./test
a1
b2
c3

http://stackoverflow.com/questions/3024197/what-does-int-argc-char-argv-mean

Monday, 12 May 2014

Task for Monday

Research On OSD.
Shock Absorber.
Familarise with QgroundControl

http://pixhawk.org/users/first_steps

Guidelines to follow to set up hardware & Qgroundcontrol - Jiale
Can't arm my Pixhawk with PX4 flight stack

Research on overriding control / PX4FLOW

commander (Application)

PX4's Blog

PX4IOAR - PX4FLOW Setup

PX4Flow on the PX4IO (flow to pixhawk to Qgc)

PX4 multirotor flight with position controller (video, logs)

Friday, 9 May 2014

Study the first program

__EXPORT int px4_simple_app_main(int argc, char *argv[]);

__EXPORT can be found in visibility.h

#ifdef __EXPORT
#  undef __EXPORT
#endif
#define __EXPORT __attribute__ ((visibility ("default")))

"The keyword __attribute__ allows you to specify special attributes when making a declaration. This keyword is followed by an attribute specification inside double parentheses. "

int sensor_sub_fd = orb_subscribe(ORB_ID(sensor_combined));

sensor_combined is a structure, containing "Sensor readings in raw and SI-unit form";

ORB_ID Generates a pointer to the uORB metadata structure for a given topic. The topic must have been declared previously in scope with ORB_DECLARE().

API

Software API

The API documentation covers the embedded (computer vision, position control), flight (sensor readout, attitude control), blmc (brushless motor controller) and qgroundcontrol (user interface)

The different code parts are documented on these real-time doxygen generated APIDOCS:

http://pixhawk.ethz.ch/api/qgroundcontrol/ – Groundstation code Base
http://pixhawk.ethz.ch/api/ai_vision/ – Computer vision and position control
http://pixhawk.ethz.ch/api/imu_autopilot/ – IMU/Flight board (ARM MCU) code Base

Further Information

How to run our software and a general overview of the software architecture is documented in the project wiki pages.

Doing "make" command in the PX4 console is not necessary, I suppose.
As for the github, follow the steps in the following link: http://pixhawk.org/dev/px4_simple_app

MDP 5+1