* AeroFC: Update defconfig
defconfig generated using: make aerofc-v1_default oldconfig
* AeroFC: Disable UART8
It is not used but it share the same pinout in the FC connector with
other pin used as I2C2, so it needs to stay in high-z.
It was setting the rotation value to the I2C slave address
causing it to not be successfully probe.
Changing the constructor paramters order instead of
just fix line instantiating to keep consistency with
the other lidars and sonars.
We are running out of flash space in AeroFC so a cleanup is necessary.
Tools not used in Aero RTF, INAV, fixed wing control, vtol control and
unused libs was removed.
before
$ size build_aerofc-v1_default/src/firmware/nuttx/firmware_nuttx
text data bss dec hex filename
956880 3524 14608 975012 ee0a4 firmware_nuttx
after
$ size build_aerofc-v1_default/src/firmware/nuttx/firmware_nuttx
text data bss dec hex filename
832200 3508 14616 850324 cf994 build_aerofc-v1_default/src/firmware/nuttx/firmware_nuttx
If the second bit of COM_ARM_MIS_EXT_REQ is set the vehicle
will only arm after receive an authorization.
The authorization flow:
vehicle/external -> command: arm authorization request -> arm authorizer
vehicle <- command ack with result in progress <- arm authorizer
vehicle <- any data request <- arm authorizer
vehicle -> data response -> arm authorizer
vehicle <- command ack authorizing or denying <- arm authorizer
Right now there is 2 ways to start the arm authorization request,
that can be configured by COM_ARM_AUTH parameter.
- One arm: When pilot request the vehicle to arm, it will request
authorization blocking the arm process up to the timeout defined in
COM_ARM_AUTH parameter.
- Two arms request: The first arm request will request the
authorization and will deny the first arm request, if authorizer
approved the request, pilot can arm again within the authorized
time and arm without any block.
The arm authorizer can be running anywhere(compute board or PX4
itself) and it is responsible to request the mission list or any
other information to vehicle before send a final response, it
should send to vehicle a COMMAND_ACK with
result = MAV_RESULT_IN_PROGRESS as soon as it receive the arm
authorization request and the final result
as after it got all the data that it needs authorize or deny the
request.
If 2 or more vehicle_command are queued a call to update() will
return the oldest vehicle_command and set the _cmd_time to the
timestamp of the last vehicle_command queued losing it.
Using update_if_changed() fix this causing all item being consumed
one at each call of send().
Instead of having several bools to each requirement to arm, lets group then
in a byte and use bitmask.
This also add a new arm requirement "arm authorization" that
will be implemented in another patch.
This will initialize those structs with zero in all fields not set
and all fields set will only be change once to the final value not
wasting CPU time zeroing it.
This will guarantee that no non-unitialized structs will have
a trash value on from_external causing it to be sent to the
MAVLink channel without need it.
The previous approach was checking system id and component id but it
will not work in 100% of cases as external devices can send MAVLink
message with the right system id but with broadcast component id.
This change plus the new FPGA RTL(version 0xC1 or higher) will make
use of the new I2C bus, this new bus will be shared between aerofc_adc
and ll40ls(if connected) and leaving the old bus just to IST8310.
The UART3 also have the I2C bus 2 functions so moving GPS to UART7 to
have one additional I2C.
To keep GPS working is also necessary update the FPGA RTL to version
0xC1 or higher.
This can help "unbrick" AeroFC when a bad firmware is loaded
and it keeps rebooting or it spinning in some loop.
No need to request to stay in booloader as it will stay
in bootloader because the pin is set.
Use the size of each item type instead of the biggest one.
In AeroFC that runs is constrained mode it was using 7860 bytes
and now it uses 6930 bytes almost 1KB less.
This backend will keep all updated data in RAM and
persist the data between reboots using flash memory.
Using only flash memory would result in a slow backend that
would decrease the lifetime of the flash memory, using both
we can reduce the several cycles of erase & write into flash
and keep the performance of the backend almost as fast
as the RAM only backend.
Note: Do not use this backend on a sector from the same flash memory
bank as the memory bank that STM32 read instructions or it can block
the CPU from fetching instructions from flash during the erase and
write operations and cause your drone crash.
The maximum number of missions was increased in almost 8 times in
recent commit: 9369262e63 navigator: allow more mission items.
As this board loads missions in RAM, now it don't have enough memory
to allocate causing dataman start to fail, so mark it as a memory
constrained system and reduce the number of maximum missions
supported.
This board don't have a SDCard to save crash dumps and it was causing
the board to get stuck into '[boot] There were %d reboots with Hard
fault that were not committed to disk - System halted', until user
connect to the serial console and clear the fault.
Measure the battery voltage of Aero RTF kit will be done by FPGA
and read by AeroFC using I2C bus.
The protocol is a little bit odd, it have different I2C slave
address for each "register", in future the FPGA RTL will
have a protocol more similar to other I2C sensors.
Also Aero RTF don't have a ADC line to measure current consumption.
This way user can set aftwards any other AUTOSTART value and it will
not be overwritten.
Also move the block up and set SYS_AUTOCONFIG, this way if air frame
configuration was reset in ground station it will wipe the parameters
before load new ones.
AeroFC is updated by Aero board using the UART between AeroFC
and Aero board.
This script will copy firmware and px_uploader.py to Aero board and run
px_uploader.py with the correct paremeters. User only needs to have a
network connection (Ethernet over USB or WiFi) with Aero board to update
AeroFC firmware. The IP/hostname can be given by AERO_HOSTNAME
environment variable.
As ASC use a non-standard UART for mavlink it is necessary check for
the board name and set SYS_AUTOSTART to initialize mavlink on the
right interface otherwise there is no way to change the SYS_AUTOSTART.
By default the baudrate in flight stack (Mavlink or NSH) 57600 and the default
baudrate of bootloader is 115200. So we may need to set different
baudrates.
The Mavlink reboot messages was only requesting the board to reboot.
If the flashed bootloader has a small or no timeout user will
never be able to update firmware.
