Posts made by JoeC

@Zachary-Lowell-0 Thanks Zach, this does answer. I have been used to ROS1/MAVROS where sending position targets was completely ignored unless in offboard mode so my node would typically blast setpoint_raw messages whether in offboard or not (in part to keep the option of switching to 'offboard' mode "alive").

I will proceed from now on in ROS2/MicroXRCE assuming I should constantly send offboard control mode messages, but send traj setpoints only when offboard mode is confirmed. I appreciate the clarification on why this is.

-Joe

Hello, I see on the downloads section there are CAD files for several VOXL1-era PCBs, etc. Any chance you might consider making the VOXL2 flight deck .stl 3D printable files available? I'm kludging together a drone from ModalAI boards and parts and 3D printing the same VOXL2 flight deck parts would save a little design time. Thanks!

-Joe

@Eric-Katzfey I have not, but I can do that.

Re: VOXL2 mavlink topic streaming modifications

@Eric-Katzfey Hi Eric, would you mind advising on the current location for the startup script with the newer SDK 1.1.X setup? I believe the above topic applies to the SDK 0.9.5.

Thanks!

-Joe

Hello, I've noticed with PX4 1.14 that sending TrajectorySetpoint messages causes "jittery", nearly unstable, behavior unless vehicle is in "offboard" mode. For background, consider there are two flight modes set to choose from: "Position" and "Offboard"; a custom modification of the px4_ros_com example has been created that removes programmatic arming and programmatic flight mode changes and only continually publishes TrajectorySetpoint and OffboardControlMode messages at 20 Hz. The "offboard_mode" field in voxl-vision-hub.conf has been set to "off" so there shouldn't be a conflict there.

Expected behavior: PX4 stack should ignore TrajectorySetpoint and OffboardControlMode messages while vehicle flight mode is in "position" control, then should start following the trajectory setpoints according to the offboardcontrolmode settings when flipped into "offboard"mode.

Observed behavior: When sending TrajectorySetpoint messages in "position" mode, vehicle becomes extremely jittery with reduced controllability, as if it's trying to implement these setpoints. Sending OffboardControlMode messages does NOT affect behavior whether in "position" or "offboard" mode and hence can be used as the "offboard heartbeat signal" to keep offboard mode active. Sending TrajectorySetpoint messages in offboard mode works as expected. This has been observed using both the VOXL2+VOXL2IO+m500 frame as well as the Starling.

Question: Are we to expect in PX4 1.14 that this behavior is correct and we need to only send TrajectorySetpoint messages as soon as offboard mode is switched on or is this a bug in the firmware?

Thanks!

-Joe

@Eric-Katzfey Thanks for your help. I've confirmed that I was able to use J19 with the "RC=M0065_SBUS" option successfully. Hence, if no VOXL_ESC, one should use J18 for the VOXL2 IO board and if there IS a VOXL_ESC board, one should use the J19 for the VOXL2 IO board. The firmware seems to be "smart" enough to figure out as long as /etc/modalai/voxl-px4.conf is set as you suggested.

-Joe

@Eric-Katzfey Thanks Eric, Apologies, I needed to also indicate that I've got a VOXL2 IO board in this as well. Hence, I should ask, "Can J19 be used as a UART that goes to a VOXL2 IO board?"

-Joe

Hello, I'm trying to retrofit an early Sentinel design with an S.BUS receiver. The Sentinel has been upgraded to the most recent SDK 1.1.3. In this model, J18 is taken by the VOXL ESC board. A Spektrum receiver cable is split between J10 and J19 and going to the older Sentinel Spektrum bind board. If I could utilize the J19 as an S.BUS input, that might be the way to go? I'm not sure how to ensure the PX4 stack is looking for the RC S.BUS signal on J19 rather than J18 like usual. Any thoughts appreciated, thanks!

-Joe

Re: IMX412 full resolution support at 12MP not working

Hi Travis @modaltb , I took your prior advice and am trying to work with an IMX412 on the VOXL2 flight deck running SDK 1.1.1. I've played around with a couple different physical connections and for software the 'camera-server-config-helper', the 'voxl-configure-cameras' script, and simply modifying the voxl-camera-server.conf file directly and simply not able to get imagery. Interestingly, I get either a "ERROR: Found zero cameras connected, need at least one." or alternatively, "ERROR: Camera 3 failed to find supported stream config: 1920x1080 ERROR: Failed to start camera: hires" I also can't get the "--imx412" arg to work with the voxl-configure-cameras script so I'm guessing that's deprecated?

If it's not too much trouble, would you kindly post an example that definitely works? Maybe using camera configuration 8 ("hires only") or 11 ("sentinel")?

-Joe

@modaltb ok thanks! I'll proceed with the 412 variant.

Re: VOXL 2 IMX377/IMX412 support and configuration

Hi Travis @modaltb , this is related to another older topic that assuredly covered an older SDK. I'm using a standard VOXL2 flight deck (SDK 1.1.1 now) and replaced the stock hires imager with an IMX377. I've been strolling through the configuration wiki pages and have determined a couple things for sure: the camera-server-config-helper does not like the 'imx377' ' as an option and manually modifying the /etc/modalai/voxl-camera-server.conf file does not appear to work. Has there been any movement between this older thread on the IMX377 and now and/or updates to the 1.1.1 SDK that might suggest the IMX377 will work in one of the ports?

-Joe

@Eric-Katzfey Thanks Eric 1 question and 1 comment on this. question: Just to verify, I now need to update the VOXL IO firmware as well as of 1.1.1, correct? It seems like the correct firmware update is here: https://docs.modalai.com/voxl2-io-firmware/ comment: I'm getting a "no mags detected" error upon connection to QGC; changing SYS_HAS_MAG parameter to 0 at least removes the error but doesn't help with yaw estimation (naturally).

@Eric-Katzfey Hi Eric, Our team is looking forward to this as well using the VOXL2 flight deck - SBUS input to VOXL2 IO - VOXL2 IO PWM output to m500 ESCs setup. I note when flashing with the SDK 1.1.0 and then using 'apt update && apt dist-upgrade -y' after flashing, then voxl-suite is advertised as "voxl-suite 1.1.1" at the banner screen when logging in via adb or ssh. It was advertised as "voxl-suite 1.1.1-beta" yesterday. Does flashing with SDK 1.1.0 and then running 'apt dist-upgrade' do the same thing as what you are planning to release officially in a few days?

@Moderator Apologies for the lack of clarity. It's mentioned in an earlier version of the SDK (pre SDK 0.9.5), here in fact: https://docs.modalai.com/voxl-camera-server-0_9/ (search for "flip"). I added "flip" to the .conf file, but it didn't have an effect it seems. I haven't checked out 1.0 or 1.1 yet (I'm holding off on going past 0.9.5 until VOXL IO board is supported) but I'm hoping such basic image manipulation is available in those versions as well.

Hello, I recall there used to be an option to flip or reverse the image prior to being published to the MPA by using an argument ("flip") in the voxl-configure-cameras.conf file. In SDK 0.9.5, it seems as though this no longer works? Due to ribbon length, I've had to integrate a hires camera upside down and would like to invert the image prior to going to all the other built-in image processing functions. Perhaps I need to do this by directly modifying voxl-camera-server now? Any advice helps, thanks!

-Joe

@tom Confirmed, installing the normal way doesn't corrupt the apt repo..... THANKS!

Hello, with the VOXL1 m500s, I was advised to set "SYS_AUTOSTART" to 0 from 4001 to prevent full booting of the px4 stack and, hence, prevent the ESCs from beeping after a number of minutes.

With the VOXL2, using the VOXL2 I/O board and m500 ESCs and motors, setting SYS_AUTOSTART to 0 is probably not the best way to prevent the beeping as doing so results in difficulty connecting to QGroundcontrol in some cases and changing it back. In fact, it seems that when setting SYS_AUTOSTART to 0 and rebooting, the parameter seems to be erased entirely? What do folks do at ModalAI when working long term with a drone on the bench and want to prevent ESC beeping?

-Joe

@tom I've narrowed this behavior down! On the VOXL2 using the 0.9.5 image: Do a factory flash, connect to internet via 'voxl-wifi station', then 'apt update && apt dist-upgrade'. You'll note everything is fine. Then run 'voxl-configure-docker-support' and type '1' for all prompts. Immediately after this, you'll note that 'apt update' is broken and the error, "Download is performed unsandboxed as root as file '/data/voxl-suite-offline-packages/./InRelease' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)" is given. Something is up when running voxl-configure-docker-support that breaks how apt normally operates....

-Joe

@tom Hi Tom, I was using Ubuntu 20.04 as the dev computer OS.

@tom Thanks Tom! This "wipe everything flag" is what I was hoping for. I just tried on my Sentinel and got the same error BUT.... That said, my next step was to try a different COMPUTER and that worked! So something is messed up in the configuration of the laptop itself I was using.

-Joe