Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Mixer Issue: Mixer Files Still Not Always Loading Properly #8975

Closed
blarfo opened this issue Feb 27, 2018 · 8 comments
Closed

Mixer Issue: Mixer Files Still Not Always Loading Properly #8975

blarfo opened this issue Feb 27, 2018 · 8 comments
Assignees
@LorenzMeier
Labels
Admin: Wont fix
Milestone
Release v1.10.0

Comments

@blarfo
Copy link

blarfo commented Feb 27, 2018 •
edited by AuterionWrikeBot
Loading

Greetings,

I was wondering if anyone was aware of on going issues with the mixer files not loading correctly all the time? I have attached the simplest example of a mixer which has been causing me issues. There have been serveral versions which have caused problems for me.

Configuration Notes:
Hardware : Pixhawk 2.1
Target: px4fmu-v3_default ( Pretty sure this issue was also present with v2_default )
Software Version: 1.7.3 ( I have not attempted this with the master although I doubt anything in px4io has changed much)

I spent some time looking into what the root cause was but was not able to get a warm fuzzy that the crux of the issue had been addressed. A previous solution involved adding a mixer.h file (px4iofirmware module) with a constant defined "PX4IO_MAX_MIXER_LENGHT" and a magic value was selected of 230.

In a mixer.cpp it is indicated that it is an array size large enough to hold one mixer but, I believe the issue stems from the fact that perhaps you will not always receive just one mixer (for some reason TBD).

As a temporary work around I increased the size to 512 (PX4IO_MAX_MIXER_LENGHT). I really feel as though this is addressing a symptom and not the problem.

If the specific mixes were moved to either the main.mix or aux.mix the problem followed. In order to get the last 2 mixes to load properly: they could only contain 2 scalers each.

If I loaded the second to last with 4 scales, I could get the last mix to load if I only put in 1 scale. Any additional scalers for the last mix resulted in it not being loaded.

px4io status did not appear to indicate any errors and neither did the bootlog.txt, so it is as though it silently fails.

I came across #5924 and #6226 and that is what pointed me to increasing the array size for mixer text. I am unsure how the text is passed to the parser, chasing down that rabbit hole somehow lead me to i2c which didnt make sense to me. Is it read in then sent to processors via i2c or spi?
perhaps there is some I/O buffer size which should be dictating the array size.. I dunno

When looking into things further I noticed that there is a _max_transfers which is defined to be 16. I am assuming this is with regard to the number of available registers? Is this left over from old i2c?

If that is an accurate assumption, than it would follow that 16x 32bit registers would create a maximum transfer size of 512. In which case my update to the array size for parsing being 512 may be a sufficient solution. But I am not smart enough about how things work to know if I am correct in any of my assumptions.

Additional Comments from Slack:

Beat Küng [9:09 AM]
@jgyoung the IO is connected via UART (https://github.com/PX4/Firmware/blob/master/src/drivers/px4io/px4io_serial.cpp). I don't know why I2C is mentioned there as well. If you don't find the problem, can you open an issue on github?

James Pattison [8:15 PM]
The IO board on the px4v1 was connected over I2C. That’s deprecated now so the i2c references could probably be cleaned out.

Roman Bapst [5:42 AM]
@jgyoung Regarding your mixer issue: If you don't solve the problem and decide to open an issue please also give a link to the mixer files you are using so that we can reproduce it quickly.

yavtol_quadd.main.mix.txt
@petermccloud
Copy link

I'm experiencing similar issues with v1.7.3. I get no errors on startup, but some of the channels do not respond. For instance, I had a mixer file set up for 4 channels. After bootup, I ran pwm info and got the following output:

nsh> pwm info
device: /dev/pwm_output0
channel 1: 1500 us (alternative rate: 50 Hz failsafe: 1500, disarmed: 1500 us, min: 1300 us, max: 1600 us, trim:  0.00)
channel 2: 900 us (alternative rate: 50 Hz failsafe: 900, disarmed: 1500 us, min: 1300 us, max: 1600 us, trim:  0.00)
channel 3: 0 us (alternative rate: 50 Hz failsafe: 0, disarmed: 1500 us, min: 1300 us, max: 1600 us, trim:  0.00)
channel 4: 0 us (alternative rate: 50 Hz failsafe: 0, disarmed: 1500 us, min: 1300 us, max: 1600 us, trim:  0.00)
channel 5: 0 us (default rate: 50 Hz failsafe: 0, disarmed: 0 us, min: 1000 us, max: 2000 us, trim:  0.00)
channel 6: 0 us (default rate: 50 Hz failsafe: 0, disarmed: 0 us, min: 1000 us, max: 2000 us, trim:  0.00)
channel 7: 0 us (default rate: 50 Hz failsafe: 0, disarmed: 0 us, min: 1000 us, max: 2000 us, trim:  0.00)
channel 8: 0 us (default rate: 50 Hz failsafe: 0, disarmed: 0 us, min: 1000 us, max: 2000 us, trim:  0.00)
channel group 0: channels 1 2
channel group 1: channels 5 6 7 8
channel group 2: channels 3 4

I tried stripping out all of the comments, and then 3 of the 4 channels were then available...

pwm info
device: /dev/pwm_output0
channel 1: 1500 us (alternative rate: 50 Hz failsafe: 1500, disarmed: 1500 us, min: 1300 us, max: 1600 us, trim:  0.00)
channel 2: 1500 us (alternative rate: 50 Hz failsafe: 0, disarmed: 1500 us, min: 1300 us, max: 1600 us, trim:  0.00)
channel 3: 1500 us (alternative rate: 50 Hz failsafe: 0, disarmed: 1500 us, min: 1300 us, max: 1600 us, trim:  0.00)
channel 4: 0 us (alternative rate: 50 Hz failsafe: 0, disarmed: 1500 us, min: 1300 us, max: 1600 us, trim:  0.00)
channel 5: 0 us (default rate: 50 Hz failsafe: 0, disarmed: 0 us, min: 1000 us, max: 2000 us, trim:  0.00)
channel 6: 0 us (default rate: 50 Hz failsafe: 0, disarmed: 0 us, min: 1000 us, max: 2000 us, trim:  0.00)
channel 7: 0 us (default rate: 50 Hz failsafe: 0, disarmed: 0 us, min: 1000 us, max: 2000 us, trim:  0.00)
channel 8: 0 us (default rate: 50 Hz failsafe: 0, disarmed: 0 us, min: 1000 us, max: 2000 us, trim:  0.00)
channel group 0: channels 1 2
channel group 1: channels 5 6 7 8
channel group 2: channels 3 4

Later, after making no other changes, all of the channels were working. I was using this mixer with 1.6.? without issues. I upgraded to 1.7.3 just a few days ago and started having this problem. The issues seems to be present on the current master branch as well.

@LorenzMeier
Copy link
Member

Feel free to ping me on lorenz@px4.io if the mixer issue persists.

@petermccloud
Copy link

petermccloud commented May 7, 2018 via email

@taileron
Copy link
Contributor

taileron commented Jun 18, 2018 •
edited
Loading

... changing source file: modules/pxiofirmware/mixer.h
line 42 from 230 to 330 will load mixers with more than 2 sources
On PixFalcon for me that worked perfect.
230 was a good value in V 1.6.5 but in versions above 1.7.x it is necessary to increase it
same in #8312

@LorenzMeier LorenzMeier added this to the Release v2.0.0 milestone Jun 18, 2018
@LorenzMeier LorenzMeier self-assigned this Jun 18, 2018
@taileron taileron mentioned this issue Jun 18, 2018
Closed
@taileron
Copy link
Contributor

... Release 1.8.0 broke it again.
with 1.8.0 rc0 master from 10´th of june it works (line 42 changed) perfect, all mixer always load even with 5 sources

@taileron
Copy link
Contributor

.... sorry, 1.8.0 Final release works perfect with line 42 changed to 330 (GCC 7.2.1) issue could be closed

@stale
Copy link

stale bot commented Jan 26, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale
Copy link

stale bot commented Feb 9, 2019

Closing as stale.

@stale stale bot closed this as completed Feb 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@LorenzMeier LorenzMeier

Labels
Admin: Wont fix
Projects
None yet
Milestone
Release v1.10.0
Development

No branches or pull requests
4 participants
@LorenzMeier @petermccloud @taileron @blarfo