'Engineers of Innovation Wiki' - User contributions [en]

CAN-bus

2026-05-06T14:31:10Z

Aran Dokoupil: /* CAN-bus pinout */

The communication between the electronics within the [[Solar boat (boii)|solar boat]] is build upon the CAN-bus protocol, where the [[datalogger]] logs the CAN messages. Pinout of our Binder connectors are:

== CAN-bus ID overview ==
<syntaxhighlight lang="markdown">
0x100 EoI Battery start
0x10F EoI Battery end

0x200 EoI GNNS info, u8 fix (bool); u8 sats; u8 sats used
0x201 EoI GNNS f32 speed, kmh; f32 direction, degrees
0x202 EoI GNNS f64 Latitude, degrees
0x203 EoI GNNS f64 Longitude, degrees
0x204 EoI GNNS date time, u16 year, u8 month, u8 day, u8 hour, u8 minute, u8 second

0x400 Gan MPPT R0 : Vin, Iin, Vout, Iout
0x401 Gan MPPT R0 : Mode, Fault, Enabled, TBoard, THS
0x410 Gan MPPT R1
0x411 Gan MPPT R1
...
0x470 Gan MPPT R7
0x471 Gan MPPT R7
0x480 Gan MPPT F0
0x481 Gan MPPT F0
...
0x4F0 Gan MPPT F7
0x4F1 Gan MPPT F7

0x4E6 Gan MPPT Baseboard Front
0x4EE Gan MPPT Baseboard Rear

0x700 MPPT start
0x77F MPPT end

0x0900 THROTTLE To VESC
0x1337 THROTTLE Status

0x0909 VESC Status message 1
0x0E09 VESC Status message 2
0x0F09 VESC Status message 3
0x1009 VESC Status message 4
0x1B09 VESC Status message 5
</syntaxhighlight>

== CAN-bus pinout ==
{| class="wikitable"
|+ Colours of the Standard Binder CAN Cable and its pinout
|-
! Binder Connector pin Number !! Wire Colour !! Signal on wire
|-
| 1 ||style="background: #83603A;"| Brown || 24v Power
|-
| 2 ||style="background: #FFFFFF;"| White || CAN H
|-
| 3 ||style="background: #0065B2;"| Blue || CAN L
|-
| 4 ||style="background: #241F21;color:white;"| Black || Ground
|-
| 5 ||style="background: #B2B3B7;"| Gray || Safety

|}

== Battery (MG) CAN-format (No longer used) ==
As of now the MG electronics [[battery]] is used in the [[Solar boat (boii)|solar boat]]. Although a new battery is being developed, this MG battery is still in use (as of September '22). Therefore the battery format is given here below.
{| class="wikitable"
|+
!Node-ID
!Index
!Subindex
!Data
!Type
!Resolution
|-
|0x302
|0x2005
|0x01
|Voltage <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|0x02
|Current <code>[A]</code>
|int16_t
|10 <code>[mA/LSB]</code>
|-
|
|
|0x03
|Current Discharge <code>[A]</code>
|int16_t
|10 <code>[mA/LSB]</code>
|-
|
|
|0x04
|Current Charge <code>[A]</code>
|int16_t
|10 <code>[mA/LSB]</code>
|-
|
|
|0x05
|State-of-Charge <code>[%]</code>
|int8_t
|1 <code>[%/LSB]</code>
|-
|
|
|0x06
|
|
|
|-
|
|
|0x07
|Time to Go <code>[min]</code>
|uint16_t
|1 <code>[min/LSB]</code>
|-
|
|
|
|
|
|
|-
|0x402
|0x2005
|0x09
|Cell Temperature High <code>[°C]</code>
|int8_t
|1 <code>[°C/LSB]</code>
|-
|
|
|0x0A
|
|
|
|-
|
|
|0x0B
|Cell Temperature Low <code>[°C]</code>
|int8_t
|1 <code>[°C/LSB]</code>
|-
|
|
|0x0C
|Cell Voltage High <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|0x0D
|Cell Voltage Low <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|0x0E
|BMS State
|uint32_t
|
|-
|
|
|0x0F
|Temperature Collection <code>[°C]</code>
|4x uint8_t
|1 <code>[°C/LSB]</code>
|-
|
|
|
|
|
|
|-
|0x482
|0x2000
|Cell nr
|Cell <code>[Cell_nr]</code> Voltage <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|
|
|
|
|-
|0x202
|Don't Care
|Don't Care
|Power Level <code>[%]</code>
|uint8_t
|1 <code>[%/LSB]</code>
|}

CAN-bus

2026-05-06T14:29:20Z

Aran Dokoupil: /* CAN-bus ID overview */

The communication between the electronics within the [[Solar boat (boii)|solar boat]] is build upon the CAN-bus protocol, where the [[datalogger]] logs the CAN messages. Pinout of our Binder connectors are:

== CAN-bus ID overview ==
<syntaxhighlight lang="markdown">
0x100 EoI Battery start
0x10F EoI Battery end

0x200 EoI GNNS info, u8 fix (bool); u8 sats; u8 sats used
0x201 EoI GNNS f32 speed, kmh; f32 direction, degrees
0x202 EoI GNNS f64 Latitude, degrees
0x203 EoI GNNS f64 Longitude, degrees
0x204 EoI GNNS date time, u16 year, u8 month, u8 day, u8 hour, u8 minute, u8 second

0x400 Gan MPPT R0 : Vin, Iin, Vout, Iout
0x401 Gan MPPT R0 : Mode, Fault, Enabled, TBoard, THS
0x410 Gan MPPT R1
0x411 Gan MPPT R1
...
0x470 Gan MPPT R7
0x471 Gan MPPT R7
0x480 Gan MPPT F0
0x481 Gan MPPT F0
...
0x4F0 Gan MPPT F7
0x4F1 Gan MPPT F7

0x4E6 Gan MPPT Baseboard Front
0x4EE Gan MPPT Baseboard Rear

0x700 MPPT start
0x77F MPPT end

0x0900 THROTTLE To VESC
0x1337 THROTTLE Status

0x0909 VESC Status message 1
0x0E09 VESC Status message 2
0x0F09 VESC Status message 3
0x1009 VESC Status message 4
0x1B09 VESC Status message 5
</syntaxhighlight>

== CAN-bus pinout ==
{| class="wikitable"
|+ Colours of the Standard Binder CAN Cable and its pinout
|-
! Binder Connector pin Number !! Wire Colour !! Signal on wire
|-
| 1 ||style="background: #83603A;"| Brown || 24v Power
|-
| 2 ||style="background: #FFFFFF;"| White || CAN H
|-
| 3 ||style="background: #0065B2;"| Blue || CAN L
|-
| 4 ||style="background: #241F21;color:white;"| Black || Ground
|-
| 5 ||style="background: #B2B3B7;"| Gray || Safety

|}

Note that the M12 connectors have a different pinout and thus different colour wires. To make compatibility between systems easier the binder connectors are soldered with the wrong colored wires so that plugging in a M12 device results in the right signals being passed to the Binder connector. This Compatibility pinout is shown below:

{| class="wikitable"
|+ NON-STANDARD!! Colours when connecting an M12 cable to a binder connector NON-STANDARD!!
|-
! Binder Connector pin Number !! Wire Colour !! Signal on wire
|-
| 1 ||style="background: #FFFFFF;"| White || 24v Power
|-
| 2 ||style="background: #241F21;color:white;"| Black || CAN H
|-
| 3 ||style="background: #B2B3B7;"| Gray || CAN L
|-
| 4 ||style="background: #0065B2;"| Blue || Ground
|-
| 5 ||style="background: #83603A;"| Brown || Safety
|-

|}

== Battery (MG) CAN-format (No longer used) ==
As of now the MG electronics [[battery]] is used in the [[Solar boat (boii)|solar boat]]. Although a new battery is being developed, this MG battery is still in use (as of September '22). Therefore the battery format is given here below.
{| class="wikitable"
|+
!Node-ID
!Index
!Subindex
!Data
!Type
!Resolution
|-
|0x302
|0x2005
|0x01
|Voltage <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|0x02
|Current <code>[A]</code>
|int16_t
|10 <code>[mA/LSB]</code>
|-
|
|
|0x03
|Current Discharge <code>[A]</code>
|int16_t
|10 <code>[mA/LSB]</code>
|-
|
|
|0x04
|Current Charge <code>[A]</code>
|int16_t
|10 <code>[mA/LSB]</code>
|-
|
|
|0x05
|State-of-Charge <code>[%]</code>
|int8_t
|1 <code>[%/LSB]</code>
|-
|
|
|0x06
|
|
|
|-
|
|
|0x07
|Time to Go <code>[min]</code>
|uint16_t
|1 <code>[min/LSB]</code>
|-
|
|
|
|
|
|
|-
|0x402
|0x2005
|0x09
|Cell Temperature High <code>[°C]</code>
|int8_t
|1 <code>[°C/LSB]</code>
|-
|
|
|0x0A
|
|
|
|-
|
|
|0x0B
|Cell Temperature Low <code>[°C]</code>
|int8_t
|1 <code>[°C/LSB]</code>
|-
|
|
|0x0C
|Cell Voltage High <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|0x0D
|Cell Voltage Low <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|0x0E
|BMS State
|uint32_t
|
|-
|
|
|0x0F
|Temperature Collection <code>[°C]</code>
|4x uint8_t
|1 <code>[°C/LSB]</code>
|-
|
|
|
|
|
|
|-
|0x482
|0x2000
|Cell nr
|Cell <code>[Cell_nr]</code> Voltage <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|
|
|
|
|-
|0x202
|Don't Care
|Don't Care
|Power Level <code>[%]</code>
|uint8_t
|1 <code>[%/LSB]</code>
|}

CAN-bus

2026-05-01T05:41:15Z

Aran Dokoupil: /* CAN-bus ID overview */

The communication between the electronics within the [[Solar boat (boii)|solar boat]] is build upon the CAN-bus protocol, where the [[datalogger]] logs the CAN messages. Pinout of our Binder connectors are:

== CAN-bus ID overview ==
<syntaxhighlight lang="markdown">
0x100 EoI Battery start
0x10F EoI Battery end

0x200 EoI GNNS info, u8 fix (bool); u8 sats; u8 sats used
0x201 EoI GNNS f32 speed, kmh; f32 direction, degrees
0x202 EoI GNNS f64 Latitude, degrees
0x203 EoI GNNS f64 Longitude, degrees
0x204 EoI GNNS date time, u16 year, u8 month, u8 day, u8 hour, u8 minute, u8 second

0x400 Gan MPPT R0 : Vin, Iin, Vout, Iout
0x401 Gan MPPT R0 : Mode, Fault, Enabled, TBoard, THS
0x410 Gan MPPT R1
0x411 Gan MPPT R1
...
0x470 Gan MPPT R7
0x471 Gan MPPT R7
0x480 Gan MPPT F0
0x481 Gan MPPT F0
...
0x4F0 Gan MPPT F0
0x4F1 Gan MPPT F0

0x4E6 Gan MPPT Baseboard Front
0x4EE Gan MPPT Baseboard Rear

0x700 MPPT start
0x77F MPPT end

0x0900 THROTTLE To VESC
0x1337 THROTTLE Status

0x0909 VESC Status message 1
0x0E09 VESC Status message 2
0x0F09 VESC Status message 3
0x1009 VESC Status message 4
0x1B09 VESC Status message 5
</syntaxhighlight>

== CAN-bus pinout ==
{| class="wikitable"
|+ Colours of the Standard Binder CAN Cable and its pinout
|-
! Binder Connector pin Number !! Wire Colour !! Signal on wire
|-
| 1 ||style="background: #83603A;"| Brown || 24v Power
|-
| 2 ||style="background: #FFFFFF;"| White || CAN H
|-
| 3 ||style="background: #0065B2;"| Blue || CAN L
|-
| 4 ||style="background: #241F21;color:white;"| Black || Ground
|-
| 5 ||style="background: #B2B3B7;"| Gray || Safety

|}

Note that the M12 connectors have a different pinout and thus different colour wires. To make compatibility between systems easier the binder connectors are soldered with the wrong colored wires so that plugging in a M12 device results in the right signals being passed to the Binder connector. This Compatibility pinout is shown below:

{| class="wikitable"
|+ NON-STANDARD!! Colours when connecting an M12 cable to a binder connector NON-STANDARD!!
|-
! Binder Connector pin Number !! Wire Colour !! Signal on wire
|-
| 1 ||style="background: #FFFFFF;"| White || 24v Power
|-
| 2 ||style="background: #241F21;color:white;"| Black || CAN H
|-
| 3 ||style="background: #B2B3B7;"| Gray || CAN L
|-
| 4 ||style="background: #0065B2;"| Blue || Ground
|-
| 5 ||style="background: #83603A;"| Brown || Safety
|-

|}

== Battery (MG) CAN-format (No longer used) ==
As of now the MG electronics [[battery]] is used in the [[Solar boat (boii)|solar boat]]. Although a new battery is being developed, this MG battery is still in use (as of September '22). Therefore the battery format is given here below.
{| class="wikitable"
|+
!Node-ID
!Index
!Subindex
!Data
!Type
!Resolution
|-
|0x302
|0x2005
|0x01
|Voltage <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|0x02
|Current <code>[A]</code>
|int16_t
|10 <code>[mA/LSB]</code>
|-
|
|
|0x03
|Current Discharge <code>[A]</code>
|int16_t
|10 <code>[mA/LSB]</code>
|-
|
|
|0x04
|Current Charge <code>[A]</code>
|int16_t
|10 <code>[mA/LSB]</code>
|-
|
|
|0x05
|State-of-Charge <code>[%]</code>
|int8_t
|1 <code>[%/LSB]</code>
|-
|
|
|0x06
|
|
|
|-
|
|
|0x07
|Time to Go <code>[min]</code>
|uint16_t
|1 <code>[min/LSB]</code>
|-
|
|
|
|
|
|
|-
|0x402
|0x2005
|0x09
|Cell Temperature High <code>[°C]</code>
|int8_t
|1 <code>[°C/LSB]</code>
|-
|
|
|0x0A
|
|
|
|-
|
|
|0x0B
|Cell Temperature Low <code>[°C]</code>
|int8_t
|1 <code>[°C/LSB]</code>
|-
|
|
|0x0C
|Cell Voltage High <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|0x0D
|Cell Voltage Low <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|0x0E
|BMS State
|uint32_t
|
|-
|
|
|0x0F
|Temperature Collection <code>[°C]</code>
|4x uint8_t
|1 <code>[°C/LSB]</code>
|-
|
|
|
|
|
|
|-
|0x482
|0x2000
|Cell nr
|Cell <code>[Cell_nr]</code> Voltage <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|
|
|
|
|-
|0x202
|Don't Care
|Don't Care
|Power Level <code>[%]</code>
|uint8_t
|1 <code>[%/LSB]</code>
|}

Throttle

2026-04-06T11:35:24Z

Aran Dokoupil: /* Setting the Control Mode over CAN */

The throttle controls the motor and is operated by the pilot during sailing. It controls the duty cycle of the motor via the [[CAN-bus|CAN bus]] using the standard VESC message format.

== Usage ==
[[File:Throttle Schematic.png|thumb|Throttle shown in the inactive (green led) neutral position]]
To use the throttle to control the motor the green illuminated ''arm-button'' will have to be pressed for a few seconds, however some conditions need to be met to ensure a safe start of the motor.

# The ''dead-man cord'' needs to be applied to the bottom of the throttle body, should snap in place magnetically
# The ''throttle lever'' Should be in its neutral position, pointing straight up with a noticeable tactile bump
# The [[CAN-bus|CAN bus]] need to be actively acknowledging packets, which means other devices need to be active on the bus
# No other error should have occurred inside the electronics

If one of these conditions is not met, the throttle will beep the number of times indicated above.

== Programming Throttle Position ==
The throttle position is read out by a magnet attached tot the ''throttle lever'', because the orientation of this magnet is not know in the firmware, this position can be programmed into the EEPROM. To enter programming mode hold down the arm button during power-on. A four beep descending tone should be played, and the LED should do a double blink in red continuously. To program the throttle push lever as far forward as possible and press the button, a single beep be heard. Repeat this twice with the lever in the center and finally with the lever all the way backwards. After three beeps the throttle is reprogrammed and normal operation is resumed. To summarize:

# Lever in the forward position
# Lever in the center position
# Lever in de backward position
#

If no programming is desired leave the lever alone for 10 seconds and the lever will reboot into normal mode.

== Setting the Control Mode over CAN ==
The Throttle controls the VESC motodriver at 40Hz messaging rate with the default CAN format implemented inside the VESC. [https://dongilc.gitbook.io/openrobot-inc/tutorials/control-with-can More info on the format.] and [https://triforce-docs.readthedocs.io/en/latest/canbus/canbus.html Here]. The throttle supports the following modes:

{| class="wikitable"
|+ Different control modes of the throttle
|-
! Control Mode !! Configuration Byte Value !! Unit !! Additional data required
|-
| Filtered Duty Cycle || 0x01 || Percentage || None lever in the maximum forward position is 100%
|-
|Duty Cycle|| 0x02 || Percentage || None lever in the maximum forward position is 100%
|-
|Current Control || 0x03 || 100mA || Specify the max current for forward and backwards in two int16_t's
|-
|RPM Control || 0x04 || RPM || Specify the rpm for forward and backwards in two int16_t's
|-
|Current Control Relative
|0x05
|Percentage
|None lever in the maximum forward position is 100%
|}

These modes can be send to the throttle when the throttle is off. If the throttle is on the configuration will be ignored. A sound will play when a message is received. The message has to be send to the Throttle address 0x337, same as the reboot command. the format is as follows:

{| class="wikitable"
|+ Can Message for Setting the control mode
|-
! Byte 0 !! Byte 1 !! Byte 2 !! Byte 3 !! Byte 4 !! Byte 5
|-
| 0xAA || Control type || MSB int16_t || LSB int16_t|| MSB int16_t || LSB int16_t
|-
| Hardcoded command|| See Table Above || colspan=2 | Max value for lever completely forward || colspan=2 | Same but for backward (Positive for reverse)

|}

==== Example command: ====
<syntaxhighlight lang="bash" line="1" start="69">
# duty cycle
cansend can0 337#AA0200000000

# 120A current control
cansend can0 337#AA0304B004B0

# relative current control
cansend can0 337#AA0400000000
</syntaxhighlight>

== CAN Diagnostics messages ==
The throttle also send out messages to help debugging every 200 ms. It is send on address 0x337 and has the following format:

{| class="wikitable"
|+ Can Message for Diagnostic Purposes
|-
! Byte 0 !! Byte 1 !! Byte 2 !! Byte 3 !! Byte 4 !! Byte 5 !! Byte 6 !! Byte 7
|-
| MSB int16_t || LSB int16_t || MSB int16_t || LSB int16_t || MSB int16_t || LSB int16_t || uint8_t || Error status
|-
| colspan=2 | Filtered lever position, from +512 to -512 || colspan=2 | Raw position reported by the magnetic encoder || colspan=2 | Raw data from the deadmanswitch ADC || Gain that is required to readout the lever position || Enum of current error state. 0x00 is good
|}

If any of the error status bits are set, the throttle is set into IDLE mode and will shut off the motor. The following table shows what the bitfield represents:

{| class="wikitable"
|+ Different control modes of the throttle
|-
! Bit !! Enum Name !! Explanation
|-
| 0 to 2 || twiError || See next table for possible values
|-
| 3 || noLimitsLoaded || Reading of EEPROM for throttle limits failed
|-
| 4 || gainClipping || The Magnetic encoder detected no good magnetic field present
|-
| 5 || gainInvalid || The gain value read from the magnetic encoder is beyond the range specified in software
|-
| 6 || deadmanMissing || The hall sensor of the deadman-switch doesn't detect a strong enough magnet
|-
| 7 || impeadanceHigh || The impeadance of the deadman signal is too high, indicating a bad connection
|}

{| class="wikitable"
|+ TWI error states
|-
! Value !! Error name !! Error Description
|-
| 0 || TWI_ERROR_NoError || Indicates that the command completed successfully.
|-
| 1 || TWI_ERROR_BusFault || A TWI bus fault occurred while attempting to capture the bus.
|-
| 2 || TWI_ERROR_BusCaptureTimeout || A timeout occurred whilst waiting for the bus to be ready.
|-
| 3 || TWI_ERROR_SlaveResponseTimeout || No ACK received at the nominated slave address within the timeout period.
|-
| 4 || TWI_ERROR_SlaveNotReady || Slave NAKed the TWI bus START condition.
|-
| 5 || TWI_ERROR_SlaveNAK || Slave NAKed whilst attempting to send data to the device.
|}

Throttle

2026-04-05T14:11:08Z

Aran Dokoupil: /* Setting the Control Mode over CAN */

The throttle controls the motor and is operated by the pilot during sailing. It controls the duty cycle of the motor via the [[CAN-bus|CAN bus]] using the standard VESC message format.

== Usage ==
[[File:Throttle Schematic.png|thumb|Throttle shown in the inactive (green led) neutral position]]
To use the throttle to control the motor the green illuminated ''arm-button'' will have to be pressed for a few seconds, however some conditions need to be met to ensure a safe start of the motor.

# The ''dead-man cord'' needs to be applied to the bottom of the throttle body, should snap in place magnetically
# The ''throttle lever'' Should be in its neutral position, pointing straight up with a noticeable tactile bump
# The [[CAN-bus|CAN bus]] need to be actively acknowledging packets, which means other devices need to be active on the bus
# No other error should have occurred inside the electronics

If one of these conditions is not met, the throttle will beep the number of times indicated above.

== Programming Throttle Position ==
The throttle position is read out by a magnet attached tot the ''throttle lever'', because the orientation of this magnet is not know in the firmware, this position can be programmed into the EEPROM. To enter programming mode hold down the arm button during power-on. A four beep descending tone should be played, and the LED should do a double blink in red continuously. To program the throttle push lever as far forward as possible and press the button, a single beep be heard. Repeat this twice with the lever in the center and finally with the lever all the way backwards. After three beeps the throttle is reprogrammed and normal operation is resumed. To summarize:

# Lever in the forward position
# Lever in the center position
# Lever in de backward position
#

If no programming is desired leave the lever alone for 10 seconds and the lever will reboot into normal mode.

== Setting the Control Mode over CAN ==
The Throttle controls the VESC motodriver at 40Hz messaging rate with the default CAN format implemented inside the VESC. [https://dongilc.gitbook.io/openrobot-inc/tutorials/control-with-can More info on the format.] The throttle supports the following modes:

{| class="wikitable"
|+ Different control modes of the throttle
|-
! Control Mode !! Configuration Byte Value !! Unit !! Additional data required
|-
| Filtered Duty Cycle || 0x01 || Percentage || None lever in the maximum forward position is 100%
|-
|Duty Cycle|| 0x02 || Percentage || None lever in the maximum forward position is 100%
|-
|Current Control || 0x03 || 100mA || Specify the max current for forward and backwards in two int16_t's
|-
|RPM Control || 0x04 || RPM || Specify the rpm for forward and backwards in two int16_t's
|-
|Current Control Relative
|0x05
|Percentage
|None lever in the maximum forward position is 100%
|}

These modes can be send to the throttle when the throttle is off. If the throttle is on the configuration will be ignored. A sound will play when a message is received. The message has to be send to the Throttle address 0x337, same as the reboot command. the format is as follows:

{| class="wikitable"
|+ Can Message for Setting the control mode
|-
! Byte 0 !! Byte 1 !! Byte 2 !! Byte 3 !! Byte 4 !! Byte 5
|-
| 0xAA || Control type || MSB int16_t || LSB int16_t|| MSB int16_t || LSB int16_t
|-
| Hardcoded command|| See Table Above || colspan=2 | Max value for lever completely forward || colspan=2 | Same but for backward (Positive for reverse)

|}

==== Example command: ====
<syntaxhighlight lang="bash" line="1" start="69">
# duty cycle
cansend can0 337#AA0200000000

# 120A current control
cansend can0 337#AA0304B004B0

# relative current control
cansend can0 337#AA0400000000
</syntaxhighlight>

== CAN Diagnostics messages ==
The throttle also send out messages to help debugging every 200 ms. It is send on address 0x337 and has the following format:

{| class="wikitable"
|+ Can Message for Diagnostic Purposes
|-
! Byte 0 !! Byte 1 !! Byte 2 !! Byte 3 !! Byte 4 !! Byte 5 !! Byte 6 !! Byte 7
|-
| MSB int16_t || LSB int16_t || MSB int16_t || LSB int16_t || MSB int16_t || LSB int16_t || uint8_t || Error status
|-
| colspan=2 | Filtered lever position, from +512 to -512 || colspan=2 | Raw position reported by the magnetic encoder || colspan=2 | Raw data from the deadmanswitch ADC || Gain that is required to readout the lever position || Enum of current error state. 0x00 is good
|}

If any of the error status bits are set, the throttle is set into IDLE mode and will shut off the motor. The following table shows what the bitfield represents:

{| class="wikitable"
|+ Different control modes of the throttle
|-
! Bit !! Enum Name !! Explanation
|-
| 0 to 2 || twiError || See next table for possible values
|-
| 3 || noLimitsLoaded || Reading of EEPROM for throttle limits failed
|-
| 4 || gainClipping || The Magnetic encoder detected no good magnetic field present
|-
| 5 || gainInvalid || The gain value read from the magnetic encoder is beyond the range specified in software
|-
| 6 || deadmanMissing || The hall sensor of the deadman-switch doesn't detect a strong enough magnet
|-
| 7 || impeadanceHigh || The impeadance of the deadman signal is too high, indicating a bad connection
|}

{| class="wikitable"
|+ TWI error states
|-
! Value !! Error name !! Error Description
|-
| 0 || TWI_ERROR_NoError || Indicates that the command completed successfully.
|-
| 1 || TWI_ERROR_BusFault || A TWI bus fault occurred while attempting to capture the bus.
|-
| 2 || TWI_ERROR_BusCaptureTimeout || A timeout occurred whilst waiting for the bus to be ready.
|-
| 3 || TWI_ERROR_SlaveResponseTimeout || No ACK received at the nominated slave address within the timeout period.
|-
| 4 || TWI_ERROR_SlaveNotReady || Slave NAKed the TWI bus START condition.
|-
| 5 || TWI_ERROR_SlaveNAK || Slave NAKed whilst attempting to send data to the device.
|}

Autopilot

2026-03-15T18:08:53Z

Aran Dokoupil:

== Platform ==
Ease of development dictated the choice to run the control loop on existing hard- and software. which was chosen to be Ardupilot running on a [https://docs.cubepilot.org/user-guides/autopilot/the-cube-module-overview orange cube].
[[File:Ardupilot.jpg|thumb|Ardupilot PCB with the orange cube mounted.]]
To make use for our application a PCB has been designed to integrate into the hydrofoil design.

To connect to the ardupilot on the cube for tweaking settings and tuning control loops, [https://ardupilot.org/planner/docs/mission-planner-overview.html Mission Planner] will be used. The following section have tweaked settings found in Mission Planner.

== Hardware ==
The cube is a plug-and-play unit and therefore does not need setup changes in the underlying ardupilot software. Only necessary settings should be tweaked.

Apart from the settings, tuning needs to be done in Mission Planner, this can only be done with the solar boat in the water and therefore no values are known for now.

The ardupilot PCB supports three servo motors, two front and one back motor. It has two isolated power supplies for the servo motors. Support for CAN and the cube is powered by the 24v input from the CAN connection.

It has its own GPS antenna and four UART serial ports, where Serial1 is used for the MAVLINK connect to Mission Planner that is running on a laptop. Two of these serial ports will be used to implement the height sensors that will be mounted on the boat for measuring the height of the water. This ensures that the system correctly responds to waves where the boat can 'surf' over.

For steering on foils an extra MCU is added onto the board namely: ATSAMD20E18A. This MCU can receive data from the rudder that gives the steering position and sends it through to the cube.

== Height Sensors ==
Currently testing ultrasonic height sensors, the RS485 version of the DYP-A02YY4W-V2.0.

== Ardupilot settings ==
To use the ardupilot as the foil control unit, some settings need to be changed since they do not apply to us or should be disabled. These settings are given below with a small explanation why it has been configured as is.

The settings below are the changed settings used by the ardupilot. There are more ports available on the ardupilot, whenever more are used or are changed the table will be updated.
{| class="wikitable sortable"
|+
Configuration of ardupilot
!Setting
!Value
!Description
!Reason
|-
|INS_GYR_CAL
|0
|Controls the automatic gyro calibration.
|Gyro calibration requires that the unit should be held as still as possible.
|-
|SERVO1_FUNCTION
|78
|ElevonRight
|Controls the right foil assembly.
|-
|SERVO2_FUNCTION
|77
|ElevonLeft
|Controls the left foil assembly.
|-
|INITIAL_MODE
|5
|FBWA
|Fly By Wire A this is a fly mode for the control unit. More can be found [https://ardupilot.org/plane/docs/fbwa-mode.html here].
|-
|GPS_TYPE2
|5
|NMEA
|This sets the GPS data that is sent onto the serial data port.
|-
|SERIAL1_PROTOCOL
|2
|MAVLINK2
|Controls what protocol to use on the serial port
|-
|SERIAL1_BAUD
|57
|57600
|Specifies the baudrate of the serial port.
|-
|SERIAL4_PROTOCOL
|5
|GPS
|Controls what protocol to use on the serial port
|-
|SERIAL4_BAUD
|9
|9600
|Specifies the baudrate of the serial port.
|}

== Future plans ==
As of now: 21-03-2023, FBWA mode is used for controlling the front two foil assembly. It would probably be beneficial whenever the whole system is finished to move towards the FBWB mode.

This mode supports "Automatic Altitude Holding", that makes sure that the same level of altitude is automatically kept. Further testing is needed for determining the control loops and their coefficients.

Implementing the different sensors into ardupilot and using that data to respond to the environment. These sensors are at least the height sensors and the rudder sensor for the steering angle.

As of March 2026, some progress was made with LUA scripting, see git, some additional reading:

https://ardupilot.org/plane/docs/common-sensor-testing.html

== Relevant links for configuring Ardupilot ==
https://ardupilot.org/copter/docs/common-gcs-only-operation.html

https://ardupilot.org/copter/docs/common-rangefinder-landingpage.html

https://ardupilot.org/copter/docs/setting-up-for-tuning.html

https://ardupilot.org/copter/docs/terrain-following-manual-modes.html

https://ardupilot.org/copter/docs/common-sensor-offset-compensation.html

https://ardupilot.org/copter/docs/crash_check.html

https://ardupilot.org/copter/docs/flight-modes.html --FBW-A mode seems best fit for front only, FBW-B for finalized system

https://ardupilot.org/plane/docs/fbwb-mode.html

https://ardupilot.org/copter/docs/stabilize-mode.html

https://ardupilot.org/plane/docs/fixed-wing-faq.html --Disable Gyro calibration on start-up

https://ardupilot.org/rover/docs/sonar-sensors.html --Two sonar sensors

https://ardupilot.org/dev/docs/plane-architecture.html --Plane architecture and files

GaN MPPT

2026-02-28T14:00:14Z

Aran Dokoupil: /* Can Bus Protocol Format */

[[File:MPPT overview.jpg|thumb|Baseboard with two phases populated]]
Part of a system consisting of 8x Gan Phases and 1x Baseboard.: Picture above is fully populated BaseBoard with 8 GaN boost converters mounted. PCB's can be cooled through Inductors on the bottom using a coldplate, while still being easily replaced from the top by remving the four bolts. Software based on TPEE MPPT

== Can Bus Protocol Format ==
The CAN bus telemetry is output using Standard CAN IDs (11-bit) by default. The ID structure uses the upper 7 bits for the Node ID (default 64, offset by hardware pins) and the lower 4 bits for the Packet ID.

Here is the documentation for the telemetry messages:

CAN Bus Frame Format

Frame Type: Standard Frame (11-bit ID)

Bitrate: 1000kbps

Node ID: Configurable generalCanId (64) + Hardware ID offset (Pins ID0-ID3)

NB: The ID is based on the position on the mainboard. Where ID0-ID2 is equal to the position 0-7, and ID3 is dependent on the DIP-switch on the mainboard. Front ID3 = 1, Read ID3 = 0.

CAN ID Construction: (NodeID << 4) | PacketID

=== Power ===
Packet ID 0x00: Power (2Hz)

Sent every 500ms. Contains the primary voltage and current measurements.

Packet ID: 0x00

Data Length: 8 Bytes

Format: Big Endian (Network Order)
{| class="wikitable"
|'''Byte'''
|'''Name'''
|'''Type'''
|'''Scaling'''
|'''Description'''
|-
|0-1
|Input Voltage
|int16
|0.01 V/bit
|Input Voltage (Vlow)
|-
|2-3
|Input Current
|int16
|0.0005 A/bit
|Input Current (Iind). Scaling factor 2000.0f
|-
|4-5
|Output Voltage
|int16
|0.01 V/bit
|Output Voltage (Vhigh)
|-
|6-7
|Output Current
|int16
|0.0005 A/bit
|Output Current (Ihigh). Scaling factor 2000.0f
|}
Note on Scaling:

buffer_append_float16(data, value, scale, &index) multiplies the float value by scale and stores it as an int16.

To decode: float value = (float)((int16_t)received_value) / scale

Input/Output Current Scale: 2000.0 -> Divide received int16 by 2000.0 to get Amps.

Input/Output Voltage Scale: 100.0 -> Divide received int16 by 100.0 to get Volts.

=== Status ===
Packet ID 0x01: Status (1Hz)

Sent every 1000ms. Contains the operating state and fault codes.

Packet ID: 0x01

Data Length: 5 Bytes
{| class="wikitable"
|'''Byte'''
|'''Name'''
|'''Type'''
|'''Scaling / Enum'''
|'''Description'''
|-
|0
|Mode
|uint8
|PhaseMode_t
|Operating Mode (1=CIV, 2=CIC, 3=MinInputCurrent, 4=COV, 5=COC, 6=Temp Derating, 7=Fault)
|-
|1
|Fault
|uint8
|PhaseFault_t
|Fault Code (0=OK, 1=Config, 2=Input OV, 3=Output OV, 4=Output OC, 5=Input OC, 6=Input UC, 7=Phase OC)
|-
|2
|Enabled
|uint8
|bool
|1 if Enabled, 0 if Disabled
|-
|3
|Board Temp
|int8
|1 °C/bit
|Ambient Temperature in °C
|-
|4
|Heat Sink Temp
|int8
|1 °C/bit
|Heatsink Temperature in °C
|}

=== Sweep Data ===
Packet ID 0x02: Sweep Data (On Request)

Sent during an MPPT sweep operation.

Packet ID: 0x02

Data Length: 5 Bytes
{| class="wikitable"
|'''Byte'''
|'''Name'''
|'''Type'''
|'''Scaling'''
|'''Description'''
|-
|0
|Index
|uint8
|1
|Sweep point index (0-255)
|-
|1-2
|Current
|int16
|0.0005 A/bit
|Current at this sweep point (Scale 2000.0)
|-
|3-4
|Voltage
|int16
|0.01 V/bit
|Voltage at this sweep point (Scale 100.0)
|}

=== Enums ===

=== PhaseMode_t (Byte 0 of Status) ===
0: None (Start)

1: CIV (Constant Input Voltage)

2: CIC (Constant Input Current)

3: MinInputCurrent

4: COV (Constant Output Voltage)

5: COC (Constant Output Current)

6: TD (Temperature Derating)

7: Fault

==== PhaseFault_t (Byte 1 of Status) ====
0: OK

1: Config Error

2: Input Over Voltage

3: Output Over Voltage

4: Output Over Current

5: Input Over Current

6: Input Under Current

7: Phase Over Current

8: General Fault
#

GaN MPPT

2026-02-28T13:54:08Z

Aran Dokoupil:

[[File:MPPT overview.jpg|thumb|Baseboard with two phases populated]]
Part of a system consisting of 8x Gan Phases and 1x Baseboard.: Picture above is fully populated BaseBoard with 8 GaN boost converters mounted. PCB's can be cooled through Inductors on the bottom using a coldplate, while still being easily replaced from the top by remving the four bolts. Software based on TPEE MPPT

== Can Bus Protocol Format ==
The CAN bus telemetry is output using Standard CAN IDs (11-bit) by default. The ID structure uses the upper 7 bits for the Node ID (default 64, offset by hardware pins) and the lower 4 bits for the Packet ID.

Here is the documentation for the telemetry messages:

CAN Bus Frame Format

Frame Type: Standard Frame (11-bit ID)

Bitrate: 1000kbps

Node ID: Configurable generalCanId (64) + Hardware ID offset (Pins ID0-ID3)

CAN ID Construction: (NodeID << 4) | PacketID

=== Power ===
Packet ID 0x00: Power (2Hz)

Sent every 500ms. Contains the primary voltage and current measurements.

Packet ID: 0x00

Data Length: 8 Bytes

Format: Big Endian (Network Order)
{| class="wikitable"
|'''Byte'''
|'''Name'''
|'''Type'''
|'''Scaling'''
|'''Description'''
|-
|0-1
|Input Voltage
|int16
|0.01 V/bit
|Input Voltage (Vlow)
|-
|2-3
|Input Current
|int16
|0.0005 A/bit
|Input Current (Iind). Scaling factor 2000.0f
|-
|4-5
|Output Voltage
|int16
|0.01 V/bit
|Output Voltage (Vhigh)
|-
|6-7
|Output Current
|int16
|0.0005 A/bit
|Output Current (Ihigh). Scaling factor 2000.0f
|}
Note on Scaling:

buffer_append_float16(data, value, scale, &index) multiplies the float value by scale and stores it as an int16.

To decode: float value = (float)((int16_t)received_value) / scale

Input/Output Current Scale: 2000.0 -> Divide received int16 by 2000.0 to get Amps.

Input/Output Voltage Scale: 100.0 -> Divide received int16 by 100.0 to get Volts.

=== Status ===
Packet ID 0x01: Status (1Hz)

Sent every 1000ms. Contains the operating state and fault codes.

Packet ID: 0x01

Data Length: 5 Bytes
{| class="wikitable"
|'''Byte'''
|'''Name'''
|'''Type'''
|'''Scaling / Enum'''
|'''Description'''
|-
|0
|Mode
|uint8
|PhaseMode_t
|Operating Mode (1=CIV, 2=CIC, 3=MinInputCurrent, 4=COV, 5=COC, 6=Temp Derating, 7=Fault)
|-
|1
|Fault
|uint8
|PhaseFault_t
|Fault Code (0=OK, 1=Config, 2=Input OV, 3=Output OV, 4=Output OC, 5=Input OC, 6=Input UC, 7=Phase OC)
|-
|2
|Enabled
|uint8
|bool
|1 if Enabled, 0 if Disabled
|-
|3
|Board Temp
|int8
|1 °C/bit
|Ambient Temperature in °C
|-
|4
|Heat Sink Temp
|int8
|1 °C/bit
|Heatsink Temperature in °C
|}

=== Sweep Data ===
Packet ID 0x02: Sweep Data (On Request)

Sent during an MPPT sweep operation.

Packet ID: 0x02

Data Length: 5 Bytes
{| class="wikitable"
|'''Byte'''
|'''Name'''
|'''Type'''
|'''Scaling'''
|'''Description'''
|-
|0
|Index
|uint8
|1
|Sweep point index (0-255)
|-
|1-2
|Current
|int16
|0.0005 A/bit
|Current at this sweep point (Scale 2000.0)
|-
|3-4
|Voltage
|int16
|0.01 V/bit
|Voltage at this sweep point (Scale 100.0)
|}

=== Enums ===

=== PhaseMode_t (Byte 0 of Status) ===
0: None (Start)

1: CIV (Constant Input Voltage)

2: CIC (Constant Input Current)

3: MinInputCurrent

4: COV (Constant Output Voltage)

5: COC (Constant Output Current)

6: TD (Temperature Derating)

7: Fault

==== PhaseFault_t (Byte 1 of Status) ====
0: OK

1: Config Error

2: Input Over Voltage

3: Output Over Voltage

4: Output Over Current

5: Input Over Current

6: Input Under Current

7: Phase Over Current

8: General Fault
#

GaN MPPT

2026-02-25T22:42:41Z

Aran Dokoupil: /* Can Bus Protocol Format */

[[File:MPPT overview.jpg|thumb|Baseboard with two phases populated]]
Part of a system consisting of 8x Gan Phases and 1x Baseboard.: Picture above is fully populated BaseBoard with 8 GaN boost converters mounted. PCB's can be cooled through Inductors on the bottom using a coldplate, while still being easily replaced from the top by remving the four bolts. Software based on TPEE MPPT

== Can Bus Protocol Format ==
The CAN bus telemetry is output using Standard CAN IDs (11-bit) by default. The ID structure uses the upper 7 bits for the Node ID (default 10, offset by hardware pins) and the lower 4 bits for the Packet ID.

Here is the documentation for the telemetry messages:

CAN Bus Frame Format

Frame Type: Standard Frame (11-bit ID)

Bitrate: 1000kbps

Node ID: Configurable generalCanId (64) + Hardware ID offset (Pins ID0-ID3)

CAN ID Construction: (NodeID << 4) | PacketID

=== Status ===
Packet ID 0x01: Status (10Hz)

Sent every 100ms. Contains the operating state and fault codes.

Packet ID: 0x01

Data Length: 5 Bytes
{| class="wikitable"
|'''Byte'''
|'''Name'''
|'''Type'''
|'''Scaling / Enum'''
|'''Description'''
|-
|0
|Mode
|uint8
|PhaseMode_t
|Operating Mode (1=CIV, 2=CIC, 3=MinInputCurrent, 4=COV, 5=COC, 6=Temp Derating, 7=Fault)
|-
|1
|Fault
|uint8
|PhaseFault_t
|Fault Code (0=OK, 1=Config, 2=Input OV, 3=Output OV, 4=Output OC, 5=Input OC, 6=Input UC, 7=Phase OC)
|-
|2
|Enabled
|uint8
|bool
|1 if Enabled, 0 if Disabled
|-
|3
|Board Temp
|int8
|1 °C/bit
|Ambient Temperature in °C
|-
|4
|Heat Sink Temp
|int8
|1 °C/bit
|Heatsink Temperature in °C
|}

=== Power ===
Packet ID 0x00: Power (2Hz)

Sent every 500ms. Contains the primary voltage and current measurements.

Packet ID: 0x00

Data Length: 8 Bytes

Format: Big Endian (Network Order)
{| class="wikitable"
|'''Byte'''
|'''Name'''
|'''Type'''
|'''Scaling'''
|'''Description'''
|-
|0-1
|Input Voltage
|int16
|0.01 V/bit
|Input Voltage (Vlow)
|-
|2-3
|Input Current
|int16
|0.0005 A/bit
|Input Current (Iind). Scaling factor 2000.0f
|-
|4-5
|Output Voltage
|int16
|0.01 V/bit
|Output Voltage (Vhigh)
|-
|6-7
|Output Current
|int16
|0.0005 A/bit
|Output Current (Ihigh). Scaling factor 2000.0f
|}
Note on Scaling:

buffer_append_float16(data, value, scale, &index) multiplies the float value by scale and stores it as an int16.

To decode: float value = (float)((int16_t)received_value) / scale

Input/Output Current Scale: 2000.0 -> Divide received int16 by 2000.0 to get Amps.

Input/Output Voltage Scale: 100.0 -> Divide received int16 by 100.0 to get Volts.

=== Sweep Data ===
Packet ID 0x02: Sweep Data (On Request)

Sent during an MPPT sweep operation.

Packet ID: 0x02

Data Length: 5 Bytes
{| class="wikitable"
|'''Byte'''
|'''Name'''
|'''Type'''
|'''Scaling'''
|'''Description'''
|-
|0
|Index
|uint8
|1
|Sweep point index (0-255)
|-
|1-2
|Current
|int16
|0.0005 A/bit
|Current at this sweep point (Scale 2000.0)
|-
|3-4
|Voltage
|int16
|0.01 V/bit
|Voltage at this sweep point (Scale 100.0)
|}

=== Enums ===

=== PhaseMode_t (Byte 0 of Status) ===
0: None (Start)

1: CIV (Constant Input Voltage)

2: CIC (Constant Input Current)

3: MinInputCurrent

4: COV (Constant Output Voltage)

5: COC (Constant Output Current)

6: TD (Temperature Derating)

7: Fault

==== PhaseFault_t (Byte 1 of Status) ====
0: OK

1: Config Error

2: Input Over Voltage

3: Output Over Voltage

4: Output Over Current

5: Input Over Current

6: Input Under Current

7: Phase Over Current

8: General Fault
#

GaN MPPT

2026-02-25T22:41:42Z

Aran Dokoupil:

[[File:MPPT overview.jpg|thumb|Baseboard with two phases populated]]
Part of a system consisting of 8x Gan Phases and 1x Baseboard.: Picture above is fully populated BaseBoard with 8 GaN boost converters mounted. PCB's can be cooled through Inductors on the bottom using a coldplate, while still being easily replaced from the top by remving the four bolts. Software based on TPEE MPPT

== Can Bus Protocol Format ==
The CAN bus telemetry is output using Standard CAN IDs (11-bit) by default. The ID structure uses the upper 7 bits for the Node ID (default 10, offset by hardware pins) and the lower 4 bits for the Packet ID.

Here is the documentation for the telemetry messages:

CAN Bus Frame Format

Frame Type: Standard Frame (11-bit ID)

Bitrate: Configurable (Default 500kbps)

Node ID: Configurable generalCanId (Default 10) + Hardware ID offset (Pins ID0-ID3)

CAN ID Construction: (NodeID << 4) | PacketID

=== Status ===
Packet ID 0x01: Status (10Hz)

Sent every 100ms. Contains the operating state and fault codes.

Packet ID: 0x01

Data Length: 5 Bytes
{| class="wikitable"
|'''Byte'''
|'''Name'''
|'''Type'''
|'''Scaling / Enum'''
|'''Description'''
|-
|0
|Mode
|uint8
|PhaseMode_t
|Operating Mode (1=CIV, 2=CIC, 3=MinInputCurrent, 4=COV, 5=COC, 6=Temp Derating, 7=Fault)
|-
|1
|Fault
|uint8
|PhaseFault_t
|Fault Code (0=OK, 1=Config, 2=Input OV, 3=Output OV, 4=Output OC, 5=Input OC, 6=Input UC, 7=Phase OC)
|-
|2
|Enabled
|uint8
|bool
|1 if Enabled, 0 if Disabled
|-
|3
|Board Temp
|int8
|1 °C/bit
|Ambient Temperature in °C
|-
|4
|Heat Sink Temp
|int8
|1 °C/bit
|Heatsink Temperature in °C
|}

=== Power ===
Packet ID 0x00: Power (2Hz)

Sent every 500ms. Contains the primary voltage and current measurements.

Packet ID: 0x00

Data Length: 8 Bytes

Format: Big Endian (Network Order)
{| class="wikitable"
|'''Byte'''
|'''Name'''
|'''Type'''
|'''Scaling'''
|'''Description'''
|-
|0-1
|Input Voltage
|int16
|0.01 V/bit
|Input Voltage (Vlow)
|-
|2-3
|Input Current
|int16
|0.0005 A/bit
|Input Current (Iind). Scaling factor 2000.0f
|-
|4-5
|Output Voltage
|int16
|0.01 V/bit
|Output Voltage (Vhigh)
|-
|6-7
|Output Current
|int16
|0.0005 A/bit
|Output Current (Ihigh). Scaling factor 2000.0f
|}
Note on Scaling:

buffer_append_float16(data, value, scale, &index) multiplies the float value by scale and stores it as an int16.

To decode: float value = (float)((int16_t)received_value) / scale

Input/Output Current Scale: 2000.0 -> Divide received int16 by 2000.0 to get Amps.

Input/Output Voltage Scale: 100.0 -> Divide received int16 by 100.0 to get Volts.

=== Sweep Data ===
Packet ID 0x02: Sweep Data (On Request)

Sent during an MPPT sweep operation.

Packet ID: 0x02

Data Length: 5 Bytes
{| class="wikitable"
|'''Byte'''
|'''Name'''
|'''Type'''
|'''Scaling'''
|'''Description'''
|-
|0
|Index
|uint8
|1
|Sweep point index (0-255)
|-
|1-2
|Current
|int16
|0.0005 A/bit
|Current at this sweep point (Scale 2000.0)
|-
|3-4
|Voltage
|int16
|0.01 V/bit
|Voltage at this sweep point (Scale 100.0)
|}

=== Enums ===

=== PhaseMode_t (Byte 0 of Status) ===
0: None (Start)

1: CIV (Constant Input Voltage)

2: CIC (Constant Input Current)

3: MinInputCurrent

4: COV (Constant Output Voltage)

5: COC (Constant Output Current)

6: TD (Temperature Derating)

7: Fault

==== PhaseFault_t (Byte 1 of Status) ====
0: OK

1: Config Error

2: Input Over Voltage

3: Output Over Voltage

4: Output Over Current

5: Input Over Current

6: Input Under Current

7: Phase Over Current

8: General Fault
#

File:MPPT overview.jpg

2026-02-25T22:33:14Z

Aran Dokoupil:

Safety

2025-06-26T05:50:06Z

Aran Dokoupil: /* Electrical Specifications */

The safety system is meant to stop the boat in an emergency, there is an E-Stop button on the deck near the driver. Pressing this will disable the charge, discharge and peri-power paths in the battery.

== Electrical Specifications ==
[[File:Safety .png|thumb|The safety output as implemented on the [[Battery|BMS]]. When the boat is on the SAFETY_n signal is low. connecting pin 1 of connector J7 to ground]]
The safety wire runs together with the [[CAN-bus|CAN bus]] over same physical wire, daisy-chained on every sub-system using the 5-pins binder connectors. The safety wire is referenced to CAN ground and has an open drain output at the battery. When the safety wire is low the boat is turned on. Each subsystem should have a pull-up installed from 5v to their safety input to ensure a high level is measured when its cable is disconnected. The safety input have 6v TVS diodes installed and should not be subject to voltages over 5v5 for long amounts of time.

Safety

2025-06-26T05:49:10Z

Aran Dokoupil:

The safety system is meant to stop the boat in an emergency, there is an E-Stop button on the deck near the driver. Pressing this will disable the charge, discharge and peri-power paths in the battery.

== Electrical Specifications ==
[[File:Safety .png|thumb|The safety output as implemented on the [[Battery|BMS]]. When the boat is on the SAFETY_n signal is low. connecting pin 1 of connector J7 to ground]]
The safety wire runs together with the [[CAN-bus|CAN bus]] over same physical wire, daisy-chained on every sub-system using the 5-pins binder connectors. The safety wire is referenced to CAN ground and has an open drain output at the battery. When the safety wire is low the boat is turned on, each subsystem should have a pull up installed to 5v their safety input to ensure a high level is measured when its cable is disconnected. The safety input have 6v TVS diodes installed and should not be subject to voltages over 5v5 for long amounts of time.

File:Safety .png

2025-06-26T05:46:56Z

Aran Dokoupil:

Safety output circuitry used in BMS

Safety

2025-06-26T05:41:46Z

Aran Dokoupil: Created page with "The safety system is meant to stop the boat in an emergency, there is an E-Stop buton on the deck near the driver. Pressing this will disable the charge, discharge and peri-power paths in the battery."

The safety system is meant to stop the boat in an emergency, there is an E-Stop buton on the deck near the driver. Pressing this will disable the charge, discharge and peri-power paths in the battery.

GaN MPPT

2025-06-20T15:01:09Z

Aran Dokoupil:

First idea's for a GaN based MPPT

# Individual Phases are replaceable easily
# Software based on TPEE MPPT[https://www.tpee.nl/open-sec-open-source-mppt-developed-for-high-efficiency-solar-cars/]
##TPEE uses USB for config
# Compatible with 14S , sufficient protection for transients etc.
# Some way to get heat out of the enclosure
# Easy connectors on the enclosure (no conta-clip)
# Enough channels to have 2 MPPT's boards for the whole boat, probably 6 or 8?
# Interleaved operation to reduce RMS current through capacitors
# Functional isolation on CAN and safety inputs
#

GaN MPPT

2025-06-10T18:11:18Z

Aran Dokoupil: Created page with "First idea's for a GaN based MPPT # Individual Phases are replaceable easily # Software based on TPEE MPPT[https://www.tpee.nl/open-sec-open-source-mppt-developed-for-high-efficiency-solar-cars/] # Compatible with 14S , sufficient protection for transients etc. # Some way to get heat out of the enclosure # Easy connectors on the enclosure (no conta-clip) # Enough channels to have 2 MPPT's boards for the whole boat, probably 6 or 8? # Interleaved operation to reduce RMS..."

First idea's for a GaN based MPPT

# Individual Phases are replaceable easily
# Software based on TPEE MPPT[https://www.tpee.nl/open-sec-open-source-mppt-developed-for-high-efficiency-solar-cars/]
# Compatible with 14S , sufficient protection for transients etc.
# Some way to get heat out of the enclosure
# Easy connectors on the enclosure (no conta-clip)
# Enough channels to have 2 MPPT's boards for the whole boat, probably 6 or 8?
# Interleaved operation to reduce RMS current through capacitors
# Functional isolation on CAN and safety inputs
#

Hub Sensor

2025-05-25T13:16:20Z

Aran Dokoupil: /* Future Tests and Features */

The hub sensor is an AS5047 magnetic encoder mounted behind the Lehner BLDC motor inside the rudder. The hub sensor communicated the position of the rotor to provide a reference position to the motordriver during startup.

== Architecture ==
[[File:250525135749 Scope Screen.png|thumb|Scope screen of the RS422 in blue and SPI from the VESC. Showing the timing of the various data transfers]]
The hubsesnor is build around two PCBs, one that connects to the VESC and the other that sits behind the motor. These boards are build around the atxmega16e5 and communicate with each other though RS422. The bottom board reads out the AS5047 and NTC and sens this data to the top over serial at 2 Megabaud. This link is quite fast to be able to send this data at the sample rate of the VESC at around 12kHz. The data and power to the hub sensor are separated with functional isolation to make sure the top electronics are protected from water Ingres and shorts.

== Startup and Timing Behavior ==
The top and hub MCUs share the same flash image so they are easy to update and their protocol is always in sync. During boot the flash of the hub MCU is cleared and it waits for a copy of the top MCU's flash. If this is successful the '''top green LED will blink every second in three quick bursts'''. During running this LED should be blinking continuously. If there is no data from the bottom board for 8ms the top board will reboot the hub and send another flash config, blinking of the red LED will occur during.

== VESC tool ==
[[File:Vesc.png|thumb|VESC tool showing a counter value that has been generated on the hub PCB for testing. small steps in the data can be seen for unknown reason]]
[[File:Vesc tool.png|thumb|Showing the hub sensor with magnet data. Note the noise on the right side when the magnet is removed]]
The encoder was tested using VESC tool and a counter value generated at the bottom hub PCB. The data transmission is quite reliable without a motor attached, a spike of 360 degrees can be seen about every 10 minutes as of git hash "b45a45a" .DMA on the RX UART could ease the timing requirements on the top board and perhaps reduce this.

== Future Tests and Features ==
Some additional features or tests that could be implemented or done in the future:

* Actually test on the VESC 300/75
** Currently only tested on the UBOX 75 v2
*Test with high currents though the motor cables next to the data
* Implement error detection when for instance no magnet is found
** Perhaps set the parity bit wrong on the top to let the VESC know there is only garbage
* Check the temperature sensor accuracy
** We send the ADC values at the bottom as is to the top DAC. The idea is that we set the same voltage as measured at the bottom with the same resistor divider that's used on the VESC. We havent checked if this actually measures the temperature correctly

Rudder

2025-05-25T13:13:40Z

Aran Dokoupil:

The motor currently in use in the rudder is the Lehner 30100/12 with a NTC Temp. Sensor (B 25/100 3988 ±1%) installed. There is also a [[Hub Sensor|magnetic encoder]] placed behind the motor.

Hub Sensor

2025-05-25T12:52:34Z

Aran Dokoupil: /* VESC tool */

The hub sensor is an AS5047 magnetic encoder mounted behind the Lehner BLDC motor inside the rudder. The hub sensor communicated the position of the rotor to provide a reference position to the motordriver during startup.

== Architecture ==
[[File:250525135749 Scope Screen.png|thumb|Scope screen of the RS422 in blue and SPI from the VESC. Showing the timing of the various data transfers]]
The hubsesnor is build around two PCBs, one that connects to the VESC and the other that sits behind the motor. These boards are build around the atxmega16e5 and communicate with each other though RS422. The bottom board reads out the AS5047 and NTC and sens this data to the top over serial at 2 Megabaud. This link is quite fast to be able to send this data at the sample rate of the VESC at around 12kHz. The data and power to the hub sensor are separated with functional isolation to make sure the top electronics are protected from water Ingres and shorts.

== Startup and Timing Behavior ==
The top and hub MCUs share the same flash image so they are easy to update and their protocol is always in sync. During boot the flash of the hub MCU is cleared and it waits for a copy of the top MCU's flash. If this is successful the '''top green LED will blink every second in three quick bursts'''. During running this LED should be blinking continuously. If there is no data from the bottom board for 8ms the top board will reboot the hub and send another flash config, blinking of the red LED will occur during.

== VESC tool ==
[[File:Vesc.png|thumb|VESC tool showing a counter value that has been generated on the hub PCB for testing. small steps in the data can be seen for unknown reason]]
[[File:Vesc tool.png|thumb|Showing the hub sensor with magnet data. Note the noise on the right side when the magnet is removed]]
The encoder was tested using VESC tool and a counter value generated at the bottom hub PCB. The data transmission is quite reliable without a motor attached, a spike of 360 degrees can be seen about every 10 minutes as of git hash "b45a45a" .DMA on the RX UART could ease the timing requirements on the top board and perhaps reduce this.

== Future Tests and Features ==
Some additional features or tests that could be implemented or done in the future:

* Actually test on the VESC 300/75
** Currently only tested on the UBOX 75 v2
* Implement error detection when for instance no magnet is found
** Perhaps set the parity bit wrong on the top to let the VESC know there is only garbage
* Check the temperature sensor accuracy
** We send the ADC values at the bottom as is to the top DAC. The idea is that we set the same voltage as measured at the bottom with the same resistor divider that's used on the VESC. We havent checked if this actually measures the temperature correctly

Engineers of Innovation

2025-05-25T12:43:57Z

Aran Dokoupil:

Consult the [[mediawikiwiki:Special:MyLanguage/Help:Contents|User's Guide]] for information on using the wiki software.

== Getting started ==
To get started with Engineers of Innovation a couple of links are shown here:

* [https://engineersofinnovation.nl Our own website]
* [https://git.engineersofinnovation.nl Git]
* [https://engineers-of-innovation.365.altium.com/ Altium 365 workspace]

=== Wiki page getting started ===
The different programs that are used all have their respective wiki page for getting started on getting an account and how to access the workspaces. The pages are linked below for easy access:

* [[Altium|Getting started with Altium Designer]]
*[[Fusion 360|Getting started with Fusion 360]]
*[[GIT|Getting started with Git]]

== The Solar boat (boii) ==
[[File:Solar boat with horizon.jpg|thumb|500x500px|Solar boat sailing on the sea around Madeira.]]Our solar boat is an 8 meter long and 1,20 meter wide ship. Where we sail competitive with different teams from Europe.

The clickable picture below shows the different systems within the solar boat, these systems are their own respective project.

Any other projects and subjects going on within the association can be found in the projects [[Project catalogue|catalogue]].

<imagemap>
File:Boot blokschema.drawio.png|frameless|1000x1000px
rect 72 230 315 354 [[Rudder]]
rect 692 230 936 354 [[MPPT]]
rect 352 130 595 253 [[Battery]]
rect 352 310 595 433 [[Motordriver]]
rect 1532 90 1776 214 [[Datalogger]]
rect 1532 350 1775 473 [[Throttle]]
rect 1892 110 2201 208 [[Autopilot]]
rect 1892 330 2136 454 [[Foils]]
rect 2192 210 2436 334 [[MPPT]]
</imagemap>

== All Pages Page ==
Click [[Special:AllPages|HERE]] for a list of all pages on this Wiki

== Page syntax! ==
Before anyone can edit or add pages to the wiki. An account [[Special:RequestAccount|request]] need to be made.

For new users or users who just want to lookup what the syntax is, a '''[[Test]]''' page is created with general use cases.

Hub Sensor

2025-05-25T12:32:18Z

Aran Dokoupil: added future thing to do

The hub sensor is an AS5047 magnetic encoder mounted behind the Lehner BLDC motor inside the rudder. The hub sensor communicated the position of the rotor to provide a reference position to the motordriver during startup.

== Architecture ==
[[File:250525135749 Scope Screen.png|thumb|Scope screen of the RS422 in blue and SPI from the VESC. Showing the timing of the various data transfers]]
The hubsesnor is build around two PCBs, one that connects to the VESC and the other that sits behind the motor. These boards are build around the atxmega16e5 and communicate with each other though RS422. The bottom board reads out the AS5047 and NTC and sens this data to the top over serial at 2 Megabaud. This link is quite fast to be able to send this data at the sample rate of the VESC at around 12kHz. The data and power to the hub sensor are separated with functional isolation to make sure the top electronics are protected from water Ingres and shorts.

== Startup and Timing Behavior ==
The top and hub MCUs share the same flash image so they are easy to update and their protocol is always in sync. During boot the flash of the hub MCU is cleared and it waits for a copy of the top MCU's flash. If this is successful the '''top green LED will blink every second in three quick bursts'''. During running this LED should be blinking continuously. If there is no data from the bottom board for 8ms the top board will reboot the hub and send another flash config, blinking of the red LED will occur during.

== VESC tool ==
[[File:Vesc.png|thumb|VESC tool showing a counter value that has been generated on the hub PCB for testing. small steps in the data can be seen for unknown reason]]
[[File:Vesc tool.png|thumb|Showing the hub sensor with magnet data. Note the noise on the right side when the magnet is removed]]
The encoder was tested using VESC tool and a counter value generated at the bottom hub PCB. The data transmission is quite reliable without a motor attached, a spike o0f 360 degrees can be seen every 10 minutes as of git hash "51da04c". DMA on the RX UART could ease the timing requirements on the top board and perhaps reduce this.

== Future Tests and Features ==
Some additional features or tests that could be implemented or done in the future:

* Actually test on the VESC 300/75
** Currently only tested on the UBOX 75 v2
* Implement error detection when for instance no magnet is found
** Perhaps set the parity bit wrong on the top to let the VESC know there is only garbage
* Check the temperature sensor accuracy
** We send the ADC values at the bottom as is to the top DAC. The idea is that we set the same voltage as measured at the bottom with the same resistor divider that's used on the VESC. We havent checked if this actually measures the temperature correctly

File:Vesc tool.png

2025-05-25T12:26:45Z

Aran Dokoupil:

Showing magnet data though the hub sensor

Hub Sensor

2025-05-25T12:16:03Z

Aran Dokoupil: Created page with "The hub sensor is an AS5047 magnetic encoder mounted behind the Lehner BLDC motor inside the rudder. The hub sensor communicated the position of the rotor to provide a reference position to the motordriver during startup. == Architecture == Scope screen of the RS422 in blue and SPI from the VESC. Showing the timing of the various data transfers The hubsesnor is build around two PCBs, one that connects to the VESC and the othe..."

The hub sensor is an AS5047 magnetic encoder mounted behind the Lehner BLDC motor inside the rudder. The hub sensor communicated the position of the rotor to provide a reference position to the motordriver during startup.

== Architecture ==
[[File:250525135749 Scope Screen.png|thumb|Scope screen of the RS422 in blue and SPI from the VESC. Showing the timing of the various data transfers]]
The hubsesnor is build around two PCBs, one that connects to the VESC and the other that sits behind the motor. These boards are build around the atxmega16e5 and communicate with each other though RS422. The bottom board reads out the AS5047 and NTC and sens this data to the top over serial at 1.5 Megabaud. This link is quite fast to be able to send this data at the sample rate of the VESC at around 12kHz. The data and power to the hub sensor are separated with functional isolation to make sure the top electronics are protected from water Ingres and shorts.

== Startup and Timing Behavior ==
The top and hub MCUs share the same flash image so they are easy to update and their protocol is always in sync. During boot the flash of the hub MCU is cleared and it waits for a copy of the top MCU's flash. If this is successful the '''top green LED will blink every second in three quick bursts'''. During running this LED should be blinking continuously. If there is no data from the bottom board for 8ms the top board will reboot the hub and send another flash config, blinking of the red LED will occur during.

== VESC tool ==
[[File:Vesc.png|thumb|VESC tool showing a counter value that has been generated on the hub PCB for testing. small steps in the data can be seen for unknown reason]]
The encoder was tested using VESC tool and a counter value generated at the bottom hub PCB. The data transmission is quite reliable without a motor attached, a spike o0f 360 degrees can be seen every 10 minutes as of git hash "51da04c". DMA on the RX UART could ease the timing requirements on the top board and perhaps reduce this.

File:Vesc.png

2025-05-25T12:13:18Z

Aran Dokoupil:

VESC tool showing a counter on the encoder channel

File:250525135749 Scope Screen.png

2025-05-25T12:03:58Z

Aran Dokoupil:

Scope image of the timing

Throttle

2025-05-17T07:00:10Z

Aran Dokoupil: /* Setting the Control Mode over CAN */

The throttle controls the motor and is operated by the pilot during sailing. It controls the duty cycle of the motor via the CAN bus using the standard VESC message format.

== Usage ==
[[File:Throttle Schematic.png|thumb|Throttle shown in the inactive (green led) neutral position]]
To use the throttle to control the motor the green illuminated ''arm-button'' will have to be pressed for a few seconds, however some conditions need to be met to ensure a safe start of the motor.

# The ''dead-man cord'' needs to be applied to the bottom of the throttle body, should snap in place magnetically
# The ''throttle lever'' Should be in its neutral position, pointing straight up with a noticeable tactile bump
# The CAN bus need to be actively acknowledging packets, which means other devices need to be active on the bus
# No other error should have occurred inside the electronics

If one of these conditions is not met, the throttle will beep the number of times indicated above.

== Programming Throttle Position ==
The throttle position is read out by a magnet attached tot the ''throttle lever'', because the orientation of this magnet is not know in the firmware, this position can be programmed into the EEPROM. To enter programming mode hold down the arm button during power-on. A four beep descending tone should be played, and the LED should do a double blink in red continuously. To program the throttle push lever as far forward as possible and press the button, a single beep be heard. Repeat this twice with the lever in the center and finally with the lever all the way backwards. After three beeps the throttle is reprogrammed and normal operation is resumed. To summarize:

# Lever in the forward position
# Lever in the center position
# Lever in de backward position
#

If no programming is desired leave the lever alone for 10 seconds and the lever will reboot into normal mode.

== Setting the Control Mode over CAN ==
The Throttle controls the VESC motodriver at 40Hz messaging rate with the default CAN format implemented inside the VESC. [https://dongilc.gitbook.io/openrobot-inc/tutorials/control-with-can More info on the format.] The throttle supports the following modes:

{| class="wikitable"
|+ Different control modes of the throttle
|-
! Control Mode !! Configuration Byte Value !! Unit !! Additional data required
|-
| Duty Cycle|| 0x00 || Percentage || None lever in the maximum forward position is 100%
|-
|Filtered Duty Cycle|| 0x01 || Percentage || None lever in the maximum forward position is 100%
|-
|Current Control || 0x02 || 100mA || Specify the max current for forward and backwards in two int16_t's
|-
|RPM Control || 0x03 || RPM || Specify the rpm for forward and backwards in two int16_t's
|-
|Current Control Relative
|0x04
|Percentage
|None lever in the maximum forward position is 100%
|}

These modes can be send to the throttle when the throttle is off. If the throttle is on the configuration will be ignored. A sound will play when a message is received. The message has to be send to the Throttle address 0x337, same as the reboot command. the format is as follows:

{| class="wikitable"
|+ Can Message for Setting the control mode
|-
! Byte 0 !! Byte 1 !! Byte 2 !! Byte 3 !! Byte 4 !! Byte 5
|-
| 0xAA || Control type || MSB int16_t || LSB int16_t|| MSB int16_t || LSB int16_t
|-
| Hardcoded command|| See Table Above || colspan=2 | Max value for lever completely forward || colspan=2 | Same but for backward (Positive for reverse)

|}

==== Example command: ====
<syntaxhighlight lang="bash" line="1" start="69">
cansend can2 337#AA0000000000
</syntaxhighlight>

== CAN Diagnostics messages ==
The throttle also send out messages to help debugging every 200 ms. It is send on address 0x337 and has the following format:

{| class="wikitable"
|+ Can Message for Diagnostic Purposes
|-
! Byte 0 !! Byte 1 !! Byte 2 !! Byte 3 !! Byte 4 !! Byte 5 !! Byte 6 !! Byte 7
|-
| MSB int16_t || LSB int16_t || MSB int16_t || LSB int16_t || MSB int16_t || LSB int16_t || uint8_t || Error status
|-
| colspan=2 | Filtered lever position, from +512 to -512 || colspan=2 | Raw position reported by the magnetic encoder || colspan=2 | Raw data from the deadmanswitch ADC || Gain that is required to readout the lever position || Enum of current error state. 0x00 is good
|}

If any of the error status bits are set, the throttle is set into IDLE mode and will shut off the motor. The following table shows what the bitfield represents:

{| class="wikitable"
|+ Different control modes of the throttle
|-
! Bit !! Enum Name !! Explanation
|-
| 0 to 2 || twiError || See next table for possible values
|-
| 3 || noLimitsLoaded || Reading of EEPROM for throttle limits failed
|-
| 4 || gainClipping || The Magnetic encoder detected no good magnetic field present
|-
| 5 || gainInvalid || The gain value read from the magnetic encoder is beyond the range specified in software
|-
| 6 || deadmanMissing || The hall sensor of the deadman-switch doesn't detect a strong enough magnet
|-
| 7 || impeadanceHigh || The impeadance of the deadman signal is too high, indicating a bad connection
|}

{| class="wikitable"
|+ TWI error states
|-
! Value !! Error name !! Error Description
|-
| 0 || TWI_ERROR_NoError || Indicates that the command completed successfully.
|-
| 1 || TWI_ERROR_BusFault || A TWI bus fault occurred while attempting to capture the bus.
|-
| 2 || TWI_ERROR_BusCaptureTimeout || A timeout occurred whilst waiting for the bus to be ready.
|-
| 3 || TWI_ERROR_SlaveResponseTimeout || No ACK received at the nominated slave address within the timeout period.
|-
| 4 || TWI_ERROR_SlaveNotReady || Slave NAKed the TWI bus START condition.
|-
| 5 || TWI_ERROR_SlaveNAK || Slave NAKed whilst attempting to send data to the device.
|}

Throttle

2025-05-17T06:44:53Z

Aran Dokoupil: /* Setting the Control Mode over CAN */

The throttle controls the motor and is operated by the pilot during sailing. It controls the duty cycle of the motor via the CAN bus using the standard VESC message format.

== Usage ==
[[File:Throttle Schematic.png|thumb|Throttle shown in the inactive (green led) neutral position]]
To use the throttle to control the motor the green illuminated ''arm-button'' will have to be pressed for a few seconds, however some conditions need to be met to ensure a safe start of the motor.

# The ''dead-man cord'' needs to be applied to the bottom of the throttle body, should snap in place magnetically
# The ''throttle lever'' Should be in its neutral position, pointing straight up with a noticeable tactile bump
# The CAN bus need to be actively acknowledging packets, which means other devices need to be active on the bus
# No other error should have occurred inside the electronics

If one of these conditions is not met, the throttle will beep the number of times indicated above.

== Programming Throttle Position ==
The throttle position is read out by a magnet attached tot the ''throttle lever'', because the orientation of this magnet is not know in the firmware, this position can be programmed into the EEPROM. To enter programming mode hold down the arm button during power-on. A four beep descending tone should be played, and the LED should do a double blink in red continuously. To program the throttle push lever as far forward as possible and press the button, a single beep be heard. Repeat this twice with the lever in the center and finally with the lever all the way backwards. After three beeps the throttle is reprogrammed and normal operation is resumed. To summarize:

# Lever in the forward position
# Lever in the center position
# Lever in de backward position
#

If no programming is desired leave the lever alone for 10 seconds and the lever will reboot into normal mode.

== Setting the Control Mode over CAN ==
The Throttle controls the VESC motodriver at 10Hz messaging rate with the default CAN format implemented inside the VESC. [https://dongilc.gitbook.io/openrobot-inc/tutorials/control-with-can More info on the format.] The throttle supports the following modes:

{| class="wikitable"
|+ Different control modes of the throttle
|-
! Control Mode !! Configuration Byte Value !! Unit !! Additional data required
|-
| Duty Cycle|| 0x00 || Percentage || None lever in the maximum forward position is 100%
|-
|Filtered Duty Cycle|| 0x01 || Percentage || None lever in the maximum forward position is 100%
|-
|Current Control || 0x02 || 100mA || Specify the max current for forward and backwards in two int16_t's
|-
|RPM Control || 0x03 || RPM || Specify the rpm for forward and backwards in two int16_t's
|-
|Current Control Relative
|0x04
|Percentage
|None lever in the maximum forward position is 100%
|}

These modes can be send to the throttle when the throttle is off. If the throttle is on the configuration will be ignored. A sound will play when a message is received. The message has to be send to the Throttle address 0x337, same as the reboot command. the format is as follows:

{| class="wikitable"
|+ Can Message for Setting the control mode
|-
! Byte 0 !! Byte 1 !! Byte 2 !! Byte 3 !! Byte 4 !! Byte 5
|-
| 0xAA || Control type || MSB int16_t || LSB int16_t|| MSB int16_t || LSB int16_t
|-
| Hardcoded command|| See Table Above || colspan=2 | Max value for lever completely forward || colspan=2 | Same but for backward (Positive for reverse)

|}

==== Example command: ====
<syntaxhighlight lang="bash" line="1" start="69">
cansend can2 337#AA0000000000
</syntaxhighlight>

== CAN Diagnostics messages ==
The throttle also send out messages to help debugging every 200 ms. It is send on address 0x337 and has the following format:

{| class="wikitable"
|+ Can Message for Diagnostic Purposes
|-
! Byte 0 !! Byte 1 !! Byte 2 !! Byte 3 !! Byte 4 !! Byte 5 !! Byte 6 !! Byte 7
|-
| MSB int16_t || LSB int16_t || MSB int16_t || LSB int16_t || MSB int16_t || LSB int16_t || uint8_t || Error status
|-
| colspan=2 | Filtered lever position, from +512 to -512 || colspan=2 | Raw position reported by the magnetic encoder || colspan=2 | Raw data from the deadmanswitch ADC || Gain that is required to readout the lever position || Enum of current error state. 0x00 is good
|}

If any of the error status bits are set, the throttle is set into IDLE mode and will shut off the motor. The following table shows what the bitfield represents:

{| class="wikitable"
|+ Different control modes of the throttle
|-
! Bit !! Enum Name !! Explanation
|-
| 0 to 2 || twiError || See next table for possible values
|-
| 3 || noLimitsLoaded || Reading of EEPROM for throttle limits failed
|-
| 4 || gainClipping || The Magnetic encoder detected no good magnetic field present
|-
| 5 || gainInvalid || The gain value read from the magnetic encoder is beyond the range specified in software
|-
| 6 || deadmanMissing || The hall sensor of the deadman-switch doesn't detect a strong enough magnet
|-
| 7 || impeadanceHigh || The impeadance of the deadman signal is too high, indicating a bad connection
|}

{| class="wikitable"
|+ TWI error states
|-
! Value !! Error name !! Error Description
|-
| 0 || TWI_ERROR_NoError || Indicates that the command completed successfully.
|-
| 1 || TWI_ERROR_BusFault || A TWI bus fault occurred while attempting to capture the bus.
|-
| 2 || TWI_ERROR_BusCaptureTimeout || A timeout occurred whilst waiting for the bus to be ready.
|-
| 3 || TWI_ERROR_SlaveResponseTimeout || No ACK received at the nominated slave address within the timeout period.
|-
| 4 || TWI_ERROR_SlaveNotReady || Slave NAKed the TWI bus START condition.
|-
| 5 || TWI_ERROR_SlaveNAK || Slave NAKed whilst attempting to send data to the device.
|}

Throttle

2025-05-17T06:26:07Z

Aran Dokoupil: /* Setting the Control Mode over CAN */

The throttle controls the motor and is operated by the pilot during sailing. It controls the duty cycle of the motor via the CAN bus using the standard VESC message format.

== Usage ==
[[File:Throttle Schematic.png|thumb|Throttle shown in the inactive (green led) neutral position]]
To use the throttle to control the motor the green illuminated ''arm-button'' will have to be pressed for a few seconds, however some conditions need to be met to ensure a safe start of the motor.

# The ''dead-man cord'' needs to be applied to the bottom of the throttle body, should snap in place magnetically
# The ''throttle lever'' Should be in its neutral position, pointing straight up with a noticeable tactile bump
# The CAN bus need to be actively acknowledging packets, which means other devices need to be active on the bus
# No other error should have occurred inside the electronics

If one of these conditions is not met, the throttle will beep the number of times indicated above.

== Programming Throttle Position ==
The throttle position is read out by a magnet attached tot the ''throttle lever'', because the orientation of this magnet is not know in the firmware, this position can be programmed into the EEPROM. To enter programming mode hold down the arm button during power-on. A four beep descending tone should be played, and the LED should do a double blink in red continuously. To program the throttle push lever as far forward as possible and press the button, a single beep be heard. Repeat this twice with the lever in the center and finally with the lever all the way backwards. After three beeps the throttle is reprogrammed and normal operation is resumed. To summarize:

# Lever in the forward position
# Lever in the center position
# Lever in de backward position
#

If no programming is desired leave the lever alone for 10 seconds and the lever will reboot into normal mode.

== Setting the Control Mode over CAN ==
The Throttle controls the VESC motodriver at 10Hz messaging rate with the default CAN format implemented inside the VESC. [https://dongilc.gitbook.io/openrobot-inc/tutorials/control-with-can More info on the format.] The throttle supports four modes:

{| class="wikitable"
|+ Different control modes of the throttle
|-
! Control Mode !! Configuration Byte Value !! Unit !! Additional data required
|-
| Duty Cycle|| 0x00 || Percentage || None lever in the maximum forward position is 100%
|-
|Filtered Duty Cycle|| 0x01 || Percentage || None lever in the maximum forward position is 100%
|-
|Current Control || 0x02 || 100mA || Specify the max current for forward and backwards in two int16_t's
|-
|RPM Control || 0x03 || RPM || Specify the rpm for forward and backwards in two int16_t's
|-
|Current Control Relative
|0x04
|Percentage
|None lever in the maximum forward position is 100%
|}

These modes can be send to the throttle when the throttle is off. If the throttle is on the configuration will be ignored. A sound will play when a message is received. The message has to be send to the Throttle address 0x337, same as the reboot command. the format is as follows:

{| class="wikitable"
|+ Can Message for Setting the control mode
|-
! Byte 0 !! Byte 1 !! Byte 2 !! Byte 3 !! Byte 4 !! Byte 5
|-
| 0xAA || Control type || MSB int16_t || LSB int16_t|| MSB int16_t || LSB int16_t
|-
| Hardcoded command|| See Table Above || colspan=2 | Max value for lever completely forward || colspan=2 | Same but for backward (Positive for reverse)

|}

==== Example command: ====
<syntaxhighlight lang="bash" line="1" start="69">
cansend can2 337#AA0000000000
</syntaxhighlight>

== CAN Diagnostics messages ==
The throttle also send out messages to help debugging every 200 ms. It is send on address 0x337 and has the following format:

{| class="wikitable"
|+ Can Message for Diagnostic Purposes
|-
! Byte 0 !! Byte 1 !! Byte 2 !! Byte 3 !! Byte 4 !! Byte 5 !! Byte 6 !! Byte 7
|-
| MSB int16_t || LSB int16_t || MSB int16_t || LSB int16_t || MSB int16_t || LSB int16_t || uint8_t || Error status
|-
| colspan=2 | Filtered lever position, from +512 to -512 || colspan=2 | Raw position reported by the magnetic encoder || colspan=2 | Raw data from the deadmanswitch ADC || Gain that is required to readout the lever position || Enum of current error state. 0x00 is good
|}

If any of the error status bits are set, the throttle is set into IDLE mode and will shut off the motor. The following table shows what the bitfield represents:

{| class="wikitable"
|+ Different control modes of the throttle
|-
! Bit !! Enum Name !! Explanation
|-
| 0 to 2 || twiError || See next table for possible values
|-
| 3 || noLimitsLoaded || Reading of EEPROM for throttle limits failed
|-
| 4 || gainClipping || The Magnetic encoder detected no good magnetic field present
|-
| 5 || gainInvalid || The gain value read from the magnetic encoder is beyond the range specified in software
|-
| 6 || deadmanMissing || The hall sensor of the deadman-switch doesn't detect a strong enough magnet
|-
| 7 || impeadanceHigh || The impeadance of the deadman signal is too high, indicating a bad connection
|}

{| class="wikitable"
|+ TWI error states
|-
! Value !! Error name !! Error Description
|-
| 0 || TWI_ERROR_NoError || Indicates that the command completed successfully.
|-
| 1 || TWI_ERROR_BusFault || A TWI bus fault occurred while attempting to capture the bus.
|-
| 2 || TWI_ERROR_BusCaptureTimeout || A timeout occurred whilst waiting for the bus to be ready.
|-
| 3 || TWI_ERROR_SlaveResponseTimeout || No ACK received at the nominated slave address within the timeout period.
|-
| 4 || TWI_ERROR_SlaveNotReady || Slave NAKed the TWI bus START condition.
|-
| 5 || TWI_ERROR_SlaveNAK || Slave NAKed whilst attempting to send data to the device.
|}

Individual Phases

2024-11-13T13:20:22Z

Aran Dokoupil: Created page with "WIP"

WIP

Rudder

2024-11-02T09:50:34Z

Aran Dokoupil:

The motor currently in use in the rudder is the Lehner 30100/12 with a NTC Temp. Sensor (B 25/100 3988 ±1%) installed.

Rudder

2024-11-02T09:48:59Z

Aran Dokoupil:

The motor currently in use in the rudder is the 30100/12 with a NTC Temp. Sensor (B 25/100 3988 ±1%) installed.

Rudder

2024-11-02T09:45:58Z

Aran Dokoupil: Created page with "The motor currently in use in the rudder is the 30100/14 with a NTC Temp. Sensor (B 25/100 3988 ±1%) installed."

The motor currently in use in the rudder is the 30100/14 with a NTC Temp. Sensor (B 25/100 3988 ±1%) installed.

Autopilot

2024-10-21T20:09:12Z

Aran Dokoupil:

== Platform ==
Ease of development dictated the choice to run the control loop on existing hard- and software. which was chosen to be Ardupilot running on a [https://docs.cubepilot.org/user-guides/autopilot/the-cube-module-overview orange cube].
[[File:Ardupilot.jpg|thumb|Ardupilot PCB with the orange cube mounted.]]
To make use for our application a PCB has been designed to integrate into the hydrofoil design.

To connect to the ardupilot on the cube for tweaking settings and tuning control loops, [https://ardupilot.org/planner/docs/mission-planner-overview.html Mission Planner] will be used. The following section have tweaked settings found in Mission Planner.

== Hardware ==
The cube is a plug-and-play unit and therefore does not need setup changes in the underlying ardupilot software. Only necessary settings should be tweaked.

Apart from the settings, tuning needs to be done in Mission Planner, this can only be done with the solar boat in the water and therefore no values are known for now.

The ardupilot PCB supports three servo motors, two front and one back motor. It has two isolated power supplies for the servo motors. Support for CAN and the cube is powered by the 24v input from the CAN connection.

It has its own GPS antenna and four UART serial ports, where Serial1 is used for the MAVLINK connect to Mission Planner that is running on a laptop. Two of these serial ports will be used to implement the height sensors that will be mounted on the boat for measuring the height of the water. This ensures that the system correctly responds to waves where the boat can 'surf' over.

For steering on foils an extra MCU is added onto the board namely: ATSAMD20E18A. This MCU can receive data from the rudder that gives the steering position and sends it through to the cube.

== Height Sensors ==
Currently testing ultrasonic height sensors, the RS485 version of the DYP-A02YY4W-V2.0.

== Ardupilot settings ==
To use the ardupilot as the foil control unit, some settings need to be changed since they do not apply to us or should be disabled. These settings are given below with a small explanation why it has been configured as is.

The settings below are the changed settings used by the ardupilot. There are more ports available on the ardupilot, whenever more are used or are changed the table will be updated.
{| class="wikitable sortable"
|+
Configuration of ardupilot
!Setting
!Value
!Description
!Reason
|-
|INS_GYR_CAL
|0
|Controls the automatic gyro calibration.
|Gyro calibration requires that the unit should be held as still as possible.
|-
|SERVO1_FUNCTION
|78
|ElevonRight
|Controls the right foil assembly.
|-
|SERVO2_FUNCTION
|77
|ElevonLeft
|Controls the left foil assembly.
|-
|INITIAL_MODE
|5
|FBWA
|Fly By Wire A this is a fly mode for the control unit. More can be found [https://ardupilot.org/plane/docs/fbwa-mode.html here].
|-
|GPS_TYPE2
|5
|NMEA
|This sets the GPS data that is sent onto the serial data port.
|-
|SERIAL1_PROTOCOL
|2
|MAVLINK2
|Controls what protocol to use on the serial port
|-
|SERIAL1_BAUD
|57
|57600
|Specifies the baudrate of the serial port.
|-
|SERIAL4_PROTOCOL
|5
|GPS
|Controls what protocol to use on the serial port
|-
|SERIAL4_BAUD
|9
|9600
|Specifies the baudrate of the serial port.
|}

== Future plans ==
As of now: 21-03-2023, FBWA mode is used for controlling the front two foil assembly. It would probably be beneficial whenever the whole system is finished to move towards the FBWB mode.

This mode supports "Automatic Altitude Holding", that makes sure that the same level of altitude is automatically kept. Further testing is needed for determining the control loops and their coefficients.

Implementing the different sensors into ardupilot and using that data to respond to the environment. These sensors are at least the height sensors and the rudder sensor for the steering angle.

== Relevant links for configuring Ardupilot ==
https://ardupilot.org/copter/docs/common-gcs-only-operation.html

https://ardupilot.org/copter/docs/common-rangefinder-landingpage.html

https://ardupilot.org/copter/docs/setting-up-for-tuning.html

https://ardupilot.org/copter/docs/terrain-following-manual-modes.html

https://ardupilot.org/copter/docs/common-sensor-offset-compensation.html

https://ardupilot.org/copter/docs/crash_check.html

https://ardupilot.org/copter/docs/flight-modes.html --FBW-A mode seems best fit for front only, FBW-B for finalized system

https://ardupilot.org/plane/docs/fbwb-mode.html

https://ardupilot.org/copter/docs/stabilize-mode.html

https://ardupilot.org/plane/docs/fixed-wing-faq.html --Disable Gyro calibration on start-up

https://ardupilot.org/rover/docs/sonar-sensors.html --Two sonar sensors

https://ardupilot.org/dev/docs/plane-architecture.html --Plane architecture and files

Throttle

2024-04-23T18:34:54Z

Aran Dokoupil: /* Programming Throttle Position */

The throttle controls the motor and is operated by the pilot during sailing. It controls the duty cycle of the motor via the CAN bus using the standard VESC message format.

== Usage ==
[[File:Throttle Schematic.png|thumb|Throttle shown in the inactive (green led) neutral position]]
To use the throttle to control the motor the green illuminated ''arm-button'' will have to be pressed for a few seconds, however some conditions need to be met to ensure a safe start of the motor.

# The ''dead-man cord'' needs to be applied to the bottom of the throttle body, should snap in place magnetically
# The ''throttle lever'' Should be in its neutral position, pointing straight up with a noticeable tactile bump
# The CAN bus need to be actively acknowledging packets, which means other devices need to be active on the bus
# No other error should have occurred inside the electronics

If one of these conditions is not met, the throttle will beep the number of times indicated above.

== Programming Throttle Position ==
The throttle position is read out by a magnet attached tot the ''throttle lever'', because the orientation of this magnet is not know in the firmware, this position can be programmed into the EEPROM. To enter programming mode hold down the arm button during power-on. A four beep descending tone should be played, and the LED should do a double blink in red continuously. To program the throttle push lever as far forward as possible and press the button, a single beep be heard. Repeat this twice with the lever in the center and finally with the lever all the way backwards. After three beeps the throttle is reprogrammed and normal operation is resumed. To summarize:

# Lever in the forward position
# Lever in the center position
# Lever in de backward position
#

If no programming is desired leave the lever alone for 10 seconds and the lever will reboot into normal mode.

== Setting the Control Mode over CAN ==
The Throttle controls the VESC motodriver at 10Hz messaging rate with the default CAN format implemented inside the VESC. [https://dongilc.gitbook.io/openrobot-inc/tutorials/control-with-can More info on the format.] The throttle supports four modes:

{| class="wikitable"
|+ Different control modes of the throttle
|-
! Control Mode !! Configuration Byte Value !! Unit !! Additional data required
|-
| Duty Cycle|| 0x01 || Percentage || None lever in the maximum forward position is 100%
|-
|Filtered Duty Cycle|| 0x02 || Percentage || None lever in the maximum forward position is 100%
|-
|Current Control || 0x03 || 100mA || Specify the max current for forward and backwards in two int16_t's
|-
|RPM Control || 0x04 || RPM || Specify the rpm for forward and backwards in two int16_t's
|}

These modes can be send to the throttle when the throttle is off. If the throttle is on the configuration will be ignored. A sound will play when a message is received. The message has to be send to the Throttle address 0x1337, same as the reboot command. the format is as follows:

{| class="wikitable"
|+ Can Message for Setting the control mode
|-
! Byte 0 !! Byte 1 !! Byte 2 !! Byte 3 !! Byte 4 !! Byte 5
|-
| 0xAA || Control type || MSB int16_t || LSB int16_t|| MSB int16_t || LSB int16_t
|-
| Hardcoded command|| See Table Above || colspan=2 | Max value for lever completely forward || colspan=2 | Same but for backward (Positive for reverse)

|}

== CAN Diagnostics messages ==
The throttle also send out messages to help debugging every 200 ms. It is send on address 0x337 and has the following format:

{| class="wikitable"
|+ Can Message for Diagnostic Purposes
|-
! Byte 0 !! Byte 1 !! Byte 2 !! Byte 3 !! Byte 4 !! Byte 5 !! Byte 6 !! Byte 7
|-
| MSB int16_t || LSB int16_t || MSB int16_t || LSB int16_t || MSB int16_t || LSB int16_t || uint8_t || Error status
|-
| colspan=2 | Filtered lever position, from +512 to -512 || colspan=2 | Raw position reported by the magnetic encoder || colspan=2 | Raw data from the deadmanswitch ADC || Gain that is required to readout the lever position || Enum of current error state. 0x00 is good
|}

If any of the error status bits are set, the throttle is set into IDLE mode and will shut off the motor. The following table shows what the bitfield represents:

{| class="wikitable"
|+ Different control modes of the throttle
|-
! Bit !! Enum Name !! Explanation
|-
| 0 to 2 || twiError || See next table for possible values
|-
| 3 || noLimitsLoaded || Reading of EEPROM for throttle limits failed
|-
| 4 || gainClipping || The Magnetic encoder detected no good magnetic field present
|-
| 5 || gainInvalid || The gain value read from the magnetic encoder is beyond the range specified in software
|-
| 6 || deadmanMissing || The hall sensor of the deadman-switch doesn't detect a strong enough magnet
|-
| 7 || impeadanceHigh || The impeadance of the deadman signal is too high, indicating a bad connection
|}

{| class="wikitable"
|+ TWI error states
|-
! Value !! Error name !! Error Description
|-
| 0 || TWI_ERROR_NoError || Indicates that the command completed successfully.
|-
| 1 || TWI_ERROR_BusFault || A TWI bus fault occurred while attempting to capture the bus.
|-
| 2 || TWI_ERROR_BusCaptureTimeout || A timeout occurred whilst waiting for the bus to be ready.
|-
| 3 || TWI_ERROR_SlaveResponseTimeout || No ACK received at the nominated slave address within the timeout period.
|-
| 4 || TWI_ERROR_SlaveNotReady || Slave NAKed the TWI bus START condition.
|-
| 5 || TWI_ERROR_SlaveNAK || Slave NAKed whilst attempting to send data to the device.
|}

Throttle

2024-03-23T11:29:14Z

Aran Dokoupil: /* CAN Diagnostics messages */

The throttle controls the motor and is operated by the pilot during sailing. It controls the duty cycle of the motor via the CAN bus using the standard VESC message format.

== Usage ==
[[File:Throttle Schematic.png|thumb|Throttle shown in the inactive (green led) neutral position]]
To use the throttle to control the motor the green illuminated ''arm-button'' will have to be pressed for a few seconds, however some conditions need to be met to ensure a safe start of the motor.

# The ''dead-man cord'' needs to be applied to the bottom of the throttle body, should snap in place magnetically
# The ''throttle lever'' Should be in its neutral position, pointing straight up with a noticeable tactile bump
# The CAN bus need to be actively acknowledging packets, which means other devices need to be active on the bus
# No other error should have occurred inside the electronics

If one of these conditions is not met, the throttle will beep the number of times indicated above.

== Programming Throttle Position ==
The throttle position is read out by a magnet attached tot the ''throttle lever'', because the orientation of this magnet is not know in the firmware, this position can be programmed into the EEPROM. To enter programming mode hold down the arm button during power-on. A four beep descending tone should be played, and the LED should do a double blink in red continuously. To program the throttle push lever as far forward as possible and press the button, a single beep be heard. Repeat this twice with the lever in the center and finally with the lever all the way backwards. After three beeps the throttle is reprogrammed and normal operation is resumed.

If no programming is desired leave the lever alone for 10 seconds and the lever will reboot into normal mode.

== Setting the Control Mode over CAN ==
The Throttle controls the VESC motodriver at 10Hz messaging rate with the default CAN format implemented inside the VESC. [https://dongilc.gitbook.io/openrobot-inc/tutorials/control-with-can More info on the format.] The throttle supports four modes:

{| class="wikitable"
|+ Different control modes of the throttle
|-
! Control Mode !! Configuration Byte Value !! Unit !! Additional data required
|-
| Duty Cycle|| 0x01 || Percentage || None lever in the maximum forward position is 100%
|-
|Filtered Duty Cycle|| 0x02 || Percentage || None lever in the maximum forward position is 100%
|-
|Current Control || 0x03 || 100mA || Specify the max current for forward and backwards in two int16_t's
|-
|RPM Control || 0x04 || RPM || Specify the rpm for forward and backwards in two int16_t's
|}

These modes can be send to the throttle when the throttle is off. If the throttle is on the configuration will be ignored. A sound will play when a message is received. The message has to be send to the Throttle address 0x1337, same as the reboot command. the format is as follows:

{| class="wikitable"
|+ Can Message for Setting the control mode
|-
! Byte 0 !! Byte 1 !! Byte 2 !! Byte 3 !! Byte 4 !! Byte 5
|-
| 0xAA || Control type || MSB int16_t || LSB int16_t|| MSB int16_t || LSB int16_t
|-
| Hardcoded command|| See Table Above || colspan=2 | Max value for lever completely forward || colspan=2 | Same but for backward (Positive for reverse)

|}

== CAN Diagnostics messages ==
The throttle also send out messages to help debugging every 200 ms. It is send on address 0x337 and has the following format:

{| class="wikitable"
|+ Can Message for Diagnostic Purposes
|-
! Byte 0 !! Byte 1 !! Byte 2 !! Byte 3 !! Byte 4 !! Byte 5 !! Byte 6 !! Byte 7
|-
| MSB int16_t || LSB int16_t || MSB int16_t || LSB int16_t || MSB int16_t || LSB int16_t || uint8_t || Error status
|-
| colspan=2 | Filtered lever position, from +512 to -512 || colspan=2 | Raw position reported by the magnetic encoder || colspan=2 | Raw data from the deadmanswitch ADC || Gain that is required to readout the lever position || Enum of current error state. 0x00 is good
|}

If any of the error status bits are set, the throttle is set into IDLE mode and will shut off the motor. The following table shows what the bitfield represents:

{| class="wikitable"
|+ Different control modes of the throttle
|-
! Bit !! Enum Name !! Explanation
|-
| 0 to 2 || twiError || See next table for possible values
|-
| 3 || noLimitsLoaded || Reading of EEPROM for throttle limits failed
|-
| 4 || gainClipping || The Magnetic encoder detected no good magnetic field present
|-
| 5 || gainInvalid || The gain value read from the magnetic encoder is beyond the range specified in software
|-
| 6 || deadmanMissing || The hall sensor of the deadman-switch doesn't detect a strong enough magnet
|-
| 7 || impeadanceHigh || The impeadance of the deadman signal is too high, indicating a bad connection
|}

{| class="wikitable"
|+ TWI error states
|-
! Value !! Error name !! Error Description
|-
| 0 || TWI_ERROR_NoError || Indicates that the command completed successfully.
|-
| 1 || TWI_ERROR_BusFault || A TWI bus fault occurred while attempting to capture the bus.
|-
| 2 || TWI_ERROR_BusCaptureTimeout || A timeout occurred whilst waiting for the bus to be ready.
|-
| 3 || TWI_ERROR_SlaveResponseTimeout || No ACK received at the nominated slave address within the timeout period.
|-
| 4 || TWI_ERROR_SlaveNotReady || Slave NAKed the TWI bus START condition.
|-
| 5 || TWI_ERROR_SlaveNAK || Slave NAKed whilst attempting to send data to the device.
|}

Throttle

2024-03-20T09:30:00Z

Aran Dokoupil:

The throttle controls the motor and is operated by the pilot during sailing. It controls the duty cycle of the motor via the CAN bus using the standard VESC message format.

== Usage ==
[[File:Throttle Schematic.png|thumb|Throttle shown in the inactive (green led) neutral position]]
To use the throttle to control the motor the green illuminated ''arm-button'' will have to be pressed for a few seconds, however some conditions need to be met to ensure a safe start of the motor.

# The ''dead-man cord'' needs to be applied to the bottom of the throttle body, should snap in place magnetically
# The ''throttle lever'' Should be in its neutral position, pointing straight up with a noticeable tactile bump
# The CAN bus need to be actively acknowledging packets, which means other devices need to be active on the bus
# No other error should have occurred inside the electronics

If one of these conditions is not met, the throttle will beep the number of times indicated above.

== Programming Throttle Position ==
The throttle position is read out by a magnet attached tot the ''throttle lever'', because the orientation of this magnet is not know in the firmware, this position can be programmed into the EEPROM. To enter programming mode hold down the arm button during power-on. A four beep descending tone should be played, and the LED should do a double blink in red continuously. To program the throttle push lever as far forward as possible and press the button, a single beep be heard. Repeat this twice with the lever in the center and finally with the lever all the way backwards. After three beeps the throttle is reprogrammed and normal operation is resumed.

If no programming is desired leave the lever alone for 10 seconds and the lever will reboot into normal mode.

== Setting the Control Mode over CAN ==
The Throttle controls the VESC motodriver at 10Hz messaging rate with the default CAN format implemented inside the VESC. [https://dongilc.gitbook.io/openrobot-inc/tutorials/control-with-can More info on the format.] The throttle supports four modes:

{| class="wikitable"
|+ Different control modes of the throttle
|-
! Control Mode !! Configuration Byte Value !! Unit !! Additional data required
|-
| Duty Cycle|| 0x01 || Percentage || None lever in the maximum forward position is 100%
|-
|Filtered Duty Cycle|| 0x02 || Percentage || None lever in the maximum forward position is 100%
|-
|Current Control || 0x03 || 100mA || Specify the max current for forward and backwards in two int16_t's
|-
|RPM Control || 0x04 || RPM || Specify the rpm for forward and backwards in two int16_t's
|}

These modes can be send to the throttle when the throttle is off. If the throttle is on the configuration will be ignored. A sound will play when a message is received. The message has to be send to the Throttle address 0x1337, same as the reboot command. the format is as follows:

{| class="wikitable"
|+ Can Message for Setting the control mode
|-
! Byte 0 !! Byte 1 !! Byte 2 !! Byte 3 !! Byte 4 !! Byte 5
|-
| 0xAA || Control type || MSB int16_t || LSB int16_t|| MSB int16_t || LSB int16_t
|-
| Hardcoded command|| See Table Above || colspan=2 | Max value for lever completely forward || colspan=2 | Same but for backward (Positive for reverse)

|}

== CAN Diagnostics messages ==
The throttle also send out messages to help debugging every 200 ms. It is send on address 0x1337 and has the following format:

{| class="wikitable"
|+ Can Message for Diagnostic Purposes
|-
! Byte 0 !! Byte 1 !! Byte 2 !! Byte 3 !! Byte 4 !! Byte 5 !! Byte 6 !! Byte 7
|-
| MSB int16_t || LSB int16_t || MSB int16_t || LSB int16_t || MSB int16_t || LSB int16_t || uint8_t || Error status
|-
| colspan=2 | Filtered lever position, from +512 to -512 || colspan=2 | Raw position reported by the magnetic encoder || colspan=2 | Raw data from the deadmanswitch ADC || Gain that is required to readout the lever position || Enum of current error state. 0x00 is good
|}

If any of the error status bits are set, the throttle is set into IDLE mode and will shut off the motor. The following table shows what the bitfield represents:

{| class="wikitable"
|+ Different control modes of the throttle
|-
! Bit !! Enum Name !! Explanation
|-
| 0 to 2 || twiError || See next table for possible values
|-
| 3 || noLimitsLoaded || Reading of EEPROM for throttle limits failed
|-
| 4 || gainClipping || The Magnetic encoder detected no good magnetic field present
|-
| 5 || gainInvalid || The gain value read from the magnetic encoder is beyond the range specified in software
|-
| 6 || deadmanMissing || The hall sensor of the deadman-switch doesn't detect a strong enough magnet
|-
| 7 || impeadanceHigh || The impeadance of the deadman signal is too high, indicating a bad connection
|}

{| class="wikitable"
|+ TWI error states
|-
! Value !! Error name !! Error Description
|-
| 0 || TWI_ERROR_NoError || Indicates that the command completed successfully.
|-
| 1 || TWI_ERROR_BusFault || A TWI bus fault occurred while attempting to capture the bus.
|-
| 2 || TWI_ERROR_BusCaptureTimeout || A timeout occurred whilst waiting for the bus to be ready.
|-
| 3 || TWI_ERROR_SlaveResponseTimeout || No ACK received at the nominated slave address within the timeout period.
|-
| 4 || TWI_ERROR_SlaveNotReady || Slave NAKed the TWI bus START condition.
|-
| 5 || TWI_ERROR_SlaveNAK || Slave NAKed whilst attempting to send data to the device.
|}

Throttle

2024-03-20T08:48:33Z

Aran Dokoupil: /* CAN Diagnostics messages */

Throttle

2024-03-20T08:43:54Z

Aran Dokoupil:

Throttle

2024-03-20T08:43:19Z

Aran Dokoupil: /* Can Protocol */

CAN-bus

2024-03-19T15:33:37Z

Aran Dokoupil:

The communication between the electronics within the [[Solar boat (boii)|solar boat]] is build upon the CAN-bus protocol, where the [[datalogger]] logs the CAN messages. Pinout of our Binder connectors are:

{| class="wikitable"
|+ Colours of the Standard Binder CAN Cable and its pinout
|-
! Binder Connector pin Number !! Wire Colour !! Signal on wire
|-
| 1 ||style="background: #83603A;"| Brown || 24v Power
|-
| 2 ||style="background: #FFFFFF;"| White || CAN H
|-
| 3 ||style="background: #0065B2;"| Blue || CAN L
|-
| 4 ||style="background: #241F21;color:white;"| Black || Ground
|-
| 5 ||style="background: #B2B3B7;"| Gray || Safety

|}

Note that the M12 connectors have a different pinout and thus different colour wires. To make compatibility between systems easier the binder connectors are soldered with the wrong colored wires so that plugging in a M12 device results in the right signals being passed to the Binder connector. This Compatibility pinout is shown below:

{| class="wikitable"
|+ NON-STANDARD!! Colours when connecting an M12 cable to a binder connector NON-STANDARD!!
|-
! Binder Connector pin Number !! Wire Colour !! Signal on wire
|-
| 1 ||style="background: #FFFFFF;"| White || 24v Power
|-
| 2 ||style="background: #241F21;color:white;"| Black || CAN H
|-
| 3 ||style="background: #B2B3B7;"| Gray || CAN L
|-
| 4 ||style="background: #0065B2;"| Blue || Ground
|-
| 5 ||style="background: #83603A;"| Brown || Safety
|-

|}

== Battery (MG) CAN-format (No longer used) ==
As of now the MG electronics [[battery]] is used in the [[Solar boat (boii)|solar boat]]. Although a new battery is being developed, this MG battery is still in use (as of September '22). Therefore the battery format is given here below.
{| class="wikitable"
|+
!Node-ID
!Index
!Subindex
!Data
!Type
!Resolution
|-
|0x302
|0x2005
|0x01
|Voltage <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|0x02
|Current <code>[A]</code>
|int16_t
|10 <code>[mA/LSB]</code>
|-
|
|
|0x03
|Current Discharge <code>[A]</code>
|int16_t
|10 <code>[mA/LSB]</code>
|-
|
|
|0x04
|Current Charge <code>[A]</code>
|int16_t
|10 <code>[mA/LSB]</code>
|-
|
|
|0x05
|State-of-Charge <code>[%]</code>
|int8_t
|1 <code>[%/LSB]</code>
|-
|
|
|0x06
|
|
|
|-
|
|
|0x07
|Time to Go <code>[min]</code>
|uint16_t
|1 <code>[min/LSB]</code>
|-
|
|
|
|
|
|
|-
|0x402
|0x2005
|0x09
|Cell Temperature High <code>[°C]</code>
|int8_t
|1 <code>[°C/LSB]</code>
|-
|
|
|0x0A
|
|
|
|-
|
|
|0x0B
|Cell Temperature Low <code>[°C]</code>
|int8_t
|1 <code>[°C/LSB]</code>
|-
|
|
|0x0C
|Cell Voltage High <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|0x0D
|Cell Voltage Low <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|0x0E
|BMS State
|uint32_t
|
|-
|
|
|0x0F
|Temperature Collection <code>[°C]</code>
|4x uint8_t
|1 <code>[°C/LSB]</code>
|-
|
|
|
|
|
|
|-
|0x482
|0x2000
|Cell nr
|Cell <code>[Cell_nr]</code> Voltage <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|
|
|
|
|-
|0x202
|Don't Care
|Don't Care
|Power Level <code>[%]</code>
|uint8_t
|1 <code>[%/LSB]</code>
|}

CAN-bus

2024-03-19T15:31:12Z

Aran Dokoupil:

The communication between the electronics within the [[Solar boat (boii)|solar boat]] is build upon the CAN-bus protocol, where the [[datalogger]] logs the CAN messages. Pinout of our Binder connectors are:

{| class="wikitable"
|+ Colours of the Standard Binder CAN Cable and its pinout
|-
! Binder Connector pin Number !! Wire Colour !! Signal on wire
|-
| 1 ||style="background: #83603A;"| Brown || 24v Power
|-
| 2 ||style="background: #FFFFFF;"| White || CAN H
|-
| 3 ||style="background: #0065B2;"| Blue || CAN L
|-
| 4 ||style="background: #241F21;color:white;"| Black || Ground
|-
| 5 ||style="background: #B2B3B7;"| Gray || Safety

|}

Note that the M12 connectors have a different pinout and thus different colour wires. To make compatibility between systems easier the binder connectors are soldered with the wrong colored wires so that plugging in a M12 device results in the right signals being passed to the Binder connector. This Compatibility pinout is shown below:

{| class="wikitable"
|+ NON-STANDARD!! Colours when connecting an M12 cable to a binder connector NON-STANDARD!!
|-
! Binder Connector pin Number !! Wire Colour !! Signal on wire
|-
| 1 ||style="background: #B2B3B7;"| Gray || Safety
|-
| 2 ||style="background: #FFFFFF;"| White || 24v Power
|-
| 3 ||style="background: #0065B2;"| Blue || Ground
|-
| 4 ||style="background: #241F21;color:white;"| Black || CAN H
|-
| 5 ||style="background: #83603A;"| Brown || CAN L
|-

|}

== Battery (MG) CAN-format (No longer used) ==
As of now the MG electronics [[battery]] is used in the [[Solar boat (boii)|solar boat]]. Although a new battery is being developed, this MG battery is still in use (as of September '22). Therefore the battery format is given here below.
{| class="wikitable"
|+
!Node-ID
!Index
!Subindex
!Data
!Type
!Resolution
|-
|0x302
|0x2005
|0x01
|Voltage <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|0x02
|Current <code>[A]</code>
|int16_t
|10 <code>[mA/LSB]</code>
|-
|
|
|0x03
|Current Discharge <code>[A]</code>
|int16_t
|10 <code>[mA/LSB]</code>
|-
|
|
|0x04
|Current Charge <code>[A]</code>
|int16_t
|10 <code>[mA/LSB]</code>
|-
|
|
|0x05
|State-of-Charge <code>[%]</code>
|int8_t
|1 <code>[%/LSB]</code>
|-
|
|
|0x06
|
|
|
|-
|
|
|0x07
|Time to Go <code>[min]</code>
|uint16_t
|1 <code>[min/LSB]</code>
|-
|
|
|
|
|
|
|-
|0x402
|0x2005
|0x09
|Cell Temperature High <code>[°C]</code>
|int8_t
|1 <code>[°C/LSB]</code>
|-
|
|
|0x0A
|
|
|
|-
|
|
|0x0B
|Cell Temperature Low <code>[°C]</code>
|int8_t
|1 <code>[°C/LSB]</code>
|-
|
|
|0x0C
|Cell Voltage High <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|0x0D
|Cell Voltage Low <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|0x0E
|BMS State
|uint32_t
|
|-
|
|
|0x0F
|Temperature Collection <code>[°C]</code>
|4x uint8_t
|1 <code>[°C/LSB]</code>
|-
|
|
|
|
|
|
|-
|0x482
|0x2000
|Cell nr
|Cell <code>[Cell_nr]</code> Voltage <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|
|
|
|
|-
|0x202
|Don't Care
|Don't Care
|Power Level <code>[%]</code>
|uint8_t
|1 <code>[%/LSB]</code>
|}

CAN-bus

2024-03-19T15:29:15Z

Aran Dokoupil:

The communication between the electronics within the [[Solar boat (boii)|solar boat]] is build upon the CAN-bus protocol, where the [[datalogger]] logs the CAN messages. Pinout of our Binder connectors are:

{| class="wikitable"
|+ Colours of the Standard Binder CAN Cable and its pinout
|-
! Binder Connector pin Number !! Wire Colour !! Signal on wire
|-
| 1 ||style="background: #FFFFFF;"| White || CAN H
|-
| 2 ||style="background: #241F21;color:white;"| Black || Ground
|-
| 3 ||style="background: #B2B3B7;"| Gray || Safety
|-
| 4 ||style="background: #0065B2;"| Blue || CAN L
|-
| 5 ||style="background: #83603A;"| Brown || 24v Power

|}

Note that the M12 connectors have a different pinout and thus different colour wires. To make compatibility between systems easier the binder connectors are soldered with the wrong colored wires so that plugging in a M12 device results in the right signals being passed to the Binder connector. This Compatibility pinout is shown below:

{| class="wikitable"
|+ NON-STANDARD!! Colours when connecting an M12 cable to a binder connector NON-STANDARD!!
|-
! Binder Connector pin Number !! Wire Colour !! Signal on wire
|-
| 1 ||style="background: #B2B3B7;"| Gray || Safety
|-
| 2 ||style="background: #FFFFFF;"| White || 24v Power
|-
| 3 ||style="background: #0065B2;"| Blue || Ground
|-
| 4 ||style="background: #241F21;color:white;"| Black || CAN H
|-
| 5 ||style="background: #83603A;"| Brown || CAN L
|-

|}

== Battery (MG) CAN-format (No longer used) ==
As of now the MG electronics [[battery]] is used in the [[Solar boat (boii)|solar boat]]. Although a new battery is being developed, this MG battery is still in use (as of September '22). Therefore the battery format is given here below.
{| class="wikitable"
|+
!Node-ID
!Index
!Subindex
!Data
!Type
!Resolution
|-
|0x302
|0x2005
|0x01
|Voltage <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|0x02
|Current <code>[A]</code>
|int16_t
|10 <code>[mA/LSB]</code>
|-
|
|
|0x03
|Current Discharge <code>[A]</code>
|int16_t
|10 <code>[mA/LSB]</code>
|-
|
|
|0x04
|Current Charge <code>[A]</code>
|int16_t
|10 <code>[mA/LSB]</code>
|-
|
|
|0x05
|State-of-Charge <code>[%]</code>
|int8_t
|1 <code>[%/LSB]</code>
|-
|
|
|0x06
|
|
|
|-
|
|
|0x07
|Time to Go <code>[min]</code>
|uint16_t
|1 <code>[min/LSB]</code>
|-
|
|
|
|
|
|
|-
|0x402
|0x2005
|0x09
|Cell Temperature High <code>[°C]</code>
|int8_t
|1 <code>[°C/LSB]</code>
|-
|
|
|0x0A
|
|
|
|-
|
|
|0x0B
|Cell Temperature Low <code>[°C]</code>
|int8_t
|1 <code>[°C/LSB]</code>
|-
|
|
|0x0C
|Cell Voltage High <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|0x0D
|Cell Voltage Low <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|0x0E
|BMS State
|uint32_t
|
|-
|
|
|0x0F
|Temperature Collection <code>[°C]</code>
|4x uint8_t
|1 <code>[°C/LSB]</code>
|-
|
|
|
|
|
|
|-
|0x482
|0x2000
|Cell nr
|Cell <code>[Cell_nr]</code> Voltage <code>[V]</code>
|uint16_t
|1 <code>[mV/LSB]</code>
|-
|
|
|
|
|
|
|-
|0x202
|Don't Care
|Don't Care
|Power Level <code>[%]</code>
|uint8_t
|1 <code>[%/LSB]</code>
|}

Throttle

2024-03-17T17:48:25Z

Aran Dokoupil:

Throttle

2024-03-17T17:47:46Z

Aran Dokoupil:

Throttle

2024-03-17T17:29:59Z

Aran Dokoupil:

Autopilot

2023-03-10T09:52:42Z

Aran Dokoupil: /* Relevant links for configuring Ardupilot */

== Platform ==
Ease of development dictated the choice to run the control loop on existing hard- and software. which was chosen to be Ardupilot running on a Beaglebone blue.

== Setup ==

For the beagle bone setup follow [https://ardupilot.org/copter/docs/common-beagle-bone-blue.html this] tutorial. The versions of Debian and Ardupilot used in this tutorial are old. The Debian image used on the beaglebone is the [https://rcn-ee.net/rootfs/bb.org/testing/2022-11-01/buster-console-armhf/am57xx-eMMC-flasher-debian-10.13-console-armhf-2022-11-01-1gb.img.xz 10.13 eMMC flasher]. The procedure to flash Debian to the onboard eMMC can be found [https://beagleboard.org/static/librobotcontrol/flashing.html here]. Also make sure to use version 4.3.1 of ardupilot by using the command bellow during the Ardupilot tutorial.

<code>sudo wget -O /usr/bin/ardupilot/arduplane https://firmware.ardupilot.org/Plane/stable-4.3.1/blue/arduplane</code>

== Relevant links for configuring Ardupilot ==
https://ardupilot.org/copter/docs/common-gcs-only-operation.html

https://ardupilot.org/copter/docs/common-rangefinder-landingpage.html

https://ardupilot.org/copter/docs/setting-up-for-tuning.html

https://ardupilot.org/copter/docs/terrain-following-manual-modes.html

https://ardupilot.org/copter/docs/common-sensor-offset-compensation.html

https://ardupilot.org/copter/docs/crash_check.html

https://ardupilot.org/copter/docs/flight-modes.html --FBW-A mode seems best fit for front only, FBW-B for finalized system

https://ardupilot.org/plane/docs/fbwb-mode.html

https://ardupilot.org/copter/docs/stabilize-mode.html

https://ardupilot.org/plane/docs/fixed-wing-faq.html --Disable Gyro calibration on start-up

https://ardupilot.org/rover/docs/sonar-sensors.html --Two sonar sensors

https://ardupilot.org/dev/docs/plane-architecture.html --Plane architecture and files

Throttle

2023-03-05T17:11:31Z

Aran Dokoupil:

Throttle

2023-03-05T17:10:57Z

Aran Dokoupil: /* Programming Throttle Position */

Throttle

2023-02-18T10:19:31Z

Aran Dokoupil: /* Programming Throttle Position */