This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 1 Vote(s) - 4 Average
  • 1
  • 2
  • 3
  • 4
  • 5
ST1000 embedded TinyPilot - Projectlog & Questions
#1
After reading a lot about this great project and gaining some experience with Raspberry last summer we decided it was time for the next step. We had an old and broken ST1000 lying around, so converting that to PyPilot seems to be a nice project. Last weeks i have been reading and researching a lot. Deciphered some code and sketches, etc. Also made the first decisions toward the architecture I am gonna use. I would like to make a standalone pilot, so will embed al hardware in the ST1000's casing. After a lot of puzzling i think that i have puzzled out most of the connections. Resulting in this drawing:

[Image: Schematic_TinyPilot-ST1000-embedded_Shee...172037.svg]
Can someone say something about this sketch? Did I make wrong assumptions?

Still wondering how to connect the Arduino and Pi. They share the same powersource, so in theory can be directly connected. That would make USB the easiest solution, cause you don't have problems with the 3.3V vs 5V architecture. But having an opti-isolated I2C-bus seems to be nice for future additions. Especially a remote display, which I am planning to make in the future. Can anybody share how they have made an isolated I2C connection between Pi and Arduino?

Second point of interest is the Motorcontroller. A SimonK based controller seems to be the easiest solution. But they seem to be not so much up-to-the-job as their specs say. So I will probably need a 30A version for the little Mabuchi motor which maximally draws around 10A. Because I still have to manufacture some kind of print to accomodate all the stuff, maybe it's easier and more reliable to put an H-bridge on that print then? Can anybody share their H-bridge designs?

As you can see I have added a 6'th button. That's because the ST1000 has 6 buttons. Still deciding about functionality of these buttons. The display is another topic, I will start with the Nokia one because that's plug-and-play. But am hoping to use a display with the same size as the original display in the future. Probably a small O-led screen because they have good readability at small sizes.

Up next - in a few days - BOM and some pictures / practical sketches.

Hoping to have learned more about Motorcontrol, I2C-isolation and the faults in my sketches by then  Big Grin

Thanks a lot guys!
Reply
#2
Non isolated connection is not advisable due to electrical perturbations and potential grounds offset ; galvanic isolation is to be considered between arduino and pi. Sean is quite clear about that and it is with good reasons ; please do not cut corners.


Several solutions can be considered upon your needs :
  - isolated USB : insert a USB isolator (USB isolator from ADAFRUIT for example) between the arduino and the pi; the arduino can be powered by the isolator (you can disconnect Vin on the arduino). Simple but might be overkill (and expensive) though as the arduino/pi communication is serial at 38400 bauds. 
  - pair of opto-couplers between pi serial (GPIO pins 8 & 10) and the arduino serial (D0 & D1)
  - in case of a long distance (several meters) between the arduino and the pi (OK, it is not your case), consider using RS485 that provides industry grade communication. Isolation can be achieved for example through a MAXIM1480 and little set of side components. Being half-duplex, this solution requires TX driver control that can be either hardware (an oscillator such as a 555 adjusted to serial speed) or arduino and pi GPIO control. The later is easily implemented. Sean's code is fully compatible with the approach.

Considering the system integration described, a pair of opto-couplers would certainly be adequate and can take care of level conversion (3.3V-5V). Simple and not very expensive. Opto couplers implementation can be derived from the many break-out example given (Sparkfun, Adafruit, ...) and references. Stable and robust communication can be provided through darlington opto such as 2731 w/o the need for extra transistors and resistors that otherwise appears in some designs ; they are more expensive though.

Important note: the arduino Nano implements the D0 & D1 hardware serial to the on-board FT232RL through 1K line resistors (similar to Uno), you can then  use serial TTL  on D0 & D1 at the condition to not use the USB at the same time...

Regarding the schematics:
  - Please, consider inserting a fuse between the battery and your circuit
  - Not sure to understand how is connected the 12/5V power supply ; would expected it to be connected to V+ and V- ; is it a step down converter or something based on linear circuitry ?
  - Not sure to understand how the motor controller is connected to the battery, would expect Vin to be connected to battery +
  - Not sure to understand how the current shunt is implemented ; would expect it to be between V1- and motor controller GND (Sean's code is setting the arduino 328p A/D converters to 1.1V internal ref)
  - Battery potential resistor divider (560ohm & 1k) should be between battery V+ and V- with 560ohm on V- side
  - Rudder sensor does not appear ; it is not fundamental but might be worth to consider as it is taken into account in Sean's code
  - Unused arduino digital and analog input pins should be grounded
  - Your design does not show a clutch command (unless you are considering using the third unused channel of a reprogrammed ESC which is Sean's approach) ; should you need one you may want to to drive it through a digital pin followed by a MOSFET (IRLB8721 N-channel hexfet for example) with its companion resistors arduino-Gate (100ohm) and Gate-Source (10k) ; can drive several amps w/o dissipator
  - It might a good idea to insert a current limitation resistor in serie with you PilotEngaged LED ; LED require few mA, a 1K will do and will protect your arduino digital output (20mA continuous max per digital output).

Have fun,

Regards,

Damien Sailing
Reply
#3
Non isolated connection is not advisable due to electrical perturbations and potential grounds offset ; galvanic isolation is to be considered between arduino and pi. Sean is quite clear about that and it is with good reasons ; please do not cut corners.


Several solutions can be considered upon your needs :
  - isolated USB : insert a USB isolator (USB isolator from ADAFRUIT for example) between the arduino and the pi; the arduino can be powered by the isolator (you can disconnect Vin on the arduino). Simple but might be overkill (and expensive) though as the arduino/pi communication is serial at 38400 bauds. 
  - pair of opto-couplers between pi serial (GPIO pins 8 & 10) and the arduino serial (D0 & D1)
  - in case of a long distance (several meters) between the arduino and the pi (OK, it is not your case), consider using RS485 that provides industry grade communication. Isolation can be achieved for example through a MAXIM1480 and little set of side components. Being half-duplex, this solution requires TX driver control that can be either hardware (an oscillator such as a 555 adjusted to serial speed) or arduino and pi GPIO control. The later is easily implemented. Sean's code is fully compatible with the approach.

Considering the system integration described, a pair of opto-couplers would certainly be adequate and can take care of level conversion (3.3V-5V). Simple and not very expensive. Opto couplers implementation can be derived from the many break-out example given (Sparkfun, Adafruit, ...) and references. Stable and robust communication can be provided through darlington opto such as 2731 w/o the need for extra transistors and resistors that otherwise appears in some designs ; they are more expensive though.

Important note: the arduino Nano implements the D0 & D1 hardware serial to the on-board FT232RL through 1K line resistors (similar to Uno), you can then  use serial TTL  on D0 & D1 at the condition to not use the USB at the same time...

Regarding the schematics:
  - Please, consider inserting a fuse between the battery and your circuit
  - Not sure to understand how is connected the 12/5V power supply ; would expected it to be connected to V+ and V- ; is it a step down converter or something based on linear circuitry ?
  - Not sure to understand how the motor controller is connected to the battery, would expect Vin to be connected to battery +
  - Not sure to understand how the current shunt is implemented ; would expect it to be between V1- and motor controller GND (Sean's code is setting the arduino 328p A/D converters to 1.1V internal ref)
  - Battery potential resistor divider (560ohm & 1k) should be between battery V+ and V- with 560ohm on V- side
  - Rudder sensor does not appear ; it is not fundamental but might be worth to consider as it is taken into account in Sean's code
  - Unused arduino digital and analog input pins should be grounded
  - Your design does not show a clutch command (unless you are considering using the third unused channel of a reprogrammed ESC which is Sean's approach) ; should you need one you may want to to drive it through a digital pin followed by a MOSFET (IRLB8721 N-channel hexfet for example) with its companion resistors arduino-Gate (100ohm) and Gate-Source (10k) ; can drive several amps w/o dissipator
  - It might a good idea to insert a current limitation resistor in serie with you PilotEngaged LED ; LED require few mA, a 1K will do and will protect your arduino digital output (20mA continuous max per digital output).

Have fun,

Regards,

Damien Sailing
Reply
#4
Thanks a lot for your input!

Fusing has already been taken care of at the connections panel, so not in the schematic.

I don't like to cut corners. But still don't really understand why isolation is needed in this situation. With Arduino and Pi next to each other and sharing the same powersupply. Especially when using an ESC with integrated optocoupling. But tossing it in isn't a big deal. Using Serial is better practice in that case then using I2C?

Made a mistake in my 12V input connections indeed, probably a line got accidentally removed. That messes up a lot, all the ESC, shunt and voltagedivider circuits aren't right now indeed. Will update that soon!

ST1000 doesn't have a clutch. Maybe I'll add a rudder sensor to the rudderstock in the future. Adding the voltage divider and connections already would be wise indeed! Although I might also end up using an NMEA connection over WiFi for that. Making the data also available when pilot is powered of.

Will ground the digital pins as well then.

Completely forgot the resistor for the LED, because a lot of LED lighting has that already built in these days. But wise addition. Already experienced that as a child, when I connected some scrapped LED's to an old computer powersupply. They shined very very bright, for about a second Big Grin But I will probably leave that LED out completely, because it means drilling an extra hole in the ST1000 casing.

Fiddled around mocking everyting up in the casing yesterday. All the pieces of the puzzle are slowly coming together. Will post a few pictures, together with an updated schematic, in a few days!
Reply
#5
(2019-03-15, 05:57 PM)FMJ Wrote: After reading a lot about this great project and gaining some experience with Raspberry last summer we decided it was time for the next step. We had an old and broken ST1000 lying around, so converting that to PyPilot seems to be a nice project. Last weeks i have been reading and researching a lot. Deciphered some code and sketches, etc. Also made the first decisions toward the architecture I am gonna use. I would like to make a standalone pilot, so will embed al hardware in the ST1000's casing. After a lot of puzzling i think that i have puzzled out most of the connections. Resulting in this drawing:

[Image: Schematic_TinyPilot-ST1000-embedded_Shee...172037.svg]
Can someone say something about this sketch? Did I make wrong assumptions?

Not sure about the shunt wiring or the extra uC, what is it for?

Quote:Still wondering how to connect the Arduino and Pi. They share the same powersource, so in theory can be directly connected. That would make USB the easiest solution, cause you don't have problems with the 3.3V vs 5V architecture. But having an opti-isolated I2C-bus seems to be nice for future additions. Especially a remote display, which I am planning to make in the future. Can anybody share how they have made an isolated I2C connection between Pi and Arduino?

I opto isolate the uart not i2c. It is much simpler because each wire goes in one direction.

Quote:Second point of interest is the Motorcontroller. A SimonK based controller seems to be the easiest solution. But they seem to be not so much up-to-the-job as their specs say. So I will probably need a 30A version for the little Mabuchi motor which maximally draws around 10A. Because I still have to manufacture some kind of print to accomodate all the stuff, maybe it's easier and more reliable to put an H-bridge on that print then? Can anybody share their H-bridge designs?

Yes, I recommend at least 20A, or 30A if they are going to run efficiently and reliable if the motor draws normally a few amps.

Eventually, yes I changed to just put an H bridge. It is not really easier because a lot more parts to assemble, but no need to program multiple uC and also much lower idle current, and even better mosfets for more efficiency.

I hope to post the schematic I"m using soon when I update my site.

Quote:As you can see I have added a 6'th button. That's because the ST1000 has 6 buttons. Still deciding about
I recommend you don't wire the buttons to gnd, but to a 1k resistor to ground. That way if the program accidentally drives them when a button is pressed there is never a short.

The wire for the 6th button is already used by the lcd, so I would be careful of this. There are many more gpio available after 26. I intend to use these for more buttons in the future.

What are your 6 buttons, what do you expect the 6th button to do?

Do you have a plan for mounting the display so it can be read?
Quote:functionality of these buttons. The display is another topic, I will start with the Nokia one because that's plug-and-play. But am hoping to use a display with the same size as the original display in the future. Probably a small O-led screen because they have good readability at small sizes.
Let me know if you find a good one. the oled I think require a lot of power to be readable in sunlight.
Quote:Up next - in a few days - BOM and some pictures / practical sketches.

Hoping to have learned more about Motorcontrol, I2C-isolation and the faults in my sketches by then  Big Grin

Thanks a lot guys!
Reply
#6
Thanks for your input, Sean! Together with damien's feedback most of my faults are probably gone now.

I didn't dive in the display driving code too deep. Just expected it to be simply SPI-driven. But after inspecting ugfx.cpp I understand your comment about physical pins 22 (and 24) being used for the display's RST (and DC). While this functions can easily be mapped to other pin's it definately makes sense to just stay with 22 and 24.

Another questing regarding the display: how are you controlling the backlight? Just wiring it to 3v3 (via a resistor)? Or are you using a switch and / or driving it by a (probably even PWM'ed) pin so it can be software controlled?

And yes, I am planning to mount it behind the 'window' of the ST1000 casing, so it can be read. I guestimated the used screen area of the Nokia-style display to around 20mm in height. As I measured the window to be roughly 19,5mm in height, is must be possible to install the display in such a way that it is readable enough to be of use.

Regarding a possible future O-led display: that's just a wild idea for the future. Firstly I'd like to have a working pilot. But I surely will keep you guys posted.

Below is an updated schematic with all the feedback from this topic taken into account. It doesn't look pretty, but has given me a lot of insight in the architecture of the whole system. Probably it will also help some other people understanding the system as well. So happy to share it.


Wasn't completely sure about the rudder sensor, I assumed it to be just a 5k potentiometer wired as voltage divider. Is that correct?

Button 6 is left out for now, as I am planning a second version of the schematic, which takes into account my thoughts about the physical layout that suits my situation. Button number six will appear again in that drawing Wink . Although I am not sure about the usage of it for now. But when I have a casing with 6 buttons in it, I would like to the option to use all 6 some day..



[Image: PyPilot-Schematic-0-2-FMJ.svg]

Feedback to this drawing still appreciated Smile
Reply
#7
(2019-03-20, 05:52 PM)FMJ Wrote: Thanks for your input, Sean! Together with damien's feedback most of my faults are probably gone now.

I didn't dive in the display driving code too deep. Just expected it to be simply SPI-driven. But after inspecting ugfx.cpp I understand your comment about physical pins 22 (and 24) being used for the display's RST (and DC). While this functions can easily be mapped to other pin's it definately makes sense to just stay with 22 and 24.

Another questing regarding the display: how are you controlling the backlight? Just wiring it to 3v3 (via a resistor)? Or are you using a switch and / or driving it by a (probably even PWM'ed) pin so it can be software controlled?

And yes, I am planning to mount it behind the 'window' of the ST1000 casing, so it can be read. I guestimated the used screen area of the Nokia-style display to around 20mm in height. As I measured the window to be roughly 19,5mm in height, is must be possible to install the display in such a way that it is readable enough to be of use.

Regarding a possible future O-led display: that's just a wild idea for the future. Firstly I'd like to have a working pilot. But I surely will keep you guys posted.

Below is an updated schematic with all the feedback from this topic taken into account. It doesn't look pretty, but has given me a lot of insight in the architecture of the whole system. Probably it will also help some other people understanding the system as well. So happy to share it.


Wasn't completely sure about the rudder sensor, I assumed it to be just a 5k potentiometer wired as voltage divider. Is that correct?

Button 6 is left out for now, as I am planning a second version of the schematic, which takes into account my thoughts about the physical layout that suits my situation. Button number six will appear again in that drawing Wink . Although I am not sure about the usage of it for now. But when I have a casing with 6 buttons in it, I would like to the option to use all 6 some day..



[Image: PyPilot-Schematic-0-2-FMJ.svg]

Feedback to this drawing still appreciated Smile

I used NTC not PTC thermistors, and they are wired to ground with 100k to 5v, you have this opposite.  R2 must be 10k not 1k.
Reply
#8
(2019-03-20, 09:14 PM)seandepagnier Wrote: I used NTC not PTC thermistors, and they are wired to ground with 100k to 5v, you have this opposite.  R2 must be 10k not 1k.

Thanks for your feedback again. Corrected these things and made the drawing a bit more clean and clear. Added isolated UART between Pi an Arduino as well.

Isolation between Arduino and ESC might be problematic? As the voltage-sensing wires compare their measurement to ground. Which needs to be a common ground then?

[Image: Schematic_TinyPilot-ST1000-embedded_Shee...021027.svg]

Soon in this theatre: how to put all this into an ST1000. Preferably in a sturdy and elegant way.
Reply
#9
It looks good. I don't use isolation between the arduino and esc so you should be ok there. Which esc are you using? Are you using my brushed_tgy for simonk compatible ESC to run as brushed controller?

Not sure the 1k is needed on the end stops, but probably won't hurt.

Usually you don't need end stops and rudder feedback, but either, both or neither are fully supported. It might be useful to prevent the overcurrent triggering if the rudder feedback fails.

How are you doing the rudder feedback? Is it inside the st1000? A linear potentiometer? Usually these don't have enough travel.

You might have to change the backlight pin on the 5110 to either gnd or vcc depending on the module, I have seen both ways. You don't need a resistor if it's 3.3v to the backlight, usually the modules have resistors built in, but would be nice to use 10-30 ohms to limit current since it doesn't need to be so bright, you can experiment.

Keep us posted, and pictures would be great.
Reply
#10
Thanks Sean!

Pictures will follow soon!

No rudderfeedback for now, although your idea with a lineair potentiometer spinned through my head as well. For now I will just lead out two wires. Giving me the possibility to add a pot to the rudderstock later on. No capacitors or trimming pot's needed on either side of the rudderangle pot?

As for the ESC, will use some 30A SimonK compatible brushless ESC indeed. Will figure out which brushed firmware works best after I have received the part. But I am definitely playing the safe card here, choosing something that has already been proven by you or others.

First and foremost I wanted tot make a complete overview of the generic system. This has given me lots of insight and will probably help others too. From now on I will make some changes to this, adapting it to my specific situation Big Grin
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)