This past Saturday was a clear crisp day, about -10 °C, perfect for testing out charging of the new battery (Dakota Lithium 12 V, 10 Amp-hr https://www.dakotalithiumbattery.com/12-v-10-ah-lithium-battery). Everything seemed to go well. The voltage jumped immediately from about 12.6 V to 13 V or so, and then steadily climbed throughout the afternoon until it reached the pre-programmed limit for the charger of 13.7 V. No fires or explosions, so far so good.
The next couple of days were spent building something of a crude wooden framework around AMOS for supporting the solar panel and possibly the thrusters as well.
The framework is not done yet, but if it works I'll make a better one out of plastic or aluminum.
On Monday, I finished up some code for the electronic compass module (https://www.robotshop.com/en/lsm303d-3-axis-accelerometer-compass.html). At first I was worried that it would prevent the cameras from working, since it was using the first I2C channel on the Raspberry Pi Compute module, which also happened to be used by the graphics processor for the cameras. Fortunately though, switching to the 2nd I2C channel worked fine, and did not interfere with the cameras (er the remaining working camera). It would be possible to try to calibrate this thing, but it appears to work well enough just by normalizing the two's complement digital outputs, so that you get acceleration and magnetic vectors in 3D, which can then be used to compute the device orientation (i.e. roll, pitch, and heading angles). The heading seems reasonably accurate when the device is close to horizontal, so it should be good enough for my navigation purposes. It won't matter too much I guess if AMOS heads off in a direction towards its intended target that is 20 ° or so off... by continuously collecting GPS data, the desired direction to the target can be refined and it should still arrive at the correct location.
Now back to the T200 thruster: yesterday had some hours of frustration initially, as the GPIO pin I was using to control the thruster speed did not seem to be working. Eventually I figured out that the electronic speed controller for the thruster (http://docs.bluerobotics.com/bescr3/) was pulling the output of my Compute module GPIO pin high all the time, i.e. the output from the Compute module was too weak. So it looks like the previous issue with the ill-advised camera repair may have damaged more than just the camera interface... perhaps the entire 2nd bank of GPIO has gone bad. Anyway, switching over to a GPIO pin from the 1st bank worked fine, with an impressive level of thrust when the output was cranked up. The output was fairly jerky and inconsistent though, stemming from the fact that the Raspbian operating system is not real time, so it is not really possible to control the output of a GPIO pin with software to microsecond precision. Fortunately though, the Compute module has a couple of PWM outputs that are perfectly suited to driving this sort of motor controller. Switching the software over to use these instead worked quite nicely, allowing for nice smooth control of the thruster speed. Here's a short Youtube video of a 5 second blast on one of the T200 thrusters: (https://www.youtube.com/watch?v=DUQfTLgzaeM) The video doesn't quite do the thruster justice, you really need to hold it in your hand to get a feel for how much force it exerts. Suffice to say that 2 of these things on the back of the boat should be enough to drive it through some pretty strong seas!
No comments:
Post a Comment