Flexibility in Satellite Toolbox

Is there any way to both add and visualize customized gimbals and/or sensors to the satellite toolbox?

My particular scenario is looking at putting a camera on a platform but limiting the gimbal angles and field-of-view non-symmetrically.

• The FOV is different in along and cross track directions (not conical). While other toolboxes have "rectangular" FOVs, I don't see the capability in the satellite toolbox. Functions could be added to filter, but they won't visualize properly.
• My gimbals are pitch and roll rather than azimuth and elevation. I can compute the corresponding angles, but wondering if there's a way to change how gimbals are controlled.
• My gimbals don't have complete freedom to move throughout the entire hemisphere. Again, results can be filtered but the visualization doesn't correspond.

Is there currently (or possibly in the future) a path to customizing gimbals or sensors (with visualization) in this toolbox? Maybe an API?

Answer 1

[Umar]

Hi @Kevin,

I came across your post on MATLAB Central and wanted to share some thoughts after doing extensive research.

On the rectangular FOV front — you're right, it's not there. The toolbox only ships with ConicalSensor, which uses a single MaxViewAngle to define a symmetric circular cone. You can technically build a custom sensor class with separate along-track and cross-track angles, but the frustrating part is exactly what you flagged: it won't plug into the native fieldOfView() renderer. The 3D viewer just doesn't have a hook for custom footprint shapes, so the visualization stays broken even if your math is correct. I haven't found a clean solution here either.

For the pitch/roll gimbal issue, there is a partial workaround worth knowing about. The pointAt() function is locked to azimuth/elevation, but if you pre-compute your pitch/roll commands externally and convert them to quaternions or equivalent az/el pairs, you can feed that into a timetable and drive the gimbal that way. It's extra legwork but it does actually visualize properly. Also worth noting — the MountingAngles property on the Gimbal object accepts yaw, pitch, and roll in the parent body frame, which can help set a static offset for the gimbal body even if it doesn't solve dynamic steering in your preferred convention.

The constrained travel range is probably the most frustrating of the three. There's simply no property on the Gimbal object for angular limits — no MaxPitchAngle, no exclusion zone, nothing. Like you said, you can filter the access results in post-processing, but the viewer will keep drawing the footprint as if the gimbal can freely sweep the full hemisphere. The visualization and the reality just don't match.

As for a future API — I checked the docs thoroughly and there's no public extensibility interface announced. The object hierarchy (Satellite, Gimbal, ConicalSensor, Access, etc.) is essentially closed. The closest thing MathWorks suggests for non-standard scenarios is computing everything in Simulink via the Spacecraft Dynamics block and importing it back via timetables, which handles the numerical side but still doesn't solve the visualization rendering gap you're describing.

Honestly, I think your post is highlighting a real and legitimate gap in the toolbox. If you haven't already, it's probably worth filing a formal product enhancement request directly with MathWorks — the more specific the use case (camera, asymmetric FOV, pitch/roll gimbal, constrained travel), the better. Cases like yours tend to carry weight when the product team is prioritizing roadmap features.

Hope some of this is at least useful context. Would be curious to hear what direction you end up going with it.