Hi,
Can you please elaborate what sort of current draw issue you have with the Orange CUBE . I am using the HJX640 QUAD frame with 13x 5 props. It is working fine except i have problem receiving the ADSB -IN signals/ messages
Of course, I will. I need to assemble the quad first, that will take some time now.
1 Like
I am using the px4 stable version
Software Version: v1.12.3
OS Version: NuttX, v8.2.0
Estimator: EKF2
For me the Mavlink console is working and i am able to send Mavlink commands via my GCS
*px4 stable version*
*Software Version: v1.12.3*
*OS Version: NuttX, v8.2.0*
*Estimator: EKF2*
I need FD CAN support in order to incorporate the Orange Cube into our product. It appears that Nuttx supports FD CAN, but I cannot find that support in PX4. The Black Cube/PX4 supports 2 CAN buses, when will the Orange Cube/PX4 support 2 CAN buses?
TIA!
Hi,
Can the below link assist with your query
Ok, I have an update: finally assembled my S500 with Cube Orange, put PX4 1.13.0 on it and it flew very well. I am not sure what we experienced in the beginning, a few years ago, but at the moment it’s all fine for me wrt the basics.
Cheers,
Raymond
1 Like
Ok, I had an interesting experience today, with a failing calibration of a Cube Orange based setup. I cannot calibrate this setup and I wonder how to report this. I would love to help but at this moment the best I can do is testing and reporting.
The biggest difference compared to last time is that this Cube is recent (not sure if there are different revisions or so) and that I use a Here3 connected via CAN. The S500 setup that I reported earlier uses a Here2 (and therefore of cource i2c).
Update 2022 0827: I mounted the Here3 (CAN) on the S500 with the Cube Orange and that’s going well too. I would really like to find out what’s going on so if there are developer with who I can discuss things, I am happy to sort out things!
This was constantly reported:
Accel 1 clipping, not safe to fly!
Land now, and check the vehicle setup. Clipping can lead to fly-aways.
[cal] accel 1 invalid Y-axis, check rotation
What’s the best way to proceed?
I would say create a log from boot with high rate sensor logging where you do the calibration to show how it fails. Then you stop the log and upload the logfile to logs.px4.io and link it in a PX4 issue (or here). That would probably be helpful data.
The params would be:
- SDLOG_MODE set to
2. - SDLOG_PROFILE set to
65(edit: not6), so default plus sensor comparison.
2 Likes
We sometimes observe that the Cube Orange looses all its parameters or set them to default values.
We have no clue why or in which situations the reset occures. Only thing we noticed is that it mostly occures when we do a “Reboot Vehicle” via QGroundControl.
Currently in use is a custom version of PX4 1.13 with enabled RTPS. But have seen simular resets of the parameters in version 1.12.3.
Regards
Jannis
Is this thread still alive?
Lately I am experiencing issues with 2 Cube Oranges: they don’t respond properly anymore, as if parts in it are slowly dying… I’ve used these before, uploading firmware frequently…
This is what I get:
Nov 16 17:59:50 traveller kernel: [ 1511.349645] usb 1-4: new full-speed USB device number 34 using xhci_hcd
Nov 16 17:59:50 traveller kernel: [ 1511.477688] usb 1-4: device descriptor read/64, error -71
Nov 16 17:59:50 traveller kernel: [ 1511.713687] usb 1-4: device descriptor read/64, error -71
Nov 16 17:59:51 traveller kernel: [ 1511.949650] usb 1-4: new full-speed USB device number 35 using xhci_hcd
Nov 16 17:59:51 traveller kernel: [ 1512.077695] usb 1-4: device descriptor read/64, error -71
Nov 16 17:59:51 traveller kernel: [ 1512.313692] usb 1-4: device descriptor read/64, error -71
Nov 16 17:59:51 traveller kernel: [ 1512.421832] usb usb1-port4: attempt power cycle
Nov 16 17:59:52 traveller kernel: [ 1513.073662] usb 1-4: new full-speed USB device number 36 using xhci_hcd
Nov 16 17:59:52 traveller kernel: [ 1513.073876] usb 1-4: Device not responding to setup address.
Nov 16 17:59:52 traveller kernel: [ 1513.281893] usb 1-4: Device not responding to setup address.
Nov 16 17:59:52 traveller kernel: [ 1513.489663] usb 1-4: device not accepting address 36, error -71
Nov 16 17:59:52 traveller kernel: [ 1513.617666] usb 1-4: new full-speed USB device number 37 using xhci_hcd
Nov 16 17:59:52 traveller kernel: [ 1513.617859] usb 1-4: Device not responding to setup address.
Nov 16 17:59:53 traveller kernel: [ 1513.825872] usb 1-4: Device not responding to setup address.
Nov 16 17:59:53 traveller kernel: [ 1514.037665] usb 1-4: device not accepting address 37, error -71
Nov 16 17:59:53 traveller kernel: [ 1514.037805] usb usb1-port4: unable to enumerate USB device
Nov 16 17:59:55 traveller kernel: [ 1516.661693] usb 1-4: new full-speed USB device number 38 using xhci_hcd
Nov 16 17:59:55 traveller kernel: [ 1516.789734] usb 1-4: device descriptor read/64, error -71
Nov 16 17:59:56 traveller kernel: [ 1517.025733] usb 1-4: device descriptor read/64, error -71
Nov 16 17:59:56 traveller kernel: [ 1517.261705] usb 1-4: new full-speed USB device number 39 using xhci_hcd
Nov 16 17:59:56 traveller kernel: [ 1517.389792] usb 1-4: device descriptor read/64, error -71
Nov 16 17:59:56 traveller kernel: [ 1517.625744] usb 1-4: device descriptor read/64, error -71
Nov 16 17:59:56 traveller kernel: [ 1517.733851] usb usb1-port4: attempt power cycle
Nov 16 17:59:57 traveller kernel: [ 1518.385740] usb 1-4: new full-speed USB device number 40 using xhci_hcd
Nov 16 17:59:57 traveller kernel: [ 1518.385953] usb 1-4: Device not responding to setup address.
Nov 16 17:59:57 traveller kernel: [ 1518.593905] usb 1-4: Device not responding to setup address.
Nov 16 17:59:57 traveller kernel: [ 1518.801705] usb 1-4: device not accepting address 40, error -71
Nov 16 17:59:58 traveller kernel: [ 1518.929714] usb 1-4: new full-speed USB device number 41 using xhci_hcd
Nov 16 17:59:58 traveller kernel: [ 1518.929949] usb 1-4: Device not responding to setup address.
Nov 16 17:59:58 traveller kernel: [ 1519.137955] usb 1-4: Device not responding to setup address.
Nov 16 17:59:58 traveller kernel: [ 1519.345707] usb 1-4: device not accepting address 41, error -71
Nov 16 17:59:58 traveller kernel: [ 1519.345866] usb usb1-port4: unable to enumerate USB device
Of course tried it out on different machines with the same result. There was a related PX4 thread where a new mission planner fixed it. And so I tried it on Windows but no luck there too.
Any idea?
I appreciate any feedback/suggestion.
Update: after having tried the 3rd Cube Orange which also didn’t work, I started to doubt the USB cable… And yes, it seems that this original ‘Cube cable’ was the issue. I tried a different original USB cable and that one is working ok. I guess I have damaged the cable in some way, although I did not expect this effect.
Cheers,
Raymond
This is regarding GPS NMEA messages not being read by Pixhawk v2.1 CUBE with PX4 stack .
My GPS module outputs GNGGA , GNGSA ,GPGSV , GQGSV , GAGSV , GBGSV , GNSVD,GNRMC , GNGST .
I am surprised not one of these messages are detected by Orange CUBE Px4 !
@sibujacob that’s not Cube specific, let’s follow up in Enabling GPS using NMEA - #3 by sibujacob
1 Like
Hi,
I am glad one developer is here to support the px4 forum…
…
Hi,
I am getting an error message of “Accel 1 clipping, not safe to fly” on cube orange with PX4 version 1.13.2 but when change the firmware to 1.11.0, Accel 1 clipping error doesn’t show up.
Is this an issue of the firmware?
Hi,
Are you saying here that the GPS works on Px4 v1.11.0 . I am currently on v1.12.3 .
What are you getting when you use the mavlink console with the command gps status . Does it give you both primary & secondary GPS readings .
That’s probably because accel clipping was not supported in v1.11. In any case, accel clipping means that the vibrations are too high and exceeding the measurable range of the accelerators. You need to check if anything of the Cube is loose (e.g. Cube loose on base board) and also check if any cables are inducing vibrations, or if propellers or other things are unbalanced causing vibrations.
There have been numerous improvements and bugfixes in v1.13.2, so I highly recommend to use that version over older ones, especially on hardware based on the STM32H7 like the CubeOrange.
1 Like
i am afraid that i will not be able to install the firmware properly through QGroundControl and the larger headache is the Herelink Radio Telemetry system which has a mind of its own. Currently the settings are satisfactory with my Quadcopter and i do not see major issues during flight.
PS:
Did the Px4 V.1.13.2 resolve the Mavlink console issue where the commands were not working through QGC.