With the new firmware release, I can’t find a way to map the different buttons (A,B,C…) directly to an SBUS channel like we were able to do with the previous version. Is their a way to map these buttons without being connected to QGC or Solex with the new release?
You can set it in both apps but not as you were able to do in the previous version.
Solex is better to do that at the moment. The RC controls interface will be improved in the future releases. Buttons functions are working only when the apps are running.
I need to map the buttons to one of the SBUS channel for my application. From what I understand, it is impossible for the moment? I can only map those buttons to specific functions inside the app. Is this something planned to be supported short term?
This will be supported in the future. There were some safety concerns with previous way of doing things. As the switches won’t hold the last known position like they should during controller reboot. We will add mechanism to hold the position information between reboot and reintroduce this feature.
Can you share what application is it you want to use it for, maybe we can recommend a way to do that with existing setup.
You can still do this but via the Aux ports on the Cube or PH ect. You map button to the relevant servo output channel via Mavlink in the app , set the ranges and then connect your device to that port on the Autopilot via PWM.
While they are not specifically mapped to Sbus you can get the same behaviour via Mavlink and the Aux channels.
Rather than assigning the Sbus channel to an output you assign Sevo function.
We’ve designed a specific payload for a UAV for environmental scientists. We developped our own PCB that can communicate with QGC throught mavlink. The PCB also has an SBUS decoder. However we don’t have any standard flight controller installed on it… It was really easy for me to get the button’s state directly from the SBUS before the latest release. Going throught QGC to get that information would be more complicated.
Understood, we will be adding that functionality into Herelink Settings for use cases like yours.
hi, i also try to map buttons permanent to an s-bus channel. independent if an solex is running or not.
i have an penetrating ground radar system which can controlled via s-bus or pwm inputs. this was working perfect with old herelink firmware and rc channels 8-10. now i am unable to control my radar system.
also switch modes like stabelise or rtl, imo is much more secure if they mapped to an rc channel because solex or qgroundcontrol can crash. if this happens you are unable to switch modes. not good from safety and securety viewpoint.
I think the changed behavior was intentionally made to get a more secure behavior because previously a crash/reboot of the unit caused a reset of the SBUS channel PWM values. You always have to consider that your remote control goes up in flames when you are flying (I guess you are not flying with an GPR?!) and you need to have a strategy what to do if that happens.
You should not forget that this is a beta unit and not intended for productive use. If you use it in an unintended manner you have to live with the shortcomings and work your way around them.
Not sure how to do that in your case, you might have to use solex. You still could stay with the old firmware until this update emerges. I did consider this too, but finally upgraded. Or, if you use Ardupilot, you connect Mission Planner via wifi hotspot or wifi network to your vehicle and use Mission Planner to set the servo values.
For the functions we all desire we have to wait for another update. Hopefully the next update is coming soon.
How to map button long presses in QGC with the latest beta firmware? @sidbh?
not possible, will follow in a later update.
I have no worries that the herlink will fail altogether or burn. with the previous firmware, the s-bus remote control in the transmitter and receiver worked very solid for me. I never had any failures here so that never a (rc) failsafe in the copter had to be triggered. however, qgroundcontroll has crashed more than once on every flight. that didn’t matter because the s-bus control continued to function stable. now the mapping switch and function is on solex or qgroundcontroll. I don’t like to fly like that. it should first confirm that solex or qgroundcontroll run safely without crashing. if you can not switch modes immediately flying is not secure. beta tester or not. testflying also need a minimum on safety control.
I used it for two hours straight and had no system crash with QGC. And before that I turned off my controller on purpose and failsafe’s work as should
Yes, you are right. But since the Herelink even crashes and makes reboots you still have to have a strategy how to crash savely.
I lost a copter yesterday which I might have saved with my Taranis, simply because you get a tactile feedback. If you are under stress displays and switches with no tactile feedback are bad.
Anyhow, as long as everything is running as expected the device is great. We have to give them time to fix that. I’m sure they will do.
I had numerous crashes with 3 different Herelinks, at least every 3rd flight.
I don’t know. I did extensive bench tasting last weekend and since have had no problems once I figured out the difference in the buttons and such. I shut down the controller, on purpose, and a Smart RTL is invoked. All is good with QGC and look forward to Solex getting the kinks worked out of it.
Well I do not understand this. Actually the most critical switches on the Remote are the Joystic, for throttle… This are still mapped to SBUS, I am wrong? In this case the problem will still persist in the new release. If not, then I do not understand why did the team remove the SBUS mapping of the buttons.
I supposed this is done to avoid triggering other functions like RTL… mapped to these buttons, in case of reboot. If this is be the case I would prefer to have the possibility to map them and be take care of what are my setting for this buttons.
Anyway I hope this is changed in the near future.
I did not understand how this workaround works. Could you be more specific?
Button mapping will be coming once they are happy with its behaviour and functionally.
It should be in the next update.