px4 / sapog Goto Github PK

Does Sapog have any limitations on maximum RPM command rate over UAVCAN?

In the PX4 Firmware, there is a hardcoded 200 Hz limit in the uavcan code. I am able to send commands at around 500 Hz to four Kotleta20 ESCs, but when I attempt to send RPM commands at 1000 Hz, the ESCs will reboot after about 10 seconds of operation. After reboot, they work again for about 10 seconds, then reboot again. Occasionally, only one of the four ESCs on my quadrotor will reboot.

Is there a maximum rate at which Sapog can handle incoming commands without rebooting?

I want to learn ChibiOS, and “sapog” is a very good example. I want to use USART2, but I can't determine which pin USART2 is on. The data sheet of STM32F105 shows that PA2, PA3, PD5, PD6 can be used for USART2. I think there should be a file that specifies the mapping between pins and USART2. But I am not sure what I think is right.

@bendyer @davids5 We currently have only 8K reserved for the bootloader, which is enough for now but precludes future growth. I suggest to reserve 16K of flash for the bootloader instead - this will enable us to possibly add USB bootloader or some other feature in the future, if the need arises.

When I am compiling the main binary using the make command I get the following error

Linking build/io.px4.sapog.elf
collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped
compilation terminated.

I am using gcc version
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)
and ld version
GNU ld (GNU Binutils for Ubuntu) 2.26.1

How could I fix the problem?
Thanks

For example:
now: zubax_chibios//_rules_armcm.mk:35:*** USE_PROCESS_STACKSIZE is not defined. Stop it.

Detect if the temperature sensor is present on boot; continue without it if it's not responding.

I design hardware and am not really a software person. I noticed that in the sapog chibos it has code for the f4 series. How compatible is that? Do you know if there is a plug and play stm32f40x?

Number of setpoints received, number of CAN errors, etc.

I've noticed that in the PX4 logs of the sapog motor driver firmware, the esc_rpm and esc_setpoint_raw seem to be off by some set factor.

Does anyone know why that might be?

This prompt error makes me feel confused, I don't know how to solve this problem, my toolchain is GCC ARM 4.9.3

https://forum.uavcan.org/t/uavcan-2019-roadmap/666

At least one Python 3 syntax error remains...

./tools/benchmark/make_plots.py:36:43: E999 SyntaxError: invalid syntax
        filt_with_indices = filter(lambda (index, value): keep_indices[index], enumerate(value))
                                          ^

Is there a test case around this code?

A simple fix would be to remove the parens around (index, value) but that works sometimes and not others so a strong test case is needed. In general, modern Python used list comprehensions instead of filter() and map() especially when used with lambdas.

https://docs.python.org/3/whatsnew/3.0.html#views-and-iterators-instead-of-lists

Hello folks,

I would like to know if the motor inversion option is available during flight with UAVCAN Protocol, so we can change the motor rotation mid-flight.

Thank you in advance!

Depends on #42

Per implied request from https://groups.google.com/d/msg/px4users/BaG4qbckOEs/oCtUR9dngGEJ.

Hi
I'm unable to checkout the ChibiOS submodule. Is it private or did they rename/move the repo?
Their SVN mirror is here: https://github.com/ChibiOS/ChibiOS-gitmain but I have of course no clue which commit to use :)
Cheers
Ada

Hi, px4 community!

For my thruster that based on sapog software mid-flight rotation change is very important.
I have noticed that this feature was added in December of 2016 #10 , but I cannot find any sign of it in the repository.

Few months later according to issue #12 you decided to rollback the repository to some previous version.
Is it possible that this added feature was missed during the migration?

Parameter name length must not exceed 16 characters because of MAVLink v1 limitations.

When I compile the main binary using the make command the following error comes up

build/obj/crt0_v7m.o: In function `endinitloop':
(.text+0x74): undefined reference to `main'
collect2: error: ld returned 1 exit status

I am using the gcc version 4.9:
gcc version 4.9.3 20150529 (release) [ARM/embedded-4_9-branch revision 227977] (GNU Tools for ARM Embedded Processors)

how can i fix this problem?

Are there plans for Sapog to support faster telemetry? It seems to be limited to 10 Hz at the moment and it would be nice to receive perceived RPMs at a faster rate.

Is there any reason why faster telemetry would be a problem?

As soon as we move from ESC developers to autopilot developers for testing, updating the ESC firmware will become painful (in particular if they are mounted in vehicles). We should bundle the ESC firmware in the autopilot flash (we're doing this already for PX4IO) and bootload all ESCs via CAN if the CRC of their FW (which they provide on request) differs from the autopilot's FW version. This also ensures compatibility.

@dagar
I have issues with the Mixas ESC, I already followed all instruction by @mhkabir for the configuration of the ESC, the assignment and the rotation of motors it's right and the copter doesn't fly, only flips on the takeoff. This is the configuration of the ESC #1


The other ESC have the same configuration only change the assignment on the esc_index the ESC#2 =1, ESC#3=2 and ESC#4=3.
What could be wrong?

Together with a PWM_DEAD_TIME_NANOSEC=750, the FETs run at about 45°C @ 80% power for a minute. Unfortunately the DEAD_TIME seems to be quite on the edge, sometimes the boot of the ESC fails with the following error messages (LED red, low freq beep):

UAVCAN: CAN bitrate 1000000 bps
UAVCAN: Node started, ID 10
Motor: Power stage test...
Motor: Selftest phase 0: low 6, high 2603
Motor: Selftest phase 1: low 6, high 1171
Motor: Selftest phase 2: low 6, high 2597
Motor: Selftest FAILURE at phase 1: sample 1171 is far from median 2597
Motor: Power stage test...
Motor: Selftest phase 0: low 7, high 2604
Motor: Selftest phase 1: low 6, high 2595
Motor: Selftest phase 2: low 6, high 2597
Motor: Cross phase test...
Motor: Phase 0 cross conductivity: 2603 2630 2642
Motor: Phase 1 cross conductivity: 1177 1170 1173
Motor: Phase 2 cross conductivity: 1086 1080 1083
Motor: All phases are shorted, assuming the motor is connected
Motor: Sensors test...
Motor: Raw input voltage 2373, raw input current 487
Hardware OK
Motor OK

The issue is most likely caused by poorly chosen duty cycle that prevents the high side FET driver cap from recharging: https://github.com/pavel-kirienko/px4esc/blob/master/firmware/src/motor/realtime/motor_pwm.c#L365.

As I have indicated earlier, I want to rename this project in order to avoid confusion with FOC-enabled PX4ESC. The current name px4esc-bldc is not a good choice as it doesn't reflect the idea of the project.

The master branch of this repository will be rolled back to the point where the branch pixhawk_esc_1.4 has been created, and then the latter will become the new master. Pixhawk ESC v1.4 will become the official reference hardware design (although a few fixes won't hurt as long as they don't affect backward compatibility).

@LorenzMeier any feedback?

[Feature request]Add support DSHOT signal input.

Ubuntu 14.04.3 LTS
Toolchain per http://dev.px4.io/starting-installing-linux.html (NuttX based hardware)
Build per: http://dev.px4.io/uavcan-node-firmware.html (PX4 ESC Codebase (Pixhawk ESC 1.4))

Pixhawk firmwares and Pixhawk ESC 1.6 compile successfully on same machine.

Summary::

Build fails with [Unable to checkout 'e7a5b54dee336bb632b9b767e2001103c65a33ee' in submodule path 'firmware/chibios'] error, specifically:
fatal: reference is not a tree: e7a5b54dee336bb632b9b767e2001103c65a33ee

https://github.com/Zubax/ChibiOS/tree/e7a5b54dee336bb632b9b767e2001103c65a33ee throws a 404 error.

Terminal:

geo@geo-Latitude-E6530:/src$ git clone https://github.com/PX4/px4esc.git
Cloning into 'px4esc'...
remote: Counting objects: 2964, done.
remote: Total 2964 (delta 0), reused 0 (delta 0), pack-reused 2964
Receiving objects: 100% (2964/2964), 993.18 KiB | 1.14 MiB/s, done.
Resolving deltas: 100% (2095/2095), done.
Checking connectivity... done.
geo@geo-Latitude-E6530:/src$ cd px4esc
geo@geo-Latitude-E6530:/src/px4esc$ git submodule update --init --recursive
Submodule 'firmware/chibios' (https://github.com/Zubax/ChibiOS) registered for path 'firmware/chibios'
Submodule 'firmware/uavcan' (https://github.com/UAVCAN/uavcan) registered for path 'firmware/uavcan'
Cloning into 'firmware/chibios'...
remote: Counting objects: 101032, done.
remote: Total 101032 (delta 0), reused 0 (delta 0), pack-reused 101032
Receiving objects: 100% (101032/101032), 37.13 MiB | 1.18 MiB/s, done.
Resolving deltas: 100% (80130/80130), done.
Checking connectivity... done.
fatal: reference is not a tree: e7a5b54dee336bb632b9b767e2001103c65a33ee
Cloning into 'firmware/uavcan'...
remote: Counting objects: 16540, done.
remote: Total 16540 (delta 0), reused 0 (delta 0), pack-reused 16540
Receiving objects: 100% (16540/16540), 2.66 MiB | 1.30 MiB/s, done.
Resolving deltas: 100% (11188/11188), done.
Checking connectivity... done.
Submodule path 'firmware/uavcan': checked out '6dd432c9742c22e1dd1638c7f91cf937e4bdb2f1'
Unable to checkout 'e7a5b54dee336bb632b9b767e2001103c65a33ee' in submodule path 'firmware/chibios'
geo@geo-Latitude-E6530:/src/px4esc$ cd firmware
geo@geo-Latitude-E6530:/src/px4esc/firmware$ make RELEASE=1
Running from the source directory
Makefile:87: chibios/os/hal/platforms/STM32F4xx/platform.mk: No such file or directory
Makefile:88: chibios/os/hal/hal.mk: No such file or directory
Makefile:89: chibios/os/ports/GCC/ARMCMx/STM32F2xx/port.mk: No such file or directory
Makefile:90: chibios/os/kernel/kernel.mk: No such file or directory
Makefile:91: chibios/os/various/cpp_wrappers/kernel.mk: No such file or directory
Makefile:168: chibios/os/ports/GCC/ARMCMx/rules.mk: No such file or directory
make: *** No rule to make target `chibios/os/ports/GCC/ARMCMx/rules.mk'. Stop.
geo@geo-Latitude-E6530:/src/px4esc/firmware$

Hello!I build sapog development environment encountered many problems, can you give me a detail development environment development steps.thank you!

The current measured and published by the PX4ESC seems to be affected by heavy offset and scale errors. I measured the current via SM Unilog and compared the results to the ones printed by "stat" on the serial console.

Unilog -> stat output
0.00A -> 0A
0.14A -> 1.58A
0.20A -> 1.61A
0.50A -> 1.64A
1.00A -> 2.17A
2.00A -> 3.07A
3.00A -> 3.86A
4.00A -> 4,75A
5.00A -> 5.52A
5.90A -> 6.12A

These results are not really in line with the numbers stated for common mode voltage offset and linearity errors stated in the datasheet of the current monitor circuit. Especially the heavy error in the 2..4A range is rather nasty, as a lot of copters hover in this region.

I would like to propose a button-less and very easy (from the customer perspective) motor detection approach:

• Send a command to all units on the bus (broadcast) to reconfigure. This means resetting their address / state (not to zero, but to "unconfigured") so that an aborted config should result in a refusal to spin.
• for i=0..N: Send "detect motor #N" as broadcast. All unconfigured motors enter detection mode (which times out after ZZ seconds)
• The user then turns the motor. The user is instructed to start with a specific motor and follow a specific order. It gets visual feedback about which motor was detected and which ones still need handling. The next motor to handle is indicated visually in the GUI. By comparing the GUI and the frame he will also notice mismappings and is able to fix them.
• The motor beeps upon detection of the turn and changes its LED indication from unconfigured to standby.

On the technical side this needs a reconfigure and configure motor #N packet via CAN and the back-EMF detection.