For anyone that's been playing with the PX4IO board; I've just pushed a set of changes to the px4io driver on the PX4FMU that might be interesting.
Specifcally, if you add 'px4io start' to your startup script, the 8 PWM servo outs should be available in the same fashion as the 4 PWM outs on FMU, and mixer scripts can be loaded in the same fashion, accessing all 8 outputs.
The two drivers should actually get along; whichever comes first ('px4io start' or 'fmu mode_pwm') will be the default outputs, but there are facilities for driving the second set as well; check the code for more details.
If anyone is tinkering with PX4IO, I'd love to hear from you; there's a lot of work to be done and if there's something specific that would be good to have sooner, it would help me pick things to prioritise.
thanks a lot for the good work on PX4IO first of all. Is there any documentation yet on how to access these inputs? I will look into the code in the next days anyways, but a short docu would help me (and probably many other beginners) to start :)
Concerning the features, I have one request at the moment (and might have a lot more on the future, because we`re working on a project which makes big use of PX4FMU/IO here): - Spektrum RC Support for PX4IO (Lorenz said in another thread that it's currently not implemented though it was tested a while ago)
so how does one access the 8 PX4IO PWM outputs exactly? Having included the actuator_controls topic from uOrb, I advertise & publish reasonable pwm-values (1000...2000) for all 8 available controls. However, in my test app the servos do not move. I upgraded PX4io with the newest firmware from today and started it successfully through the startup script.
Alternate questions: How could one make the fixedwing_control app throw its outputs to the PX4IO servo outputs instead of to the FMU outputs?
On Sunday, October 21, 2012 8:57:32 AM UTC+2, PX4 Developer wrote:
> For anyone that's been playing with the PX4IO board; I've just pushed a > set of changes to the px4io driver on the PX4FMU that might be interesting.
> Specifcally, if you add 'px4io start' to your startup script, the 8 PWM > servo outs should be available in the same fashion as the 4 PWM outs on > FMU, and mixer scripts can be loaded in the same fashion, accessing all 8 > outputs.
> The two drivers should actually get along; whichever comes first ('px4io > start' or 'fmu mode_pwm') will be the default outputs, but there are > facilities for driving the second set as well; check the code for more > details.
> If anyone is tinkering with PX4IO, I'd love to hear from you; there's a > lot of work to be done and if there's something specific that would be good > to have sooner, it would help me pick things to prioritise.
If you don't start the FMU PWM outputs, it will use IO. Whatever starts first gets control output group 0 and the second one group 1.
Stupid question: You did arm FMU AND IO, right? (FMU: fast blinking main loop led, IO: fast blinking arming switch led).
-Lorenz
Am 05.11.2012 um 20:41 schrieb Philipp Oettershagen <philipp.oettersha...@gmail.com<mailto:philipp.oettersha...@gmail.com>>
:
Hi,
so how does one access the 8 PX4IO PWM outputs exactly? Having included the actuator_controls topic from uOrb, I advertise & publish reasonable pwm-values (1000...2000) for all 8 available controls. However, in my test app the servos do not move. I upgraded PX4io with the newest firmware from today and started it successfully through the startup script.
Alternate questions: How could one make the fixedwing_control app throw its outputs to the PX4IO servo outputs instead of to the FMU outputs?
Best,
Philipp
On Sunday, October 21, 2012 8:57:32 AM UTC+2, PX4 Developer wrote:
For anyone that's been playing with the PX4IO board; I've just pushed a set of changes to the px4io driver on the PX4FMU that might be interesting.
Specifcally, if you add 'px4io start' to your startup script, the 8 PWM servo outs should be available in the same fashion as the 4 PWM outs on FMU, and mixer scripts can be loaded in the same fashion, accessing all 8 outputs.
The two drivers should actually get along; whichever comes first ('px4io start' or 'fmu mode_pwm') will be the default outputs, but there are facilities for driving the second set as well; check the code for more details.
If anyone is tinkering with PX4IO, I'd love to hear from you; there's a lot of work to be done and if there's something specific that would be good to have sooner, it would help me pick things to prioritise.
You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4users@googlegroups.com<mailto:px4users@googlegroups.com>. To unsubscribe from this group, send email to px4users+unsubscribe@googlegroups.com<mailto:px4users+unsubscribe@googlegro ups.com>. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
The first of the 'fmu' and 'px4io' drivers that you start will become the 'default' PWM output. If you start the other, it will become the secondary PWM output. There are four PWM output topics, which are claimed in order by the fmu and px4io drivers:
So if you just want to add more PWM outputs, once you've started the px4io driver you can publish to the second topic (actuator_controls_1) and that will drive the PX4IO outputs. The third and fourth topics are not yet claimed by anything yet.
In addition, the px4io driver has a device node (/dev/px4io) that responds to the PWM_SERVO and MIXER ioctls; if you don't want to use the ORB, then you can use ioctls instead. The node should respond to the GPIO ioctls, but there is work that needs to be done to make that behave right first. There's a trivial example of using the ioctl interface in the px4io 'test' command implementation.
HTH - let me know how you go on.
On Nov 5, 2012, at 11:41 AM, Philipp Oettershagen wrote:
> so how does one access the 8 PX4IO PWM outputs exactly? Having included the actuator_controls topic from uOrb, I advertise & publish reasonable pwm-values (1000...2000) for all 8 available controls. However, in my test app the servos do not move. I upgraded PX4io with the newest firmware from today and started it successfully through the startup script.
> Alternate questions: How could one make the fixedwing_control app throw its outputs to the PX4IO servo outputs instead of to the FMU outputs?
> Best,
> Philipp
> On Sunday, October 21, 2012 8:57:32 AM UTC+2, PX4 Developer wrote:
> For anyone that's been playing with the PX4IO board; I've just pushed a set of changes to the px4io driver on the PX4FMU that might be interesting.
> Specifcally, if you add 'px4io start' to your startup script, the 8 PWM servo outs should be available in the same fashion as the 4 PWM outs on FMU, and mixer scripts can be loaded in the same fashion, accessing all 8 outputs.
> The two drivers should actually get along; whichever comes first ('px4io start' or 'fmu mode_pwm') will be the default outputs, but there are facilities for driving the second set as well; check the code for more details.
> If anyone is tinkering with PX4IO, I'd love to hear from you; there's a lot of work to be done and if there's something specific that would be good to have sooner, it would help me pick things to prioritise.
> You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4users@googlegroups.com. To unsubscribe from this group, send email to px4users+unsubscribe@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
ok, so I think arming is one issue here :) To give you a problem description, these are the LED states:
FMU: blue led solid, red led slowly (ca. 1Hz) blinking IO: blue led 2Hz, red off safety switch led: off
The only docu on how to arm the system was that one should "press the safety switch". If I do this, I have a solid safety switch LED for 1s, then blinking, and once I release the safety switch the SS-LED turns off again with nothing changed on FMU & IO.
Is there any documentation on how to arm FMU&IO exactly? I also tried to manually set the vehicle_status.state_machine (from STDBY to PREFLIGHT) and vehicle_status.flag_system_armed variables, but that did not change anything.
I guess its pretty simple once you know how to... :)
On Tuesday, November 6, 2012 6:20:34 AM UTC+1, PX4 Developer wrote:
> Philipp,
> It depends on how you want to use them.
> The first of the 'fmu' and 'px4io' drivers that you start will become the > 'default' PWM output. If you start the other, it will become the secondary > PWM output. There are four PWM output topics, which are claimed in order by > the fmu and px4io drivers:
> So if you just want to add more PWM outputs, once you've started the px4io > driver you can publish to the second topic (actuator_controls_1) and that > will drive the PX4IO outputs. The third and fourth topics are not yet > claimed by anything yet.
> In addition, the px4io driver has a device node (/dev/px4io) that responds > to the PWM_SERVO and MIXER ioctls; if you don't want to use the ORB, then > you can use ioctls instead. The node should respond to the GPIO ioctls, but > there is work that needs to be done to make that behave right first. > There's a trivial example of using the ioctl interface in the px4io 'test' > command implementation.
> HTH - let me know how you go on.
> On Nov 5, 2012, at 11:41 AM, Philipp Oettershagen wrote:
> Hi,
> so how does one access the 8 PX4IO PWM outputs exactly? Having included > the actuator_controls topic from uOrb, I advertise & publish reasonable > pwm-values (1000...2000) for all 8 available controls. However, in my test > app the servos do not move. I upgraded PX4io with the newest firmware from > today and started it successfully through the startup script.
> Alternate questions: How could one make the fixedwing_control app throw > its outputs to the PX4IO servo outputs instead of to the FMU outputs?
> Best, > Philipp
> On Sunday, October 21, 2012 8:57:32 AM UTC+2, PX4 Developer wrote:
>> For anyone that's been playing with the PX4IO board; I've just pushed a >> set of changes to the px4io driver on the PX4FMU that might be interesting.
>> Specifcally, if you add 'px4io start' to your startup script, the 8 PWM >> servo outs should be available in the same fashion as the 4 PWM outs on >> FMU, and mixer scripts can be loaded in the same fashion, accessing all 8 >> outputs.
>> The two drivers should actually get along; whichever comes first ('px4io >> start' or 'fmu mode_pwm') will be the default outputs, but there are >> facilities for driving the second set as well; check the code for more >> details.
>> If anyone is tinkering with PX4IO, I'd love to hear from you; there's a >> lot of work to be done and if there's something specific that would be good >> to have sooner, it would help me pick things to prioritise.
> You received this message because you are subscribed to the Google Groups > px4users group. To post to this group, send email to > px4u...@googlegroups.com <javascript:>. To unsubscribe from this group, > send email to px4users+u...@googlegroups.com <javascript:>. For more > options, visit this group at > https://groups.google.com/d/forum/px4users?hl=en-US
We have to sort out the fixed wing story, but for now: Arm by putting the throttle lever on the lower right corner, like for a quad. Make sure to have the RC settings right. For now I recommend to calibrate your RC with mission planner, I didn't get around yet to test QGC.
On Nov 6, 2012, at 12:43 PM, Philipp Oettershagen wrote:
Hi,
ok, so I think arming is one issue here :) To give you a problem description, these are the LED states:
FMU: blue led solid, red led slowly (ca. 1Hz) blinking
IO: blue led 2Hz, red off
safety switch led: off
The only docu on how to arm the system was that one should "press the safety switch". If I do this, I have a solid safety switch LED for 1s, then blinking, and once I release the safety switch the SS-LED turns off again with nothing changed on FMU & IO.
Is there any documentation on how to arm FMU&IO exactly? I also tried to manually set the vehicle_status.state_machine (from STDBY to PREFLIGHT) and vehicle_status.flag_system_armed variables, but that did not change anything.
I guess its pretty simple once you know how to... :)
Best,
Philipp
On Tuesday, November 6, 2012 6:20:34 AM UTC+1, PX4 Developer wrote:
Philipp,
It depends on how you want to use them.
The first of the 'fmu' and 'px4io' drivers that you start will become the 'default' PWM output. If you start the other, it will become the secondary PWM output. There are four PWM output topics, which are claimed in order by the fmu and px4io drivers:
So if you just want to add more PWM outputs, once you've started the px4io driver you can publish to the second topic (actuator_controls_1) and that will drive the PX4IO outputs. The third and fourth topics are not yet claimed by anything yet.
In addition, the px4io driver has a device node (/dev/px4io) that responds to the PWM_SERVO and MIXER ioctls; if you don't want to use the ORB, then you can use ioctls instead. The node should respond to the GPIO ioctls, but there is work that needs to be done to make that behave right first. There's a trivial example of using the ioctl interface in the px4io 'test' command implementation.
HTH - let me know how you go on.
On Nov 5, 2012, at 11:41 AM, Philipp Oettershagen wrote:
Hi,
so how does one access the 8 PX4IO PWM outputs exactly? Having included the actuator_controls topic from uOrb, I advertise & publish reasonable pwm-values (1000...2000) for all 8 available controls. However, in my test app the servos do not move. I upgraded PX4io with the newest firmware from today and started it successfully through the startup script.
Alternate questions: How could one make the fixedwing_control app throw its outputs to the PX4IO servo outputs instead of to the FMU outputs?
Best,
Philipp
On Sunday, October 21, 2012 8:57:32 AM UTC+2, PX4 Developer wrote:
For anyone that's been playing with the PX4IO board; I've just pushed a set of changes to the px4io driver on the PX4FMU that might be interesting.
Specifcally, if you add 'px4io start' to your startup script, the 8 PWM servo outs should be available in the same fashion as the 4 PWM outs on FMU, and mixer scripts can be loaded in the same fashion, accessing all 8 outputs.
The two drivers should actually get along; whichever comes first ('px4io start' or 'fmu mode_pwm') will be the default outputs, but there are facilities for driving the second set as well; check the code for more details.
If anyone is tinkering with PX4IO, I'd love to hear from you; there's a lot of work to be done and if there's something specific that would be good to have sooner, it would help me pick things to prioritise.
You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4u...@googlegroups.com<javascript:>. To unsubscribe from this group, send email to px4users+u...@googlegroups.com<javascript:>. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4users@googlegroups.com<mailto:px4users@googlegroups.com>. To unsubscribe from this group, send email to px4users+unsubscribe@googlegroups.com<mailto:px4users+unsubscribe@googlegro ups.com>. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
On Nov 6, 2012, at 12:43 PM, Philipp Oettershagen wrote:
Hi,
ok, so I think arming is one issue here :) To give you a problem description, these are the LED states:
FMU: blue led solid, red led slowly (ca. 1Hz) blinking
IO: blue led 2Hz, red off
safety switch led: off
The only docu on how to arm the system was that one should "press the safety switch". If I do this, I have a solid safety switch LED for 1s, then blinking, and once I release the safety switch the SS-LED turns off again with nothing changed on FMU & IO.
Is there any documentation on how to arm FMU&IO exactly? I also tried to manually set the vehicle_status.state_machine (from STDBY to PREFLIGHT) and vehicle_status.flag_system_armed variables, but that did not change anything.
I guess its pretty simple once you know how to... :)
Best,
Philipp
On Tuesday, November 6, 2012 6:20:34 AM UTC+1, PX4 Developer wrote:
Philipp,
It depends on how you want to use them.
The first of the 'fmu' and 'px4io' drivers that you start will become the 'default' PWM output. If you start the other, it will become the secondary PWM output. There are four PWM output topics, which are claimed in order by the fmu and px4io drivers:
So if you just want to add more PWM outputs, once you've started the px4io driver you can publish to the second topic (actuator_controls_1) and that will drive the PX4IO outputs. The third and fourth topics are not yet claimed by anything yet.
In addition, the px4io driver has a device node (/dev/px4io) that responds to the PWM_SERVO and MIXER ioctls; if you don't want to use the ORB, then you can use ioctls instead. The node should respond to the GPIO ioctls, but there is work that needs to be done to make that behave right first. There's a trivial example of using the ioctl interface in the px4io 'test' command implementation.
HTH - let me know how you go on.
On Nov 5, 2012, at 11:41 AM, Philipp Oettershagen wrote:
Hi,
so how does one access the 8 PX4IO PWM outputs exactly? Having included the actuator_controls topic from uOrb, I advertise & publish reasonable pwm-values (1000...2000) for all 8 available controls. However, in my test app the servos do not move. I upgraded PX4io with the newest firmware from today and started it successfully through the startup script.
Alternate questions: How could one make the fixedwing_control app throw its outputs to the PX4IO servo outputs instead of to the FMU outputs?
Best,
Philipp
On Sunday, October 21, 2012 8:57:32 AM UTC+2, PX4 Developer wrote:
For anyone that's been playing with the PX4IO board; I've just pushed a set of changes to the px4io driver on the PX4FMU that might be interesting.
Specifcally, if you add 'px4io start' to your startup script, the 8 PWM servo outs should be available in the same fashion as the 4 PWM outs on FMU, and mixer scripts can be loaded in the same fashion, accessing all 8 outputs.
The two drivers should actually get along; whichever comes first ('px4io start' or 'fmu mode_pwm') will be the default outputs, but there are facilities for driving the second set as well; check the code for more details.
If anyone is tinkering with PX4IO, I'd love to hear from you; there's a lot of work to be done and if there's something specific that would be good to have sooner, it would help me pick things to prioritise.
You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4u...@googlegroups.com<javascript:>. To unsubscribe from this group, send email to px4users+u...@googlegroups.com<javascript:>. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4users@googlegroups.com<mailto:px4users@googlegroups.com>. To unsubscribe from this group, send email to px4users+unsubscribe@googlegroups.com<mailto:px4users+unsubscribe@googlegro ups.com>. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
unfortunately no, I cannot even arm because I do not get a RC connection. I am using the small satellite receiver of a Spektrum AR7010 at the PX4IO "Spektrum In" plug. This satellite receiver is correctly bound to my DX7 Transmitter. APM Planner however does not detect RC signals.
Also, I wrote a small "_testRC" application which does not show any RC channel data. The therein contained code
gives zero for rc.chan_count and all other values printed (with rc being a subscription of the rc_channels topic). I get the same values (i.e. chan count = 0) both before and after initialization of the px4io using "px4io start rx_spektrum7". I also did not find the direct implementation of the "px4io start rx_spektrum7" command in the code, i.e. I could not find "rx_spektrum7" in the whole workspace at all! Is this normal?
On Tuesday, November 6, 2012 3:24:42 PM UTC+1, Lorenz Meier wrote:
> Hi,
> Any luck with this in the meantime?
> -Lorenz
> ------------------------------------------------------ > Lorenz Meier > Institute for Visual Computing > ETH Zurich > http://www.inf.ethz.ch/personal/lomeier/
> On Nov 6, 2012, at 12:43 PM, Philipp Oettershagen wrote:
> Hi,
> ok, so I think arming is one issue here :) To give you a problem > description, these are the LED states:
> FMU: blue led solid, red led slowly (ca. 1Hz) blinking > IO: blue led 2Hz, red off > safety switch led: off
> The only docu on how to arm the system was that one should "press the > safety switch". If I do this, I have a solid safety switch LED for 1s, then > blinking, and once I release the safety switch the SS-LED turns off again > with nothing changed on FMU & IO.
> Is there any documentation on how to arm FMU&IO exactly? I also tried to > manually set the vehicle_status.state_machine (from STDBY to PREFLIGHT) and > vehicle_status.flag_system_armed variables, but that did not change > anything.
> I guess its pretty simple once you know how to... :)
> Best, > Philipp
> On Tuesday, November 6, 2012 6:20:34 AM UTC+1, PX4 Developer wrote: > Philipp,
> It depends on how you want to use them.
> The first of the 'fmu' and 'px4io' drivers that you start will become the > 'default' PWM output. If you start the other, it will become the secondary > PWM output. There are four PWM output topics, which are claimed in order by > the fmu and px4io drivers:
> So if you just want to add more PWM outputs, once you've started the px4io > driver you can publish to the second topic (actuator_controls_1) and that > will drive the PX4IO outputs. The third and fourth topics are not yet > claimed by anything yet.
> In addition, the px4io driver has a device node (/dev/px4io) that responds > to the PWM_SERVO and MIXER ioctls; if you don't want to use the ORB, then > you can use ioctls instead. The node should respond to the GPIO ioctls, but > there is work that needs to be done to make that behave right first. > There's a trivial example of using the ioctl interface in the px4io 'test' > command implementation.
> HTH - let me know how you go on.
> On Nov 5, 2012, at 11:41 AM, Philipp Oettershagen wrote:
> Hi,
> so how does one access the 8 PX4IO PWM outputs exactly? Having included > the actuator_controls topic from uOrb, I advertise & publish reasonable > pwm-values (1000...2000) for all 8 available controls. However, in my test > app the servos do not move. I upgraded PX4io with the newest firmware from > today and started it successfully through the startup script.
> Alternate questions: How could one make the fixedwing_control app throw > its outputs to the PX4IO servo outputs instead of to the FMU outputs?
> Best, > Philipp
> On Sunday, October 21, 2012 8:57:32 AM UTC+2, PX4 Developer wrote:
> For anyone that's been playing with the PX4IO board; I've just pushed a > set of changes to the px4io driver on the PX4FMU that might be interesting.
> Specifcally, if you add 'px4io start' to your startup script, the 8 PWM > servo outs should be available in the same fashion as the 4 PWM outs on > FMU, and mixer scripts can be loaded in the same fashion, accessing all 8 > outputs.
> The two drivers should actually get along; whichever comes first ('px4io > start' or 'fmu mode_pwm') will be the default outputs, but there are > facilities for driving the second set as well; check the code for more > details.
> If anyone is tinkering with PX4IO, I'd love to hear from you; there's a > lot of work to be done and if there's something specific that would be good > to have sooner, it would help me pick things to prioritise.
> You received this message because you are subscribed to the Google Groups > px4users group. To post to this group, send email to > px4u...@googlegroups.com<javascript:>. To unsubscribe from this group, > send email to px4users+u...@googlegroups.com<javascript:>. For more > options, visit this group at > https://groups.google.com/d/forum/px4users?hl=en-US
> You received this message because you are subscribed to the Google Groups > px4users group. To post to this group, send email to > px4u...@googlegroups.com <javascript:><mailto:px4u...@googlegroups.com<javascript:>>. > To unsubscribe from this group, send email to > px4users+u...@googlegroups.com <javascript:><mailto: > px4users+unsubscribe@googlegroups.com <javascript:>>. For more options, > visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
It sounds like there may be a problem with your safety switch wiring. The safety switch LED should be on solid when PX4IO boots.
Currently, PX4IO cannot be armed until PX4FMU is armed. The arming policy in general is open to discussion, but for now the design is somewhat tilted towards fixed-wing usage, where arming the aircraft is something you would do very late in your pre-flight checklist. This is not necessarily optimal for a rotorcraft, where you typically want to arm at a safe distance.
First, you need to sort out why your safety switch LED is not behaving correctly. It should be wired like this (forgive the sloppy Upverter screencap):
If the LED is on while the switch is closed, then I think you may have managed to wire the switch and LED in series somehow. At any rate, once the safety LED is blinking, PX4IO is armed and it believes that PX4FMU is armed as well.
Here's a simple test procedure you can use to verify that PX4IO is behaving:
Set up your PX4FMU to boot to the shell without starting the normal flight software; e.g. an /etc/rc on your microSD card containing just
set MODE none
Disconnect everything except your serial console from PX4IO/PX4FMU.
Attach a servo to PX4IO servo output 1 (closest to the power connector). Alternatively you can attach an oscilloscope or servo tester capable of measuring PWM servo signals.
At the nsh prompt, enter the following commands:
nsh> px4io start
nsh> px4io test
Press and hold the PX4IO safety switch until the safety LED is blinking (~1 second).
You should observe a 1000µs pulse on PX4IO servo output 1. Each channel above 1 should have a pulse longer by 100µs than the channel below (e.g. channel 2 should be 1100µs and so on).
On Nov 6, 2012, at 3:43 AM, Philipp Oettershagen wrote:
> ok, so I think arming is one issue here :) To give you a problem description, these are the LED states:
> FMU: blue led solid, red led slowly (ca. 1Hz) blinking
> IO: blue led 2Hz, red off
> safety switch led: off
> The only docu on how to arm the system was that one should "press the safety switch". If I do this, I have a solid safety switch LED for 1s, then blinking, and once I release the safety switch the SS-LED turns off again with nothing changed on FMU & IO.
> Is there any documentation on how to arm FMU&IO exactly? I also tried to manually set the vehicle_status.state_machine (from STDBY to PREFLIGHT) and vehicle_status.flag_system_armed variables, but that did not change anything.
> I guess its pretty simple once you know how to... :)
> Best,
> Philipp
> On Tuesday, November 6, 2012 6:20:34 AM UTC+1, PX4 Developer wrote:
> Philipp,
> It depends on how you want to use them.
> The first of the 'fmu' and 'px4io' drivers that you start will become the 'default' PWM output. If you start the other, it will become the secondary PWM output. There are four PWM output topics, which are claimed in order by the fmu and px4io drivers:
> So if you just want to add more PWM outputs, once you've started the px4io driver you can publish to the second topic (actuator_controls_1) and that will drive the PX4IO outputs. The third and fourth topics are not yet claimed by anything yet.
> In addition, the px4io driver has a device node (/dev/px4io) that responds to the PWM_SERVO and MIXER ioctls; if you don't want to use the ORB, then you can use ioctls instead. The node should respond to the GPIO ioctls, but there is work that needs to be done to make that behave right first. There's a trivial example of using the ioctl interface in the px4io 'test' command implementation.
> HTH - let me know how you go on.
> On Nov 5, 2012, at 11:41 AM, Philipp Oettershagen wrote:
>> Hi,
>> so how does one access the 8 PX4IO PWM outputs exactly? Having included the actuator_controls topic from uOrb, I advertise & publish reasonable pwm-values (1000...2000) for all 8 available controls. However, in my test app the servos do not move. I upgraded PX4io with the newest firmware from today and started it successfully through the startup script.
>> Alternate questions: How could one make the fixedwing_control app throw its outputs to the PX4IO servo outputs instead of to the FMU outputs?
>> Best,
>> Philipp
>> On Sunday, October 21, 2012 8:57:32 AM UTC+2, PX4 Developer wrote:
>> For anyone that's been playing with the PX4IO board; I've just pushed a set of changes to the px4io driver on the PX4FMU that might be interesting.
>> Specifcally, if you add 'px4io start' to your startup script, the 8 PWM servo outs should be available in the same fashion as the 4 PWM outs on FMU, and mixer scripts can be loaded in the same fashion, accessing all 8 outputs.
>> The two drivers should actually get along; whichever comes first ('px4io start' or 'fmu mode_pwm') will be the default outputs, but there are facilities for driving the second set as well; check the code for more details.
>> If anyone is tinkering with PX4IO, I'd love to hear from you; there's a lot of work to be done and if there's something specific that would be good to have sooner, it would help me pick things to prioritise.
>> You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4u...@googlegroups.com. To unsubscribe from this group, send email to px4users+u...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
> You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4users@googlegroups.com. To unsubscribe from this group, send email to px4users+unsubscribe@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
As per other recent threads, Spektrum input has not been tested yet as I don't have a working Spektrum setup. If you don't mind doing a little debugging on PX4IO, it should be easy to work out what's going wrong.
On Nov 6, 2012, at 11:03 AM, Philipp Oettershagen wrote:
> unfortunately no, I cannot even arm because I do not get a RC connection. I am using the small satellite receiver of a Spektrum AR7010 at the PX4IO "Spektrum In" plug. This satellite receiver is correctly bound to my DX7 Transmitter. APM Planner however does not detect RC signals.
> Also, I wrote a small "_testRC" application which does not show any RC channel data. The therein contained code
> gives zero for rc.chan_count and all other values printed (with rc being a subscription of the rc_channels topic). I get the same values (i.e. chan count = 0) both before and after initialization of the px4io using "px4io start rx_spektrum7". I also did not find the direct implementation of the "px4io start rx_spektrum7" command in the code, i.e. I could not find "rx_spektrum7" in the whole workspace at all! Is this normal?
> What might I be doing wrong?
> Best,
> Philipp
> On Tuesday, November 6, 2012 3:24:42 PM UTC+1, Lorenz Meier wrote:
> Hi,
> Any luck with this in the meantime?
> -Lorenz
> ------------------------------------------------------ > Lorenz Meier > Institute for Visual Computing > ETH Zurich > http://www.inf.ethz.ch/personal/lomeier/
> On Nov 6, 2012, at 12:43 PM, Philipp Oettershagen wrote:
> Hi,
> ok, so I think arming is one issue here :) To give you a problem description, these are the LED states:
> FMU: blue led solid, red led slowly (ca. 1Hz) blinking > IO: blue led 2Hz, red off > safety switch led: off
> The only docu on how to arm the system was that one should "press the safety switch". If I do this, I have a solid safety switch LED for 1s, then blinking, and once I release the safety switch the SS-LED turns off again with nothing changed on FMU & IO.
> Is there any documentation on how to arm FMU&IO exactly? I also tried to manually set the vehicle_status.state_machine (from STDBY to PREFLIGHT) and vehicle_status.flag_system_armed variables, but that did not change anything.
> I guess its pretty simple once you know how to... :)
> Best, > Philipp
> On Tuesday, November 6, 2012 6:20:34 AM UTC+1, PX4 Developer wrote: > Philipp,
> It depends on how you want to use them.
> The first of the 'fmu' and 'px4io' drivers that you start will become the 'default' PWM output. If you start the other, it will become the secondary PWM output. There are four PWM output topics, which are claimed in order by the fmu and px4io drivers:
> So if you just want to add more PWM outputs, once you've started the px4io driver you can publish to the second topic (actuator_controls_1) and that will drive the PX4IO outputs. The third and fourth topics are not yet claimed by anything yet.
> In addition, the px4io driver has a device node (/dev/px4io) that responds to the PWM_SERVO and MIXER ioctls; if you don't want to use the ORB, then you can use ioctls instead. The node should respond to the GPIO ioctls, but there is work that needs to be done to make that behave right first. There's a trivial example of using the ioctl interface in the px4io 'test' command implementation.
> HTH - let me know how you go on.
> On Nov 5, 2012, at 11:41 AM, Philipp Oettershagen wrote:
> Hi,
> so how does one access the 8 PX4IO PWM outputs exactly? Having included the actuator_controls topic from uOrb, I advertise & publish reasonable pwm-values (1000...2000) for all 8 available controls. However, in my test app the servos do not move. I upgraded PX4io with the newest firmware from today and started it successfully through the startup script.
> Alternate questions: How could one make the fixedwing_control app throw its outputs to the PX4IO servo outputs instead of to the FMU outputs?
> Best, > Philipp
> On Sunday, October 21, 2012 8:57:32 AM UTC+2, PX4 Developer wrote:
> For anyone that's been playing with the PX4IO board; I've just pushed a set of changes to the px4io driver on the PX4FMU that might be interesting.
> Specifcally, if you add 'px4io start' to your startup script, the 8 PWM servo outs should be available in the same fashion as the 4 PWM outs on FMU, and mixer scripts can be loaded in the same fashion, accessing all 8 outputs.
> The two drivers should actually get along; whichever comes first ('px4io start' or 'fmu mode_pwm') will be the default outputs, but there are facilities for driving the second set as well; check the code for more details.
> If anyone is tinkering with PX4IO, I'd love to hear from you; there's a lot of work to be done and if there's something specific that would be good to have sooner, it would help me pick things to prioritise.
> You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4u...@googlegroups.com<javascript:>. To unsubscribe from this group, send email to px4users+u...@googlegroups.com<javascript:>. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
> You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4u...@googlegroups.com<mailto:px4u...@googlegroups.com>. To unsubscribe from this group, send email to px4users+u...@googlegroups.com<mailto:px4users+unsubscribe@googlegroups.com >. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
> You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4users@googlegroups.com. To unsubscribe from this group, send email to px4users+unsubscribe@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
Actually, I take that back. There are some serious issues with the decoder as-is; I'm working up a new version. The protocol is more annoying than it first seemed.
> As per other recent threads, Spektrum input has not been tested yet as I don't have a working Spektrum setup. If you don't mind doing a little debugging on PX4IO, it should be easy to work out what's going wrong.
> On Nov 6, 2012, at 11:03 AM, Philipp Oettershagen wrote:
>> Hi,
>> unfortunately no, I cannot even arm because I do not get a RC connection. I am using the small satellite receiver of a Spektrum AR7010 at the PX4IO "Spektrum In" plug. This satellite receiver is correctly bound to my DX7 Transmitter. APM Planner however does not detect RC signals.
>> Also, I wrote a small "_testRC" application which does not show any RC channel data. The therein contained code
>> gives zero for rc.chan_count and all other values printed (with rc being a subscription of the rc_channels topic). I get the same values (i.e. chan count = 0) both before and after initialization of the px4io using "px4io start rx_spektrum7". I also did not find the direct implementation of the "px4io start rx_spektrum7" command in the code, i.e. I could not find "rx_spektrum7" in the whole workspace at all! Is this normal?
>> What might I be doing wrong?
>> Best,
>> Philipp
>> On Tuesday, November 6, 2012 3:24:42 PM UTC+1, Lorenz Meier wrote:
>> Hi,
>> Any luck with this in the meantime?
>> -Lorenz
>> ------------------------------------------------------ >> Lorenz Meier >> Institute for Visual Computing >> ETH Zurich >> http://www.inf.ethz.ch/personal/lomeier/
>> On Nov 6, 2012, at 12:43 PM, Philipp Oettershagen wrote:
>> Hi,
>> ok, so I think arming is one issue here :) To give you a problem description, these are the LED states:
>> FMU: blue led solid, red led slowly (ca. 1Hz) blinking >> IO: blue led 2Hz, red off >> safety switch led: off
>> The only docu on how to arm the system was that one should "press the safety switch". If I do this, I have a solid safety switch LED for 1s, then blinking, and once I release the safety switch the SS-LED turns off again with nothing changed on FMU & IO.
>> Is there any documentation on how to arm FMU&IO exactly? I also tried to manually set the vehicle_status.state_machine (from STDBY to PREFLIGHT) and vehicle_status.flag_system_armed variables, but that did not change anything.
>> I guess its pretty simple once you know how to... :)
>> Best, >> Philipp
>> On Tuesday, November 6, 2012 6:20:34 AM UTC+1, PX4 Developer wrote: >> Philipp,
>> It depends on how you want to use them.
>> The first of the 'fmu' and 'px4io' drivers that you start will become the 'default' PWM output. If you start the other, it will become the secondary PWM output. There are four PWM output topics, which are claimed in order by the fmu and px4io drivers:
>> So if you just want to add more PWM outputs, once you've started the px4io driver you can publish to the second topic (actuator_controls_1) and that will drive the PX4IO outputs. The third and fourth topics are not yet claimed by anything yet.
>> In addition, the px4io driver has a device node (/dev/px4io) that responds to the PWM_SERVO and MIXER ioctls; if you don't want to use the ORB, then you can use ioctls instead. The node should respond to the GPIO ioctls, but there is work that needs to be done to make that behave right first. There's a trivial example of using the ioctl interface in the px4io 'test' command implementation.
>> HTH - let me know how you go on.
>> On Nov 5, 2012, at 11:41 AM, Philipp Oettershagen wrote:
>> Hi,
>> so how does one access the 8 PX4IO PWM outputs exactly? Having included the actuator_controls topic from uOrb, I advertise & publish reasonable pwm-values (1000...2000) for all 8 available controls. However, in my test app the servos do not move. I upgraded PX4io with the newest firmware from today and started it successfully through the startup script.
>> Alternate questions: How could one make the fixedwing_control app throw its outputs to the PX4IO servo outputs instead of to the FMU outputs?
>> Best, >> Philipp
>> On Sunday, October 21, 2012 8:57:32 AM UTC+2, PX4 Developer wrote:
>> For anyone that's been playing with the PX4IO board; I've just pushed a set of changes to the px4io driver on the PX4FMU that might be interesting.
>> Specifcally, if you add 'px4io start' to your startup script, the 8 PWM servo outs should be available in the same fashion as the 4 PWM outs on FMU, and mixer scripts can be loaded in the same fashion, accessing all 8 outputs.
>> The two drivers should actually get along; whichever comes first ('px4io start' or 'fmu mode_pwm') will be the default outputs, but there are facilities for driving the second set as well; check the code for more details.
>> If anyone is tinkering with PX4IO, I'd love to hear from you; there's a lot of work to be done and if there's something specific that would be good to have sooner, it would help me pick things to prioritise.
>> You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4u...@googlegroups.com<javascript:>. To unsubscribe from this group, send email to px4users+u...@googlegroups.com<javascript:>. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
>> You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4u...@googlegroups.com<mailto:px4u...@googlegroups.com>. To unsubscribe from this group, send email to px4users+u...@googlegroups.com<mailto:px4users+unsubscribe@googlegroups.com >. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
>> You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4users@googlegroups.com. To unsubscribe from this group, send email to px4users+unsubscribe@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
> You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4users@googlegroups.com. To unsubscribe from this group, send email to px4users+unsubscribe@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
ok, arming switch issue is working now, there were some minor glitches with pin ordering in the old PX4IO manual... My IO is therefore armed now. Thanks for the good explanations guys!
However, still now Spektrum input. PX4Dev, let me know when you pushed the new spektrum version, i will test it ASAP then!
On Wednesday, November 7, 2012 11:17:41 AM UTC+1, PX4 Developer wrote:
> Actually, I take that back. There are some serious issues with the > decoder as-is; I'm working up a new version. The protocol is more annoying > than it first seemed.
> On Nov 6, 2012, at 11:28 PM, PX4 Developer wrote:
> Philipp,
> As per other recent threads, Spektrum input has not been tested yet as I > don't have a working Spektrum setup. If you don't mind doing a little > debugging on PX4IO, it should be easy to work out what's going wrong.
> On Nov 6, 2012, at 11:03 AM, Philipp Oettershagen wrote:
> Hi,
> unfortunately no, I cannot even arm because I do not get a RC connection. > I am using the small satellite receiver of a Spektrum AR7010 at the PX4IO > "Spektrum In" plug. This satellite receiver is correctly bound to my DX7 > Transmitter. APM Planner however does not detect RC signals.
> Also, I wrote a small "_testRC" application which does not show any RC > channel data. The therein contained code
> gives zero for rc.chan_count and all other values printed (with rc being a > subscription of the rc_channels topic). I get the same values (i.e. chan > count = 0) both before and after initialization of the px4io using "px4io > start rx_spektrum7". I also did not find the direct implementation of the > "px4io start rx_spektrum7" command in the code, i.e. I could not find > "rx_spektrum7" in the whole workspace at all! Is this normal?
> What might I be doing wrong? > Best, > Philipp
> On Tuesday, November 6, 2012 3:24:42 PM UTC+1, Lorenz Meier wrote:
>> Hi,
>> Any luck with this in the meantime?
>> -Lorenz
>> ------------------------------------------------------ >> Lorenz Meier >> Institute for Visual Computing >> ETH Zurich >> http://www.inf.ethz.ch/personal/lomeier/
>> On Nov 6, 2012, at 12:43 PM, Philipp Oettershagen wrote:
>> Hi,
>> ok, so I think arming is one issue here :) To give you a problem >> description, these are the LED states:
>> FMU: blue led solid, red led slowly (ca. 1Hz) blinking >> IO: blue led 2Hz, red off >> safety switch led: off
>> The only docu on how to arm the system was that one should "press the >> safety switch". If I do this, I have a solid safety switch LED for 1s, then >> blinking, and once I release the safety switch the SS-LED turns off again >> with nothing changed on FMU & IO.
>> Is there any documentation on how to arm FMU&IO exactly? I also tried to >> manually set the vehicle_status.state_machine (from STDBY to PREFLIGHT) and >> vehicle_status.flag_system_armed variables, but that did not change >> anything.
>> I guess its pretty simple once you know how to... :)
>> Best, >> Philipp
>> On Tuesday, November 6, 2012 6:20:34 AM UTC+1, PX4 Developer wrote: >> Philipp,
>> It depends on how you want to use them.
>> The first of the 'fmu' and 'px4io' drivers that you start will become the >> 'default' PWM output. If you start the other, it will become the secondary >> PWM output. There are four PWM output topics, which are claimed in order by >> the fmu and px4io drivers:
>> So if you just want to add more PWM outputs, once you've started the >> px4io driver you can publish to the second topic (actuator_controls_1) and >> that will drive the PX4IO outputs. The third and fourth topics are not yet >> claimed by anything yet.
>> In addition, the px4io driver has a device node (/dev/px4io) that >> responds to the PWM_SERVO and MIXER ioctls; if you don't want to use the >> ORB, then you can use ioctls instead. The node should respond to the GPIO >> ioctls, but there is work that needs to be done to make that behave right >> first. There's a trivial example of using the ioctl interface in the px4io >> 'test' command implementation.
>> HTH - let me know how you go on.
>> On Nov 5, 2012, at 11:41 AM, Philipp Oettershagen wrote:
>> Hi,
>> so how does one access the 8 PX4IO PWM outputs exactly? Having included >> the actuator_controls topic from uOrb, I advertise & publish reasonable >> pwm-values (1000...2000) for all 8 available controls. However, in my test >> app the servos do not move. I upgraded PX4io with the newest firmware from >> today and started it successfully through the startup script.
>> Alternate questions: How could one make the fixedwing_control app throw >> its outputs to the PX4IO servo outputs instead of to the FMU outputs?
>> Best, >> Philipp
>> On Sunday, October 21, 2012 8:57:32 AM UTC+2, PX4 Developer wrote:
>> For anyone that's been playing with the PX4IO board; I've just pushed a >> set of changes to the px4io driver on the PX4FMU that might be interesting.
>> Specifcally, if you add 'px4io start' to your startup script, the 8 PWM >> servo outs should be available in the same fashion as the 4 PWM outs on >> FMU, and mixer scripts can be loaded in the same fashion, accessing all 8 >> outputs.
>> The two drivers should actually get along; whichever comes first ('px4io >> start' or 'fmu mode_pwm') will be the default outputs, but there are >> facilities for driving the second set as well; check the code for more >> details.
>> If anyone is tinkering with PX4IO, I'd love to hear from you; there's a >> lot of work to be done and if there's something specific that would be good >> to have sooner, it would help me pick things to prioritise.
>> You received this message because you are subscribed to the Google Groups >> px4users group. To post to this group, send email to >> px4u...@googlegroups.com<javascript:>. To unsubscribe from this group, >> send email to px4users+u...@googlegroups.com<javascript:>. For more >> options, visit this group at >> https://groups.google.com/d/forum/px4users?hl=en-US
>> You received this message because you are subscribed to the Google Groups >> px4users group. To post to this group, send email to >> px4u...@googlegroups.com<mailto:px4u...@googlegroups.com>. To >> unsubscribe from this group, send email to px4users+u...@googlegroups.com >> <mailto:px4users+unsubscribe@googlegroups.com>. For more options, visit >> this group at https://groups.google.com/d/forum/px4users?hl=en-US
> You received this message because you are subscribed to the Google Groups > px4users group. To post to this group, send email to > px4u...@googlegroups.com <javascript:>. To unsubscribe from this group, > send email to px4users+u...@googlegroups.com <javascript:>. For more > options, visit this group at > https://groups.google.com/d/forum/px4users?hl=en-US
> You received this message because you are subscribed to the Google Groups > px4users group. To post to this group, send email to > px4u...@googlegroups.com <javascript:>. To unsubscribe from this group, > send email to px4users+u...@googlegroups.com <javascript:>. For more > options, visit this group at > https://groups.google.com/d/forum/px4users?hl=en-US
On Nov 7, 2012, at 4:41 PM, Philipp Oettershagen wrote:
Hi,
ok, arming switch issue is working now, there were some minor glitches with pin ordering in the old PX4IO manual... My IO is therefore armed now. Thanks for the good explanations guys!
However, still now Spektrum input. PX4Dev, let me know when you pushed the new spektrum version, i will test it ASAP then!
On Wednesday, November 7, 2012 11:17:41 AM UTC+1, PX4 Developer wrote:
Actually, I take that back. There are some serious issues with the decoder as-is; I'm working up a new version. The protocol is more annoying than it first seemed.
On Nov 6, 2012, at 11:28 PM, PX4 Developer wrote:
Philipp,
As per other recent threads, Spektrum input has not been tested yet as I don't have a working Spektrum setup. If you don't mind doing a little debugging on PX4IO, it should be easy to work out what's going wrong.
On Nov 6, 2012, at 11:03 AM, Philipp Oettershagen wrote:
Hi,
unfortunately no, I cannot even arm because I do not get a RC connection. I am using the small satellite receiver of a Spektrum AR7010 at the PX4IO "Spektrum In" plug. This satellite receiver is correctly bound to my DX7 Transmitter. APM Planner however does not detect RC signals.
Also, I wrote a small "_testRC" application which does not show any RC channel data. The therein contained code
gives zero for rc.chan_count and all other values printed (with rc being a subscription of the rc_channels topic). I get the same values (i.e. chan count = 0) both before and after initialization of the px4io using "px4io start rx_spektrum7". I also did not find the direct implementation of the "px4io start rx_spektrum7" command in the code, i.e. I could not find "rx_spektrum7" in the whole workspace at all! Is this normal?
What might I be doing wrong?
Best,
Philipp
On Tuesday, November 6, 2012 3:24:42 PM UTC+1, Lorenz Meier wrote:
On Nov 6, 2012, at 12:43 PM, Philipp Oettershagen wrote:
Hi,
ok, so I think arming is one issue here :) To give you a problem description, these are the LED states:
FMU: blue led solid, red led slowly (ca. 1Hz) blinking
IO: blue led 2Hz, red off
safety switch led: off
The only docu on how to arm the system was that one should "press the safety switch". If I do this, I have a solid safety switch LED for 1s, then blinking, and once I release the safety switch the SS-LED turns off again with nothing changed on FMU & IO.
Is there any documentation on how to arm FMU&IO exactly? I also tried to manually set the vehicle_status.state_machine (from STDBY to PREFLIGHT) and vehicle_status.flag_system_armed variables, but that did not change anything.
I guess its pretty simple once you know how to... :)
Best,
Philipp
On Tuesday, November 6, 2012 6:20:34 AM UTC+1, PX4 Developer wrote:
Philipp,
It depends on how you want to use them.
The first of the 'fmu' and 'px4io' drivers that you start will become the 'default' PWM output. If you start the other, it will become the secondary PWM output. There are four PWM output topics, which are claimed in order by the fmu and px4io drivers:
So if you just want to add more PWM outputs, once you've started the px4io driver you can publish to the second topic (actuator_controls_1) and that will drive the PX4IO outputs. The third and fourth topics are not yet claimed by anything yet.
In addition, the px4io driver has a device node (/dev/px4io) that responds to the PWM_SERVO and MIXER ioctls; if you don't want to use the ORB, then you can use ioctls instead. The node should respond to the GPIO ioctls, but there is work that needs to be done to make that behave right first. There's a trivial example of using the ioctl interface in the px4io 'test' command implementation.
HTH - let me know how you go on.
On Nov 5, 2012, at 11:41 AM, Philipp Oettershagen wrote:
Hi,
so how does one access the 8 PX4IO PWM outputs exactly? Having included the actuator_controls topic from uOrb, I advertise & publish reasonable pwm-values (1000...2000) for all 8 available controls. However, in my test app the servos do not move. I upgraded PX4io with the newest firmware from today and started it successfully through the startup script.
Alternate questions: How could one make the fixedwing_control app throw its outputs to the PX4IO servo outputs instead of to the FMU outputs?
Best,
Philipp
On Sunday, October 21, 2012 8:57:32 AM UTC+2, PX4 Developer wrote:
For anyone that's been playing with the PX4IO board; I've just pushed a set of changes to the px4io driver on the PX4FMU that might be interesting.
Specifcally, if you add 'px4io start' to your startup script, the 8 PWM servo outs should be available in the same fashion as the 4 PWM outs on FMU, and mixer scripts can be loaded in the same fashion, accessing all 8 outputs.
The two drivers should actually get along; whichever comes first ('px4io start' or 'fmu mode_pwm') will be the default outputs, but there are facilities for driving the second set as well; check the code for more details.
If anyone is tinkering with PX4IO, I'd love to hear from you; there's a lot of work to be done and if there's something specific that would be good to have sooner, it would help me pick things to prioritise.
You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4u...@googlegroups.com<javascript:>. To unsubscribe from this group, send email to px4users+u...@googlegroups.com<javascript:>. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4u...@googlegroups.com<mailto:px4u...@googlegroups.com>. To unsubscribe from this group, send email to px4users+u...@googlegroups.com<mailto:px4users+unsubscribe@googlegroups.com >. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4u...@googlegroups.com<javascript:>. To unsubscribe from this group, send email to px4users+u...@googlegroups.com<javascript:>. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4u...@googlegroups.com<javascript:>. To unsubscribe from this group, send email to px4users+u...@googlegroups.com<javascript:>. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4users@googlegroups.com<mailto:px4users@googlegroups.com>. To unsubscribe from this group, send email to px4users+unsubscribe@googlegroups.com<mailto:px4users+unsubscribe@googlegro ups.com>. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
On Wednesday, November 7, 2012 11:17:41 AM UTC+1, PX4 Developer wrote:
> Actually, I take that back. There are some serious issues with the > decoder as-is; I'm working up a new version. The protocol is more annoying > than it first seemed.
> On Nov 6, 2012, at 11:28 PM, PX4 Developer wrote:
> Philipp,
> As per other recent threads, Spektrum input has not been tested yet as I > don't have a working Spektrum setup. If you don't mind doing a little > debugging on PX4IO, it should be easy to work out what's going wrong.
> On Nov 6, 2012, at 11:03 AM, Philipp Oettershagen wrote:
> Hi,
> unfortunately no, I cannot even arm because I do not get a RC connection. > I am using the small satellite receiver of a Spektrum AR7010 at the PX4IO > "Spektrum In" plug. This satellite receiver is correctly bound to my DX7 > Transmitter. APM Planner however does not detect RC signals.
> Also, I wrote a small "_testRC" application which does not show any RC > channel data. The therein contained code
> gives zero for rc.chan_count and all other values printed (with rc being a > subscription of the rc_channels topic). I get the same values (i.e. chan > count = 0) both before and after initialization of the px4io using "px4io > start rx_spektrum7". I also did not find the direct implementation of the > "px4io start rx_spektrum7" command in the code, i.e. I could not find > "rx_spektrum7" in the whole workspace at all! Is this normal?
> What might I be doing wrong? > Best, > Philipp
> On Tuesday, November 6, 2012 3:24:42 PM UTC+1, Lorenz Meier wrote:
>> Hi,
>> Any luck with this in the meantime?
>> -Lorenz
>> ------------------------------------------------------ >> Lorenz Meier >> Institute for Visual Computing >> ETH Zurich >> http://www.inf.ethz.ch/personal/lomeier/
>> On Nov 6, 2012, at 12:43 PM, Philipp Oettershagen wrote:
>> Hi,
>> ok, so I think arming is one issue here :) To give you a problem >> description, these are the LED states:
>> FMU: blue led solid, red led slowly (ca. 1Hz) blinking >> IO: blue led 2Hz, red off >> safety switch led: off
>> The only docu on how to arm the system was that one should "press the >> safety switch". If I do this, I have a solid safety switch LED for 1s, then >> blinking, and once I release the safety switch the SS-LED turns off again >> with nothing changed on FMU & IO.
>> Is there any documentation on how to arm FMU&IO exactly? I also tried to >> manually set the vehicle_status.state_machine (from STDBY to PREFLIGHT) and >> vehicle_status.flag_system_armed variables, but that did not change >> anything.
>> I guess its pretty simple once you know how to... :)
>> Best, >> Philipp
>> On Tuesday, November 6, 2012 6:20:34 AM UTC+1, PX4 Developer wrote: >> Philipp,
>> It depends on how you want to use them.
>> The first of the 'fmu' and 'px4io' drivers that you start will become the >> 'default' PWM output. If you start the other, it will become the secondary >> PWM output. There are four PWM output topics, which are claimed in order by >> the fmu and px4io drivers:
>> So if you just want to add more PWM outputs, once you've started the >> px4io driver you can publish to the second topic (actuator_controls_1) and >> that will drive the PX4IO outputs. The third and fourth topics are not yet >> claimed by anything yet.
>> In addition, the px4io driver has a device node (/dev/px4io) that >> responds to the PWM_SERVO and MIXER ioctls; if you don't want to use the >> ORB, then you can use ioctls instead. The node should respond to the GPIO >> ioctls, but there is work that needs to be done to make that behave right >> first. There's a trivial example of using the ioctl interface in the px4io >> 'test' command implementation.
>> HTH - let me know how you go on.
>> On Nov 5, 2012, at 11:41 AM, Philipp Oettershagen wrote:
>> Hi,
>> so how does one access the 8 PX4IO PWM outputs exactly? Having included >> the actuator_controls topic from uOrb, I advertise & publish reasonable >> pwm-values (1000...2000) for all 8 available controls. However, in my test >> app the servos do not move. I upgraded PX4io with the newest firmware from >> today and started it successfully through the startup script.
>> Alternate questions: How could one make the fixedwing_control app throw >> its outputs to the PX4IO servo outputs instead of to the FMU outputs?
>> Best, >> Philipp
>> On Sunday, October 21, 2012 8:57:32 AM UTC+2, PX4 Developer wrote:
>> For anyone that's been playing with the PX4IO board; I've just pushed a >> set of changes to the px4io driver on the PX4FMU that might be interesting.
>> Specifcally, if you add 'px4io start' to your startup script, the 8 PWM >> servo outs should be available in the same fashion as the 4 PWM outs on >> FMU, and mixer scripts can be loaded in the same fashion, accessing all 8 >> outputs.
>> The two drivers should actually get along; whichever comes first ('px4io >> start' or 'fmu mode_pwm') will be the default outputs, but there are >> facilities for driving the second set as well; check the code for more >> details.
>> If anyone is tinkering with PX4IO, I'd love to hear from you; there's a >> lot of work to be done and if there's something specific that would be good >> to have sooner, it would help me pick things to prioritise.
>> You received this message because you are subscribed to the Google Groups >> px4users group. To post to this group, send email to >> px4u...@googlegroups.com<javascript:>. To unsubscribe from this group, >> send email to px4users+u...@googlegroups.com<javascript:>. For more >> options, visit this group at >> https://groups.google.com/d/forum/px4users?hl=en-US
>> You received this message because you are subscribed to the Google Groups >> px4users group. To post to this group, send email to >> px4u...@googlegroups.com<mailto:px4u...@googlegroups.com>. To >> unsubscribe from this group, send email to px4users+u...@googlegroups.com >> <mailto:px4users+unsubscribe@googlegroups.com>. For more options, visit >> this group at https://groups.google.com/d/forum/px4users?hl=en-US
> You received this message because you are subscribed to the Google Groups > px4users group. To post to this group, send email to > px4u...@googlegroups.com <javascript:>. To unsubscribe from this group, > send email to px4users+u...@googlegroups.com <javascript:>. For more > options, visit this group at > https://groups.google.com/d/forum/px4users?hl=en-US
> You received this message because you are subscribed to the Google Groups > px4users group. To post to this group, send email to > px4u...@googlegroups.com <javascript:>. To unsubscribe from this group, > send email to px4users+u...@googlegroups.com <javascript:>. For more > options, visit this group at > https://groups.google.com/d/forum/px4users?hl=en-US
