AP_Periph 1.0.0 stable released

[palm369 (David Kaden)]

That question was related to the “heading from GPS”

[tridge]

ahh, sorry. That will work only for u-blox F9 GPS modules, or NMEA GPS modules that can provide yaw.

[tridge]

@Matt_C

Also note the Mrobotics has just released the above node and it is available for preorder and should ship within a week

great, the f303 is a nice improvement, and you should get one if you can.

@Matt_C

Have used a few of these but seem to have some trouble when trying to update to a different firmware seems as though MP won’t open the slcan.

tridge:

@hwurzburg is working on documenting how to use the SLCAN mode in MissionPlanner for this. It is a bit tricky.

[pkocmoud (Phillip Kocmoud)]

I also sent a PM to help him. I have helped a few others that had old bootloaders and pre-stable firmware. Anyone else with CANNode issues feel free to reach out to me.

[hwurzburg (Henry Wurzburg aka ATXHELI)]

Thanks…it appreciated

[tridge]

@Matt_C

would the RTK support also work on emlid products (ERB) or is it specifically tied to the new F9P unit mrobotics has come out with

You can do RTK with any RTK capable u-blox. The new moving baseline support will need a F9P however.

@Matt_C

these range finders work on the I2C bus when connected via that but not on the I2C bus of the can node

that is odd. Did you set the RNFND_TYPE via the CAN parameters? Do you happen to own a logic analyser so you can look at the I2C traffic?

@Matt_C

I also have major issues getting more than one range finder to work even when changing the address so each have their own.

do you mean two rangefinders on one CAN node, or two CAN nodes? We don’t support two on one node yet

[Mallikarjun_SE]

Hey @tridge
I was thinking to use F0 processor with lower flash for AP_Periph for fixed sensors with less than 5 sensor type count. I was thinking to remove all the sensor drivers which are not required and reduce flash requirement for F0. what do you suggest? And I also want to know insights on removing code and consequences of it.
Thank you.

[tridge]

@Mallikarjun_SE

I was thinking to use F0 processor with lower flash for AP_Periph for fixed sensors with less than 5 sensor type count.

you won’t fit the AP_HAL into a F0. I deliberately chose to use a larger flash footprint so we can share common code with the rest of ArduPilot. We’d lose that with the F0

[ThePara (Cornel Fudulu)]

Sorry to disturb the thread, but I have a question I have nowhere else to ask.
If, for instance, the CAN controller has three available analog pins to drive the R, G and B of a LED, a specific driver has to be written to tackle that, as opposed to having a ToshibaLED driver on I2C or a NeoPixel and making use of AP drivers ?

I’m not comfortable and I don’t have insight with code. I’m just dealing with hardware.
I’ve appropriated some DJI GPSes, soldered out all CAN stuff and used them in I2C/serial mode. And now I’m thinking of reprogramming the CAN part for AP.

[tridge]

@ThePara

the CAN controller has three available analog pins to drive the R, G and B of a LED

you shouldn’t use analogs to drive LEDs, you should use GPIOs (unless you want variable intensity, in which case you use timers and a duty cycle)

@ThePara

a specific driver has to be written to tackle that, as opposed to having a ToshibaLED driver on I2C or a NeoPixel and making use of AP drivers ?

you can use the existing board LED driver. For 3 LEDs the pixracer LED driver is a good choice.

@ThePara

I’ve appropriated some DJI GPSes, soldered out all CAN stuff and used them in I2C/serial mode. And now I’m thinking of reprogramming the CAN part for AP.

nice! What MCU is on the GPS for CAN?

[ThePara (Cornel Fudulu)]

@tridge

What MCU is on the GPS for CAN?

DJI being DJI, they laser-erase all the markings on their MCUs. I’ll have to study the pinout to search for a match. But their RF approach feeding the classic NEO-M8N is superb, and given that M9N is a drop-in replacement, it makes them better, still.
I have been at the receiving end of I2C storms caused by QMC5883 mag clones, directly connected to FC MCU. How would they translate over a CAN connection ? Because all A2 GPS units I’ve seen so far had the original Honywell mag, while the A3 units had the clones.

[smartdave (Dave Glover)]

@tridge Have you done any work getting a CAN Baro working? I have one in my CUAV NEO V2 Pro CAN GPS that I would like to see if I can get working, also in my Zubaks GNSS 2

[tridge]

@smartdave

Have you done any work getting a CAN Baro working? I have one in my CUAV NEO V2 Pro CAN GPS that I would like to see if I can get working, also in my Zubaks GNSS 2

My NeoV2Pro arrived today too. The baro is already supported, but is disabled by default.
You need to use either uavcan_gui_tool or MissionPlanner to change the BARO_ENABLE parameter on the GPS to 1 and then restart.

More information here:
https://ardupilot.org/copter/docs/common-slcan-f7h7.html
https://ardupilot.org/copter/docs/common-mp-slcan.html

It is so nice to receive this GPS! I had a prototype that I developed the support on some time ago but really nice to see the real thing. The little light show on boot looks nice

[tridge]

@Matt_C

Can you confirm that RTK GPS and rangefinders work

RTK GPS works if you have a recent ArduPilot firmware and recent AP_Periph firmware. Both need to be recent (eg. current stable copter or plane) as the Fix2 UAVCAN message is needed for RTK GPS and support for Fix2 was added for 4.0.
For rangefinders we support both I2C and serial rangefinders. I’ve just spent the last 20 mins digging around on my desk for a rangefinder to test and confirm. I did find a LidarLite, but I need to make up a cable for it.
Some questions:

• What vesion of AP_Periph do you have loaded?
• what version of ArduPilot are you using?
• have you setup the RNGFND1_TYPE correctly in the parameters on the AP_Periph node?

[smartdave (Dave Glover)]

Oh the red blue sequence? Yeah I like it too. I did enable the baro sensor in MP via UAVCAN

I was just wanting to make sure AP will actually use it. Everything I have read expects an external baro sensor to be on the I2C bus

[MGeo (George Small)]

Hi,
AP_Periph is great work, I’m digging in. I am a UAVCAN and CAN bus advocate and am working up the AP_Periph build learning curve. I’ve managed to successfully build and load f103-GPS and f303-GPS examples on Ubuntu 18.04, starting with bootloaders flashed to the processors via ST-Link and then using UAVCAN GUI to update the as-built firmware binary.

Below is my UAVCAN test setup. I’m running with UAVCAN GUI plugged in to the FTDI via SLCAN adapater. My node is either an STM32F103CB modified bluepill or an STM303CC blackpill board with CAN adapter breakout boards. Based on schematics (https://github.com/mRoboticsIO/CANNode/tree/master/Schematic) I believe my nodes are breadboard equivalents of the F1 and F3 mRo CAN Node variants.

I’m interested in building and documenting minimum viable F103 and F303 libcanard node examples that works with the AP_Periph bootloader. I’ve had success with this example (https://github.com/skyyuzhang/UAVCAN_NODE_FreeRTOS) as bare metal loads no bootloader. I also have STM32 Arduino variations of this demo built and tested here (https://github.com/geosmall/UAVCAN-for-STM32-Arduino).

I am now trying to understand the changes needed to get it to work with the AP_Periph bootloader. I’ve changed the linker script to relocate the flash and ram starts, and eliminated the SCV->VTOR startup code so as to keep bootloader VTOR value. The GUI lets me upload the binary just fine but the node does not start up and drops back into MAINTENANCE mode.

I can see that the bootloader does some firmware signature checks (https://github.com/ArduPilot/ardupilot/blob/141099078ce11f5ee1b78debb1ec52222c7fafc7/Tools/AP_Bootloader/AP_Bootloader.cpp#L89 and https://github.com/ArduPilot/ardupilot/blob/141099078ce11f5ee1b78debb1ec52222c7fafc7/Tools/AP_Bootloader/can.cpp#L564) so I have a bit more learning to do.

Perhaps there might also be some WAF magic in signing of the binary?

Is there any guiding info on how to create and sign a binary to work with AP_Periph bootloader? I’m close but am missing a few key details. I believe that open source AP_Periph bootloader together with simple, well documented ‘hello world’ build could greatly aid in adoption of UAVCAN.

Thanks!
George

[tridge]

thanks for sharing!

@MGeo

Is there any guiding info on how to create a binary to work with AP_Periph bootloader?

Only the AP_Periph code itself in Tools/AP_Periph, but here is a summary of what it needs:

• the signature as you found already. Details in can_check_firmware(). The app side of this is implemented in set_app_descriptor() here:
  ardupilot/Tools/ardupilotwaf/chibios.py at master · ArduPilot/ardupilot · GitHub
• signature needs to have right board ID, see APJ_BOARD_ID in hwdef.dat

Once that passes the firmware will run, but before it runs the bootloader setups up the IWDG (independent watchdog) so that if the firmware crashes the board resets. The bootloader can detect this reset and decide if it should re-run or stay in bootloader for user to try loading a new fw. It decides that based on a RTC register here:
https://github.com/ardupilot/ardupilot/blob/pr-imu-adis16470/Tools/AP_Bootloader/AP_Bootloader.cpp#L98
the app should set the RTC register after 30s of running, to tell the bootloader in the case of a watchdog that it had been running happily for 30s, in which case the bootloader will run it again. If the app had been running for less than 30s then the bootloader will stay in maintenance mode.
When in maintainence mode the bootloaders set the vendor_specific code visibile in the uavcan_gui to tell the user why it is in maintainence. The reasons are listed here:
https://github.com/ardupilot/ardupilot/blob/pr-imu-adis16470/Tools/AP_Bootloader/can.cpp#L82
and are:
enum {
FAIL_REASON_NO_APP_SIG = 10,
FAIL_REASON_BAD_LENGTH = 11,
FAIL_REASON_BAD_BOARD_ID = 12,
FAIL_REASON_BAD_CRC = 13,
FAIL_REASON_IN_UPDATE = 14,
FAIL_REASON_WATCHDOG = 15,
};
that gives you a way to know why your app is not working.
Good luck with the project, and keep us informed on how you do!
Cheers, Tridge

[tridge]

oh, I should have also mentioned that as IWDG is running the app must “pat the dog” frequently to prevent a watchdog reset.
See this function stm32_watchdog_pat():
https://github.com/ardupilot/ardupilot/blob/pr-imu-adis16470/libraries/AP_HAL_ChibiOS/hwdef/common/watchdog.c#L75
if you stop patting for 2s then you’ll get a MCU reset.

[pkocmoud (Phillip Kocmoud)]

Hi George,

I originally tried to use the Blue Pill boards to prototype, be aware that even this board pictured has a pullup resistor R6 to 3.3v on PA12 for use with the USB functionally. That may need to be removed to properly utilize CAN.

Sincerely,
Phil

[MGeo (George Small)]

Thanks Phil,

Yes I am aware of the AP-12 pull-up (4.7K on the ones I have checked). It would probably be best for me to remove that resistor, but it has not caused any trouble to date in a year or so of testing on F103 and F303 variants running the CAN bus at 1MHz. But good to keep it in mind, thanks for the info.

George