“…other serial devices and the like that aren’t already supported in ArduPilot firmware and/or are best handled outside the autopilot”
Is there any way to have all the software on a single board computer without the flight controller?
The idea is to have the sensors distributed and come to a common point or a breakout board. The Navigator appears to be a breakout board compared to Pixhawk which can work as a standalone unit and with a companion computer. The Navigator would be great however I need more.
If your setup will indeed involve only I2C sensors then there doesn’t seem to be any reason to run an autopilot firmware, in which case your picture should work fine to just connect an I2C bus to your Raspberry Pi and run programs on the pi that communicate as appropriate with each sensor
If you’re needing to control a vehicle and wanting to use ArduSub then you’ll need a flight controller board with the appropriate IMU sensors and PWM outputs, which a Raspberry Pi alone does not have.
Sorry, I need more resources such as ability to use multiple same address I2C devices. I’ve chosen I2C as the primary communications protocol for the sensors.
The robot will use magnets to adhere, do you think the IMU / compass such as is on the Navigator or Pixhawk will be suitable?
I’ve moved this discussion to its own topic, since it’s not really about fibre optic tethering anymore.
Communication protocols are not made to handle duplicate addresses - that’s always either a development software/firmware problem (to reassign the duplicates until all addresses are unique, before the devices get connected together), or a hardware problem (to run separate signal wires that can separate any duplicate addresses into independent groups).
Since the Raspberry Pi is almost certainly the controller here, with the sensors all acting as peripherals that only respond when contacted, I expect the simplest hardware approach would be to use a shared clock line and then a multiplexer chip that allows using GPIO pins to switch between independent data lines. That approach requires your software to all operate through a single controller program (so it can ensure the Raspberry Pi isn’t trying to talk to multiple devices at the same time), but I can’t really see a way around that without having multiple I2C buses via separate communication chips or something.
It’s still unclear to me whether you’re actually planning to control a vehicle with the hardware we’re discussing. Is the idea that you have just Raspberry Pi + several I2C sensors, or will you actually have Raspberry Pi + autopilot board + actuators (thrusters, magnets, etc) + several I2C sensors?
If you’re using a magnetometer, permanent magnets can generally be calibrated for unless they’re overwhelmingly strong / nearby, but large fluctuations of electric or magnetic field (due to strong nearby electric current surges or moving close to and away from large metallic objects like ship hulls) can definitely cause significant issues with heading estimation. In such operating environments it’s generally a requirement to have some kind of vision and/or sonar system to help maintain a sense of direction.
Thanks for the feedback and for moving the topic to a more relevant thread.
It’s still unclear to me whether you’re actually planning to control a vehicle with the hardware we’re discussing.
The idea is to control a vehicle using BlueOS, RPi and perhaps a Pixhawk 2.4.8 in a rover configuration. The Navigator isn’t suitable so I am making my own board in its place. There are two motors, 4x IP cameras, 1x PTZ camera and plenty extra to facilitate add-ons such as sonar, DVL, CP, UT and the like. The primary comms protocol is I2C. As many of the sensors are the same, and thus the same address, I’m using I2C multiplexers for these. Uniquely addressed devices go straight onto the bus.
…permanent magnets can generally be calibrated for unless they’re overwhelmingly strong / nearby, but large fluctuations of electric or magnetic field (due to strong nearby electric current surges or moving close to and away from large metallic objects like ship hulls) can definitely cause significant issues with heading estimation.
The robot uses neodymium magnets, about 60 of them, to hold it on the surface. My experience with ROVs is the compass doesn’t like to be close to hulls, pipelines or metal structures and they go moggy. The problem is I’d like to use the robot in just such a space and need the heading to be stable without relying on visual aids. I’m looking for sensors that could be used in this environment and hopefully not having to fork out for a fibre optic gyro.
It doesn’t make much sense to run both a Pixhawk and a Navigator-equivalent at the same time, because both are intended to be flight controller boards. I suppose it would be possible to run a Pixhawk flight controller and a separate Raspberry Pi HAT that’s just intended for I2C multiplexing to simplify interfacing with your extra sensors.
It would also be possible to make your own HAT-style flight controller board (like the Navigator) but it may get complicated to either
implement all your peripheral sensor interfacing via libraries within ArduPilot, or
have some I2C channels that are used by the autopilot firmware and other I2C channels being used for external peripherals at the same time.
Yeah, my experience is the same.
Hmm - my main other suggestion would be a scanning/imaging sonar (like our Ping360), although that’s more of a referential/positional navigation aid rather than providing a direct heading estimate, so it’s reliant on visually detectable features in the scan, and slow enough vehicle rotations to be able to see how and where they move. It’s also not super cheap when compared to a magnetometer IC.
I suppose it may be possible to use multiple magnetometers to measure and try to account for the surrounding magnetic field, but I’m unsure how well that would work, and it’s not something that’s built into ArduSub so would presumably need to be implemented by you. The success would rely on the magnetometer ranges not being saturated by the nearby large magnetic things, which may be difficult to ensure.
I’m learning with the Pixhawk as it is affordable, however, I won’t use either as both are too limited due to the higher number of channels required to manage sensors and power distribution. I’m making PCBs with existing libraries as far as possible. The rest I’ll have to make.
The idea is to make a “flight controller” with code as required. I’ve started with a comms board that manages my PWM and I2C and a power distribution board that switches MOSFETs and monitors each channel’s voltage, current and power. I’ll use limited DIO/AIOs as I prefer using protocols such as I2C, RS232/485 and ethernet protocols.
I’ve adopted the PC104 standard as you get a lot of knowns along with quite a lot of readymade boards such as the fibre to copper, ethernet boards and PSU which stack reducing wiring. I’d like to move to a PC104 SBC. Not sure if anyone has suggestions or has done this before. I may experiment on an Odroid-N2 I have.
When will BlueOS gain the ability to switch relays? Due to the higher channel volumes, I have done away with relays and opted to use MOSFETs as the can be enabled with 3.3V. Do you know if the switching you intend to add to BlueOS would switch a MOSFET?
Alrighty then, sounds like an interesting project with a lot of work - feel free to discuss and ask questions here as relevant
You can track the progress here - we’ve just opened a pull request and it will be discussed in today’s ArduPilot dev call, so should hopefully be available in at least the development firmware this week.
Note that the Navigator’s PWM outputs (which will be configurable as relay-style outputs) are via a 16-output PCA9685 chip, which may not be what you’re using on your board.
The “relay” functionality is a bit of a misnomer, because there are no relays involved - it’s more to indicate that it’s a switchable signal / digital output that is either on or off. It should definitely switch a MOSFET, assuming the MOSFET has a switching voltage below 3.3V.
